Istio 설치와 구성 완벽 가이드

Kubernetes 환경에서 Istio 서비스 메시를 설치하고 구성하는 방법을 초급 개발자도 쉽게 이해할 수 있도록 실무 스토리와 비유로 풀어낸 가이드입니다. istioctl 설치부터 사이드카 주입까지 단계별로 학습합니다.

---

목차

1. Istio 컴포넌트
2. istioctl 설치
3. Istio 프로파일
4. 설치 및 확인
5. 사이드카 자동 주입
6. Envoy 프록시

---

1. Istio 컴포넌트

김개발 씨는 회사에서 마이크로서비스 아키텍처를 도입하기로 했다는 소식을 들었습니다. 팀장님이 "Istio를 사용해서 서비스 메시를 구축할 거야"라고 말씀하셨는데, 도대체 Istio가 무엇이고 어떤 부품들로 이루어져 있는지 궁금해졌습니다.

Istio는 마이크로서비스 간의 통신을 관리하는 서비스 메시 플랫폼입니다. 크게 데이터 플레인과 컨트롤 플레인으로 나뉘며, 데이터 플레인은 Envoy 프록시로 트래픽을 처리하고, 컨트롤 플레인은 Istiod라는 단일 컴포넌트로 구성 관리, 인증서 발급, 서비스 디스커버리를 담당합니다.

다음 코드를 살펴봅시다.

# Istio 주요 컴포넌트 확인
kubectl get pods -n istio-system

# 출력 예시:
# NAME                      READY   STATUS    RESTARTS   AGE
# istiod-5c9d8f8d4b-x7k2p   1/1     Running   0          10m

# Istiod는 Pilot, Citadel, Galley를 통합한 단일 바이너리입니다
kubectl describe pod -n istio-system istiod-5c9d8f8d4b-x7k2p

# Envoy 프록시는 각 애플리케이션 Pod의 사이드카로 배포됩니다
kubectl get pods -n default
# NAME                        READY   STATUS    RESTARTS   AGE
# myapp-7d8f9c6b5a-p4r2t      2/2     Running   0          5m

김개발 씨는 퇴근 후 집에서 Istio 공식 문서를 펼쳤습니다. 첫 페이지부터 나오는 용어들이 낯설었습니다.

데이터 플레인, 컨트롤 플레인, Envoy, Istiod... 도대체 이것들이 무엇일까요?

다음 날 출근하자마자 선배 박시니어 씨를 찾아갔습니다. "선배님, Istio가 정확히 뭔가요?" 박시니어 씨는 커피를 한 모금 마시고 친절하게 설명을 시작했습니다.

Istio의 구조를 이해하는 비유 "Istio를 이해하려면 먼저 비유를 하나 들어볼게요. 대형 쇼핑몰을 생각해보세요." 쇼핑몰에는 수많은 매장이 있습니다.

각 매장은 독립적으로 운영되지만, 고객이 매장 사이를 이동하려면 안내 데스크의 도움이 필요합니다. 안내 데스크는 "3층 화장품 코너는 왼쪽입니다", "주차장은 지하 2층입니다"처럼 길을 알려줍니다.

Istio도 마찬가지입니다. 쇼핑몰의 각 매장이 마이크로서비스라면, 안내 데스크가 바로 Istio입니다.

고객(트래픽)이 올바른 매장(서비스)으로 찾아갈 수 있도록 도와주는 것입니다. 왜 Istio가 필요한가 옛날에는 애플리케이션이 하나의 거대한 덩어리였습니다.

모놀리식 아키텍처라고 부르는데, 마치 모든 상품을 한 매장에서 파는 것과 같았습니다. 간단하긴 했지만, 규모가 커지면 관리가 어려웠습니다.

그래서 등장한 것이 마이크로서비스 아키텍처입니다. 애플리케이션을 작은 서비스들로 나누어 개발하고 배포합니다.

하지만 새로운 문제가 생겼습니다. 서비스가 10개, 100개로 늘어나면 어떻게 통신을 관리할까요?

어떤 서비스가 어디에 있는지 어떻게 알 수 있을까요? Istio의 등장 바로 이런 문제를 해결하기 위해 Istio가 등장했습니다.

Istio는 크게 두 부분으로 나뉩니다. 데이터 플레인과 컨트롤 플레인입니다.

데이터 플레인은 실제 트래픽이 흐르는 길이고, 컨트롤 플레인은 그 길을 관리하는 관제탑입니다. 데이터 플레인 - Envoy 프록시 데이터 플레인의 핵심은 Envoy 프록시입니다.

Envoy는 각 마이크로서비스 옆에 붙어서 모든 트래픽을 가로챕니다. 이것을 사이드카 패턴이라고 부릅니다.

마치 자동차 옆에 붙어있는 사이드카처럼, 애플리케이션 컨테이너 옆에 Envoy 컨테이너가 함께 배포됩니다. 애플리케이션이 다른 서비스를 호출하면, Envoy가 중간에서 요청을 받아 처리합니다.

Envoy는 단순히 트래픽을 전달하는 것이 아니라, 트래픽을 분석하고, 암호화하고, 재시도하고, 로드밸런싱까지 처리합니다. 개발자는 이런 복잡한 로직을 코드에 작성할 필요가 없습니다.

컨트롤 플레인 - Istiod 컨트롤 플레인의 핵심은 Istiod입니다. 예전에는 Pilot, Citadel, Galley라는 세 개의 컴포넌트로 나뉘어 있었는데, Istio 1.5 버전부터 하나로 통합되었습니다.

Istiod는 세 가지 중요한 역할을 합니다. 첫째, 서비스 디스커버리입니다.

Kubernetes의 서비스 정보를 읽어서 Envoy에게 전달합니다. "A 서비스는 IP 10.0.0.5에 있어요"라고 알려주는 것입니다.

둘째, 구성 관리입니다. 개발자가 작성한 트래픽 라우팅 규칙, 보안 정책 등을 Envoy에게 배포합니다.

마치 관제탑이 비행기에게 비행 경로를 알려주는 것과 같습니다. 셋째, 인증서 관리입니다.

서비스 간 통신을 암호화하기 위한 TLS 인증서를 자동으로 발급하고 갱신합니다. 개발자가 직접 인증서를 관리할 필요가 없습니다.

컴포넌트 확인하기 실제로 Istio를 설치하면 어떻게 보일까요? kubectl get pods -n istio-system 명령을 실행하면 istiod Pod가 실행 중인 것을 확인할 수 있습니다.

이것이 바로 컨트롤 플레인의 두뇌입니다. 그리고 애플리케이션이 배포된 네임스페이스에서 kubectl get pods를 실행하면 흥미로운 점을 발견할 수 있습니다.

READY 컬럼이 2/2로 표시됩니다. 하나의 Pod 안에 두 개의 컨테이너가 실행 중이라는 의미입니다.

하나는 애플리케이션 컨테이너, 다른 하나는 Envoy 사이드카 컨테이너입니다. 정리 박시니어 씨의 설명을 들은 김개발 씨는 고개를 끄덕였습니다.

"아, Istio는 마이크로서비스의 교통 관제 시스템이군요!" Istio의 컴포넌트 구조를 이해하면, 왜 이것이 강력한지 알 수 있습니다. 애플리케이션 코드를 수정하지 않고도 트래픽 관리, 보안, 모니터링을 모두 처리할 수 있기 때문입니다.

실전 팁

💡 - Istio 1.5 이전 버전에서는 Pilot, Citadel, Galley가 분리되어 있었지만, 현재는 모두 Istiod로 통합되었습니다

• Envoy 프록시는 C++로 작성된 고성능 프록시로, CNCF 졸업 프로젝트입니다

---

2. istioctl 설치

김개발 씨는 Istio를 사용하기로 결정했지만, 어디서부터 시작해야 할지 막막했습니다. 팀장님이 "먼저 istioctl부터 설치해봐"라고 말씀하셨는데, 이것이 무엇인지 궁금해졌습니다.

istioctl은 Istio를 설치하고 관리하는 공식 CLI 도구입니다. Istio를 Kubernetes 클러스터에 설치하고, 설정을 검증하며, 디버깅을 수행할 수 있습니다.

curl을 사용해 최신 버전을 다운로드하고, PATH에 추가하여 사용합니다.

다음 코드를 살펴봅시다.

# istioctl 최신 버전 다운로드 및 설치
curl -L https://istio.io/downloadIstio | sh -

# 다운로드한 디렉토리로 이동
cd istio-1.20.0

# istioctl을 PATH에 추가
export PATH=$PWD/bin:$PATH

# 설치 확인
istioctl version
# client version: 1.20.0

# istioctl 자동완성 설정 (bash 사용 시)
source <(istioctl completion bash)

김개발 씨는 터미널을 열고 어떻게 시작해야 할지 고민했습니다. Kubernetes는 kubectl로 관리하는데, Istio는 어떤 도구로 관리할까요?

바로 옆 자리의 이주니어 씨가 웃으며 말했습니다. "istioctl이요!

Istio의 모든 것을 관리하는 스위스 아미 나이프 같은 도구예요." istioctl이란 무엇인가 istioctl은 Istio를 위한 전용 명령줄 도구입니다. kubectl이 Kubernetes를 관리하는 것처럼, istioctl은 Istio를 관리합니다.

설치, 업그레이드, 설정 검증, 문제 진단까지 모든 작업을 처리할 수 있습니다. 비유하자면, istioctl은 자동차 정비사의 공구함과 같습니다.

엔진을 설치하고, 오일을 점검하고, 고장을 진단하는 모든 도구가 들어있습니다. 왜 별도의 도구가 필요한가 "kubectl만으로는 안 되나요?" 김개발 씨가 물었습니다.

kubectl로도 Istio 리소스를 배포할 수 있지만, istioctl을 사용하면 훨씬 편리합니다. istioctl은 Istio에 특화된 기능들을 제공하기 때문입니다.

예를 들어, Istio 설치 시 여러 프로파일 중 하나를 선택할 수 있습니다. 개발 환경용인지, 프로덕션 환경용인지에 따라 최적화된 설정을 자동으로 적용해줍니다.

kubectl로는 이런 작업이 매우 번거롭습니다. 또한 istioctl은 설정 오류를 사전에 검증해줍니다.

"이 VirtualService 설정이 문법에 맞나요?"라고 물어보면, 즉시 답을 줍니다. 배포하기 전에 오류를 잡을 수 있어서 시간을 크게 절약할 수 있습니다.

istioctl 설치하기 istioctl 설치는 놀라울 정도로 간단합니다. 공식 홈페이지에서 제공하는 스크립트 하나만 실행하면 됩니다.

curl -L https://istio.io/downloadIstio | sh - 명령을 실행하면, 자동으로 최신 버전을 다운로드합니다. 스크립트가 실행되면 현재 디렉토리에 istio-X.XX.X 형태의 폴더가 생성됩니다.

이 폴더 안에는 bin 디렉토리가 있고, 그 안에 istioctl 실행 파일이 들어있습니다. PATH 설정하기 istioctl을 어디서든 사용하려면 PATH에 추가해야 합니다.

export PATH=$PWD/bin:$PATH 명령을 실행하면, 현재 터미널 세션에서 istioctl을 사용할 수 있습니다. 하지만 터미널을 닫으면 설정이 사라집니다.

영구적으로 설정하려면 ~/.bashrc 또는 ~/.zshrc 파일에 같은 내용을 추가해야 합니다. 그러면 새로운 터미널을 열 때마다 자동으로 PATH가 설정됩니다.

설치 확인하기 설치가 제대로 되었는지 확인해봅시다. istioctl version 명령을 실행하면, 클라이언트 버전이 표시됩니다.

아직 Istio를 클러스터에 설치하지 않았다면, 서버 버전은 표시되지 않습니다. 이것은 정상입니다.

istioctl이 제대로 설치되었다면, 다양한 서브 커맨드를 사용할 수 있습니다. istioctl --help를 실행하면 사용 가능한 모든 명령이 나열됩니다.

자동완성 설정하기 개발자의 생산성을 높이는 작은 팁이 있습니다. 셸 자동완성을 설정하면, istioctl 명령을 입력할 때 Tab 키로 자동완성할 수 있습니다.

bash를 사용한다면 source <(istioctl completion bash) 명령을 실행하세요. zsh를 사용한다면 bash 대신 zsh를 입력하면 됩니다.

이것도 ~/.bashrc 또는 ~/.zshrc에 추가하면 영구적으로 적용됩니다. 다운로드 폴더의 구조 다운로드한 istio 폴더를 살펴보면 흥미로운 것들이 많습니다.

samples 디렉토리에는 다양한 예제 애플리케이션이 들어있습니다. 유명한 Bookinfo 애플리케이션도 여기에 있습니다.

실습할 때 매우 유용합니다. manifests 디렉토리에는 Istio 설치를 위한 Kubernetes YAML 파일들이 들어있습니다.

istioctl install 명령은 내부적으로 이 파일들을 사용합니다. 정리 이주니어 씨의 도움으로 김개발 씨는 무사히 istioctl을 설치했습니다.

"생각보다 간단하네요!" istioctl은 Istio를 사용하는 개발자의 필수 도구입니다. 한 번만 설치하면, Istio의 모든 기능을 손쉽게 사용할 수 있습니다.

실전 팁

💡 - istioctl은 Go로 작성된 단일 바이너리 파일이므로, 별도의 의존성 설치가 필요 없습니다

• 특정 버전을 설치하려면 환경변수 ISTIO_VERSION을 설정하세요: curl -L https://istio.io/downloadIstio | ISTIO_VERSION=1.19.0 sh -

---

3. Istio 프로파일

istioctl을 설치한 김개발 씨는 이제 Istio를 클러스터에 설치하려고 합니다. 그런데 공식 문서를 보니 "프로파일을 선택하세요"라는 문구가 나왔습니다.

default, demo, minimal... 도대체 무엇을 선택해야 할까요?

Istio 프로파일은 서로 다른 사용 사례에 최적화된 사전 정의된 설치 구성입니다. default 프로파일은 프로덕션 환경에 적합하고, demo 프로파일은 학습과 테스트에 적합하며, minimal 프로파일은 최소한의 컴포넌트만 설치합니다.

다음 코드를 살펴봅시다.

# 사용 가능한 모든 프로파일 목록 보기
istioctl profile list
# Istio configuration profiles:
#     default
#     demo
#     minimal
#     remote
#     empty
#     preview

# 특정 프로파일의 구성 내용 확인
istioctl profile dump demo

# 두 프로파일의 차이점 비교
istioctl profile diff default demo

# demo 프로파일로 Istio 설치
istioctl install --set profile=demo -y

김개발 씨는 프로파일이라는 개념이 낯설었습니다. "프로파일이 뭐죠?" 박시니어 씨에게 물었습니다.

박시니어 씨는 스마트폰을 꺼내며 설명을 시작했습니다. "휴대폰의 사운드 모드를 생각해보세요.

일반, 무음, 진동 모드가 있잖아요. 상황에 따라 선택하는 거죠." 프로파일의 개념 Istio 프로파일도 마찬가지입니다.

개발할 때, 테스트할 때, 실제 서비스할 때 필요한 설정이 다릅니다. 매번 복잡한 설정을 일일이 지정하는 대신, 상황에 맞는 프로파일을 선택하면 됩니다.

비유하자면, 프로파일은 레스토랑의 세트 메뉴와 같습니다. A 세트는 가볍게 먹고 싶은 사람용, B 세트는 푸짐하게 먹고 싶은 사람용입니다.

일일이 메뉴를 고를 필요 없이 세트를 선택하면 됩니다. 주요 프로파일 소개 Istio는 여러 가지 프로파일을 제공합니다.

default 프로파일은 프로덕션 환경에 적합합니다. Istiod와 Ingress Gateway가 설치되며, 리소스 사용량과 기능의 균형을 맞춘 구성입니다.

실제 서비스를 운영할 때 가장 많이 사용합니다. demo 프로파일은 학습과 실습에 최적화되어 있습니다.

Ingress Gateway뿐만 아니라 Egress Gateway도 함께 설치되며, 추적 기능과 로깅이 활성화되어 있습니다. 리소스를 많이 사용하지만, 모든 기능을 테스트하기에 좋습니다.

minimal 프로파일은 정말 최소한의 컴포넌트만 설치합니다. Istiod만 설치되고, Gateway는 설치되지 않습니다.

필요한 것만 골라서 추가 설치할 때 사용합니다. remote 프로파일은 멀티 클러스터 환경에서 사용합니다.

한 클러스터는 컨트롤 플레인을 실행하고, 다른 클러스터는 remote 프로파일로 설치하여 컨트롤 플레인에 연결합니다. 프로파일 확인하기 어떤 프로파일이 있는지 확인하려면 istioctl profile list 명령을 사용합니다.

목록이 출력되면, 각 프로파일의 자세한 내용을 확인할 수 있습니다. istioctl profile dump demo 명령을 실행하면, demo 프로파일의 전체 설정이 YAML 형식으로 출력됩니다.

매우 길기 때문에 처음에는 놀랄 수 있습니다. 프로파일 비교하기 두 프로파일의 차이가 궁금하다면 diff 명령을 사용합니다.

istioctl profile diff default demo를 실행하면, default와 demo 프로파일의 차이점이 표시됩니다. 어떤 컴포넌트가 추가되고, 어떤 설정이 다른지 한눈에 볼 수 있습니다.

김개발 씨는 diff 결과를 보고 깨달았습니다. "아, demo는 Egress Gateway와 추적 기능이 추가로 켜져 있네요!" 프로파일 선택 기준 그렇다면 어떤 프로파일을 선택해야 할까요?

처음 Istio를 배우는 단계라면 demo 프로파일을 추천합니다. 모든 기능을 사용해볼 수 있어서 학습에 최적화되어 있습니다.

공식 튜토리얼도 대부분 demo 프로파일을 기준으로 작성되어 있습니다. 개발 환경이나 테스트 환경에서는 default 프로파일이 적당합니다.

필요한 기능은 모두 있으면서, 리소스를 절약할 수 있습니다. 프로덕션 환경에서는 default 프로파일을 기반으로 필요한 부분을 커스터마이징합니다.

보안 설정, 리소스 제한, 고가용성 설정 등을 추가로 조정해야 합니다. 프로파일 커스터마이징 프로파일은 시작점일 뿐입니다.

필요에 따라 특정 값을 오버라이드할 수 있습니다. 예를 들어 demo 프로파일을 사용하되, 특정 컴포넌트의 리소스 제한을 조정하고 싶다면 --set 플래그를 사용합니다.

istioctl install --set profile=demo --set values.pilot.resources.requests.memory=1Gi -y 이런 식으로 특정 값만 변경할 수 있습니다. 정리 박시니어 씨의 설명을 듣고 김개발 씨는 결정을 내렸습니다.

"학습 단계니까 demo 프로파일로 시작하겠습니다!" 프로파일을 이해하면, 상황에 맞는 최적의 설정으로 Istio를 설치할 수 있습니다. 나중에 프로덕션 환경으로 이전할 때도 프로파일을 바꾸면 됩니다.

실전 팁

💡 - demo 프로파일은 학습용으로 좋지만, 프로덕션에서는 절대 사용하지 마세요. 보안과 리소스 최적화가 부족합니다

• 프로파일별 자세한 설정 차이는 공식 문서의 Installation Configuration Profiles 페이지를 참고하세요

---

4. 설치 및 확인

김개발 씨는 드디어 Istio를 설치할 준비가 되었습니다. istioctl도 설치했고, demo 프로파일을 선택했습니다.

이제 명령 하나만 실행하면 됩니다. 하지만 정말 제대로 설치되었는지 어떻게 확인할 수 있을까요?

Istio 설치는 istioctl install 명령으로 간단히 수행할 수 있습니다. 설치 후에는 istio-system 네임스페이스에 컨트롤 플레인 컴포넌트들이 배포되며, istioctl verify-install 명령으로 설치 상태를 검증할 수 있습니다.

다음 코드를 살펴봅시다.

# demo 프로파일로 Istio 설치
istioctl install --set profile=demo -y

# 설치 확인 - istio-system 네임스페이스의 Pod 상태 보기
kubectl get pods -n istio-system
# NAME                                    READY   STATUS    RESTARTS   AGE
# istiod-5c9d8f8d4b-x7k2p                 1/1     Running   0          2m
# istio-ingressgateway-7d8f9c6b5a-p4r2t   1/1     Running   0          2m
# istio-egressgateway-6f8d7c5b4a-m3n1k    1/1     Running   0          2m

# 설치 검증
istioctl verify-install

# Istio 버전 확인 (클라이언트 및 서버)
istioctl version

김개발 씨는 긴장하며 터미널에 명령을 입력했습니다. 과연 한 번에 성공할까요?

박시니어 씨가 옆에서 지켜보며 말했습니다. "걱정 마세요.

Istio 설치는 생각보다 간단해요. 문제가 생기면 제가 도와줄게요." Istio 설치 명령 실행 설치 명령은 놀라울 정도로 간단합니다.

istioctl install --set profile=demo -y 이 한 줄이면 됩니다. --set profile=demo 부분은 demo 프로파일을 사용하겠다는 의미이고, -y 플래그는 설치를 자동으로 진행하라는 의미입니다.

명령을 실행하면 istioctl이 Kubernetes 클러스터에 연결하여 Istio 컴포넌트들을 설치하기 시작합니다. 화면에 진행 상황이 표시되며, 보통 1-2분 정도 소요됩니다.

설치 과정에서 일어나는 일 내부적으로 무슨 일이 일어나는 걸까요? 먼저 istio-system이라는 새로운 네임스페이스가 생성됩니다.

Istio의 모든 컴포넌트는 이 네임스페이스에 배포됩니다. Kubernetes의 다른 리소스와 분리되어 관리됩니다.

다음으로 Istiod가 Deployment로 배포됩니다. 이것이 컨트롤 플레인의 핵심입니다.

Istiod는 서비스 디스커버리, 구성 배포, 인증서 관리를 담당합니다. demo 프로파일을 선택했기 때문에, Ingress Gateway와 Egress Gateway도 함께 설치됩니다.

Ingress Gateway는 클러스터 외부에서 들어오는 트래픽을 처리하고, Egress Gateway는 클러스터 외부로 나가는 트래픽을 처리합니다. 설치 확인하기 설치가 완료되었다는 메시지가 나오면, 실제로 확인해봅시다.

kubectl get pods -n istio-system 명령을 실행하면, istio-system 네임스페이스의 모든 Pod가 표시됩니다. READY 컬럼이 1/1로 표시되고, STATUS가 Running이면 정상입니다.

istiod, istio-ingressgateway, istio-egressgateway 세 개의 Pod가 보여야 합니다. 만약 CrashLoopBackOff나 Error 상태라면 문제가 있는 것입니다.

김개발 씨는 화면을 보고 안도했습니다. "다 Running이네요!" Service 확인하기 Pod뿐만 아니라 Service도 확인해야 합니다.

kubectl get svc -n istio-system 명령을 실행하면, Istio가 생성한 서비스들이 나열됩니다. istio-ingressgateway는 LoadBalancer 타입으로 생성되어, 클러스터 외부에서 접근할 수 있는 IP를 받습니다.

만약 클라우드 환경이라면 EXTERNAL-IP 컬럼에 실제 IP 주소가 표시됩니다. 로컬 환경(minikube 등)이라면 <pending> 상태일 수 있는데, 이것은 정상입니다.

설치 검증 명령 더 확실하게 확인하려면 istioctl verify-install 명령을 사용합니다. 이 명령은 Istio가 올바르게 설치되었는지 종합적으로 검증합니다.

모든 필수 컴포넌트가 배포되었는지, 설정이 올바른지, 버전이 일치하는지 등을 확인합니다. 검증이 완료되면 "Istio is installed and verified successfully"라는 메시지가 출력됩니다.

만약 오류가 발견되면, 어떤 부분에 문제가 있는지 상세히 알려줍니다. 버전 확인하기 istioctl version 명령을 실행하면 클라이언트와 서버의 버전을 모두 확인할 수 있습니다.

처음에는 클라이언트 버전만 표시되었지만, 이제는 서버 버전도 함께 표시됩니다. 두 버전이 일치하는지 확인하세요.

버전이 다르면 호환성 문제가 발생할 수 있습니다. CRD 확인하기 Istio는 다양한 Custom Resource Definition을 설치합니다.

kubectl get crd | grep istio 명령을 실행하면, Istio가 설치한 CRD 목록이 표시됩니다. VirtualService, DestinationRule, Gateway 등 Istio의 핵심 리소스들이 보입니다.

이 CRD들은 Istio의 트래픽 관리와 보안 정책을 정의하는 데 사용됩니다. 나중에 실제로 사용하게 될 것입니다.

문제 해결 만약 설치 중에 오류가 발생하면 어떻게 해야 할까요? 첫째, kubectl 명령으로 Pod의 로그를 확인합니다.

kubectl logs -n istio-system <pod-name>을 실행하면, 상세한 오류 메시지를 볼 수 있습니다. 둘째, Kubernetes 클러스터의 리소스가 충분한지 확인합니다.

Istio는 메모리와 CPU를 상당히 사용하므로, 작은 클러스터에서는 리소스 부족 문제가 발생할 수 있습니다. 셋째, 네트워크 정책이나 방화벽이 Istio의 통신을 차단하고 있는지 확인합니다.

정리 김개발 씨는 모든 확인을 마치고 환호했습니다. "성공했어요!" Istio 설치는 복잡해 보이지만, istioctl 덕분에 매우 간단합니다.

한 줄의 명령으로 전체 서비스 메시 플랫폼을 설치할 수 있습니다.

실전 팁

💡 - 설치 전에 Kubernetes 클러스터의 버전을 확인하세요. Istio는 Kubernetes 1.25 이상을 권장합니다

• 프로덕션 환경에서는 IstioOperator 리소스를 사용한 선언적 설치를 고려하세요

---

5. 사이드카 자동 주입

Istio를 설치한 김개발 씨는 이제 애플리케이션을 배포하려고 합니다. 그런데 박시니어 씨가 "네임스페이스에 레이블을 붙여야 해요"라고 말했습니다.

왜 그래야 할까요?

사이드카 자동 주입은 Istio가 애플리케이션 Pod에 Envoy 프록시를 자동으로 추가하는 기능입니다. 네임스페이스에 istio-injection=enabled 레이블을 붙이면, 해당 네임스페이스에 배포되는 모든 Pod에 Envoy 사이드카가 자동으로 주입됩니다.

다음 코드를 살펴봅시다.

# default 네임스페이스에 사이드카 자동 주입 활성화
kubectl label namespace default istio-injection=enabled

# 레이블 확인
kubectl get namespace -L istio-injection

# 이제 애플리케이션 배포
kubectl apply -f my-app.yaml

# Pod 확인 - 2개의 컨테이너가 실행 중
kubectl get pods
# NAME                     READY   STATUS    RESTARTS   AGE
# myapp-7d8f9c6b5a-p4r2t   2/2     Running   0          30s

# Pod의 상세 정보로 사이드카 확인
kubectl describe pod myapp-7d8f9c6b5a-p4r2t | grep istio-proxy

김개발 씨는 애플리케이션 Deployment YAML 파일을 준비했습니다. 이제 배포만 하면 될 것 같은데, 박시니어 씨가 잠깐 멈추라고 합니다.

"잠깐만요! 배포하기 전에 네임스페이스에 레이블을 붙여야 해요.

그래야 Istio가 제대로 작동합니다." 사이드카 주입이란 Istio의 핵심은 Envoy 프록시입니다. 모든 트래픽이 Envoy를 거쳐야 Istio가 트래픽을 관리할 수 있습니다.

그렇다면 어떻게 Envoy를 각 애플리케이션 옆에 붙일 수 있을까요? 두 가지 방법이 있습니다.

첫째는 수동 주입, 둘째는 자동 주입입니다. 수동 주입은 istioctl kube-inject 명령을 사용해 YAML 파일을 수정한 후 배포하는 방식입니다.

번거롭고, 실수하기 쉽습니다. 자동 주입은 Kubernetes의 Admission Controller를 사용합니다.

네임스페이스에 특별한 레이블만 붙이면, 그 네임스페이스에 배포되는 모든 Pod에 자동으로 Envoy가 추가됩니다. 훨씬 편리합니다.

자동 주입의 원리 자동 주입은 마법이 아니라 기술입니다. Kubernetes에는 Mutating Admission Webhook이라는 기능이 있습니다.

Pod가 생성되기 직전에, 외부 서비스가 Pod의 정의를 수정할 수 있는 기능입니다. Istio는 이 기능을 활용합니다.

Istio 설치 시 MutatingWebhookConfiguration이라는 리소스가 생성되며, 이것이 Istiod를 가리킵니다. Pod가 생성되려고 하면, Kubernetes는 먼저 Istiod에게 물어봅니다.

"이 Pod를 수정할 게 있나요?" Istiod는 네임스페이스의 레이블을 확인하고, istio-injection=enabled가 있으면 Envoy 컨테이너를 추가합니다. 레이블 붙이기 자동 주입을 활성화하려면 네임스페이스에 레이블을 붙여야 합니다.

kubectl label namespace default istio-injection=enabled 명령을 실행하면, default 네임스페이스에 레이블이 추가됩니다. 다른 네임스페이스를 사용한다면 default 대신 해당 네임스페이스 이름을 입력하세요.

레이블이 제대로 붙었는지 확인하려면 kubectl get namespace -L istio-injection 명령을 사용합니다. istio-injection 컬럼에 enabled가 표시되면 성공입니다.

애플리케이션 배포하기 이제 평소처럼 애플리케이션을 배포하면 됩니다. kubectl apply -f my-app.yaml 명령을 실행하면, Deployment가 생성되고 Pod가 시작됩니다.

특별히 다른 것은 없습니다. 하지만 kubectl get pods를 실행하면 흥미로운 점을 발견할 수 있습니다.

READY 컬럼이 2/2로 표시됩니다. 원래는 1/1이어야 하는데 말이죠.

사이드카 확인하기 왜 2/2일까요? 하나의 Pod 안에 두 개의 컨테이너가 실행 중이기 때문입니다.

하나는 여러분이 작성한 애플리케이션 컨테이너, 다른 하나는 Istio가 자동으로 추가한 istio-proxy 컨테이너입니다. kubectl describe pod <pod-name> 명령으로 상세 정보를 확인하면, Containers 섹션에 두 개의 컨테이너가 나열됩니다.

애플리케이션 컨테이너와 istio-proxy 컨테이너입니다. istio-proxy는 Envoy 프록시를 실행합니다.

모든 인바운드 트래픽과 아웃바운드 트래픽이 이 컨테이너를 거쳐갑니다. Init Container 사이드카만 추가되는 것이 아닙니다.

Init Containers 섹션을 보면 istio-init이라는 컨테이너가 있습니다. 이것은 Pod가 시작될 때 한 번만 실행되는 초기화 컨테이너입니다.

istio-init의 역할은 iptables 규칙을 설정하는 것입니다. Pod의 네트워크 트래픽을 가로채서 Envoy로 리다이렉트하도록 설정합니다.

이 작업이 완료되면 컨테이너는 종료됩니다. 자동 주입 제외하기 특정 Pod는 사이드카가 필요 없을 수도 있습니다.

예를 들어, 데이터베이스나 캐시 같은 외부 서비스는 Istio 메시의 일부가 아닐 수 있습니다. 이런 경우 Pod에 sidecar.istio.io/inject: "false" 어노테이션을 추가하면 자동 주입을 건너뜁니다.

annotations: sidecar.istio.io/inject: "false" 이 어노테이션을 추가하면, 네임스페이스에 istio-injection=enabled가 있더라도 해당 Pod에는 사이드카가 주입되지 않습니다. 기존 Pod에 사이드카 추가하기 이미 실행 중인 Pod에는 어떻게 해야 할까요?

Kubernetes의 Admission Webhook은 Pod가 생성될 때만 작동합니다. 이미 실행 중인 Pod를 수정하지는 않습니다.

따라서 레이블을 붙인 후에는 기존 Pod를 재시작해야 합니다. kubectl rollout restart deployment <deployment-name> 명령을 실행하면, Deployment의 모든 Pod가 재생성되며 사이드카가 주입됩니다.

정리 박시니어 씨의 도움으로 김개발 씨는 성공적으로 사이드카를 주입했습니다. "이제 모든 트래픽이 Envoy를 거치는군요!" 사이드카 자동 주입은 Istio 사용의 핵심입니다.

한 줄의 레이블만으로 모든 애플리케이션을 서비스 메시에 통합할 수 있습니다.

실전 팁

💡 - 개발 초기에는 특정 네임스페이스만 사이드카를 활성화하고, 점진적으로 확대하세요

• 사이드카는 메모리를 약 50-100MB 정도 추가로 사용하므로, 리소스 제한을 조정해야 할 수 있습니다

---

6. Envoy 프록시

김개발 씨는 사이드카가 주입된 Pod를 보며 궁금해졌습니다. "istio-proxy가 정확히 뭘 하는 거죠?

그냥 트래픽을 전달만 하나요?" 박시니어 씨는 웃으며 말했습니다. "그것보다 훨씬 많은 일을 해요.

Envoy는 서비스 메시의 실질적인 일꾼이거든요."

Envoy 프록시는 Istio 데이터 플레인의 핵심으로, C++로 작성된 고성능 L7 프록시입니다. 트래픽 라우팅, 로드밸런싱, 서킷 브레이킹, 재시도, 타임아웃, 메트릭 수집 등 다양한 기능을 제공하며, Istiod로부터 동적으로 설정을 받아 적용합니다.

다음 코드를 살펴봅시다.

# Envoy 프록시의 설정 확인
istioctl proxy-config cluster <pod-name> -n default

# Envoy의 라우팅 규칙 확인
istioctl proxy-config route <pod-name> -n default

# Envoy의 리스너 확인
istioctl proxy-config listener <pod-name> -n default

# Envoy 로그 확인
kubectl logs <pod-name> -c istio-proxy -n default

# Envoy 관리 인터페이스에 접근 (포트 포워딩)
kubectl port-forward <pod-name> 15000:15000 -n default
# 브라우저에서 localhost:15000으로 접속

김개발 씨는 istio-proxy 컨테이너 안에서 무슨 일이 일어나는지 알고 싶었습니다. 겉으로는 단순해 보이지만, 내부는 복잡할 것 같았습니다.

박시니어 씨는 화이트보드를 꺼내 그림을 그리기 시작했습니다. "Envoy를 이해하려면 먼저 프록시가 무엇인지 알아야 해요." 프록시의 개념 프록시는 중개자입니다.

비유하자면, 프록시는 비서와 같습니다. 사장님께 직접 전화하는 대신, 비서에게 전화를 걸면 비서가 사장님께 연결해줍니다.

비서는 전화를 걸기 전에 "지금 사장님이 회의 중이니 나중에 다시 전화해주세요"라고 말할 수도 있고, "이 내용은 제가 처리하겠습니다"라고 말할 수도 있습니다. Envoy도 마찬가지입니다.

애플리케이션이 다른 서비스에 요청을 보내면, Envoy가 중간에서 가로챕니다. 요청을 그대로 전달할 수도 있고, 수정할 수도 있고, 거부할 수도 있습니다.

L7 프록시의 의미 Envoy는 Layer 7 프록시입니다. 네트워크는 7개의 계층으로 이루어져 있습니다.

Layer 4는 TCP/UDP 같은 전송 계층이고, Layer 7은 HTTP 같은 애플리케이션 계층입니다. L7 프록시는 HTTP 헤더, URL, 메서드 등을 이해합니다.

따라서 "/api/users로 가는 요청은 서버 A로, /api/products로 가는 요청은 서버 B로" 같은 세밀한 라우팅이 가능합니다. Envoy의 주요 기능 Envoy는 놀라울 정도로 많은 기능을 제공합니다.

첫째, 트래픽 라우팅입니다. URL, 헤더, 쿠키 등을 기반으로 요청을 원하는 곳으로 보낼 수 있습니다.

A/B 테스팅이나 카나리 배포에 매우 유용합니다. 둘째, 로드밸런싱입니다.

하나의 서비스에 여러 인스턴스가 있을 때, 요청을 균등하게 분산합니다. 라운드 로빈, 랜덤, 최소 요청 수 등 다양한 알고리즘을 지원합니다.

셋째, 재시도와 타임아웃입니다. 요청이 실패하면 자동으로 재시도하고, 응답이 너무 느리면 타임아웃 처리합니다.

네트워크의 일시적인 문제를 애플리케이션이 직접 처리할 필요가 없습니다. 넷째, 서킷 브레이킹입니다.

특정 서비스가 계속 실패하면, 더 이상 요청을 보내지 않고 즉시 실패 응답을 반환합니다. 장애가 전파되는 것을 막습니다.

다섯째, TLS 암호화입니다. 서비스 간 통신을 자동으로 암호화하여 보안을 강화합니다.

애플리케이션 코드를 수정할 필요가 없습니다. 여섯째, 메트릭 수집입니다.

모든 요청과 응답에 대한 통계를 수집합니다. 응답 시간, 에러율, 트래픽 양 등을 모니터링할 수 있습니다.

Envoy의 동적 설정 Envoy의 강력한 점은 동적 설정입니다. 전통적인 프록시는 설정 파일을 수정하고 재시작해야 합니다.

하지만 Envoy는 실행 중에 설정을 변경할 수 있습니다. Istiod는 xDS(Discovery Service) API를 통해 Envoy에게 설정을 전달합니다.

새로운 서비스가 추가되면, Istiod가 감지하고 모든 Envoy에게 업데이트된 설정을 푸시합니다. Envoy는 재시작 없이 새로운 설정을 적용합니다.

Envoy 설정 확인하기 istioctl을 사용하면 Envoy의 설정을 확인할 수 있습니다. istioctl proxy-config cluster <pod-name> 명령을 실행하면, Envoy가 알고 있는 모든 클러스터(대상 서비스) 목록이 표시됩니다.

어떤 서비스가 어느 IP에 있는지 한눈에 볼 수 있습니다. istioctl proxy-config route <pod-name> 명령을 실행하면, 라우팅 규칙이 표시됩니다.

어떤 URL이 어떤 클러스터로 전달되는지 확인할 수 있습니다. istioctl proxy-config listener <pod-name> 명령을 실행하면, Envoy가 수신 대기 중인 포트와 프로토콜이 표시됩니다.

Envoy 관리 인터페이스 Envoy는 관리용 HTTP 서버를 내장하고 있습니다. 기본적으로 15000번 포트에서 실행되며, 다양한 디버깅 정보를 제공합니다.

포트 포워딩을 사용해 로컬에서 접근할 수 있습니다. kubectl port-forward <pod-name> 15000:15000 명령을 실행한 후, 웹 브라우저에서 localhost:15000을 열면 관리 페이지가 표시됩니다.

/config_dump 엔드포인트는 전체 설정을 JSON 형식으로 반환합니다. 매우 길지만, Envoy가 정확히 어떻게 설정되어 있는지 알 수 있습니다.

/stats 엔드포인트는 실시간 통계를 제공합니다. 요청 수, 성공률, 응답 시간 등 수많은 메트릭을 볼 수 있습니다.

Envoy 로그 확인하기 문제가 발생하면 Envoy 로그를 확인해야 합니다. kubectl logs <pod-name> -c istio-proxy 명령을 실행하면, istio-proxy 컨테이너의 로그가 출력됩니다.

연결 오류, 타임아웃, 재시도 등의 정보가 기록됩니다. 로그 레벨을 동적으로 변경할 수도 있습니다.

istioctl을 사용하면 재시작 없이 로그 레벨을 debug로 올릴 수 있습니다. Envoy의 성능 Envoy는 C++로 작성되어 매우 빠릅니다.

일반적으로 요청당 1-2ms의 오버헤드만 추가됩니다. 대부분의 경우 이것은 무시할 수 있는 수준입니다.

네트워크 지연이나 애플리케이션 처리 시간에 비하면 매우 작기 때문입니다. 또한 Envoy는 비동기 I/O를 사용하여 수천 개의 동시 연결을 효율적으로 처리할 수 있습니다.

정리 박시니어 씨의 설명을 듣고 김개발 씨는 감탄했습니다. "Envoy가 이렇게 많은 일을 하는 줄 몰랐어요!" Envoy 프록시는 Istio의 심장입니다.

컨트롤 플레인이 두뇌라면, Envoy는 근육입니다. 실제로 트래픽을 처리하고, 정책을 적용하고, 메트릭을 수집하는 모든 일을 Envoy가 담당합니다.

실전 팁

💡 - Envoy의 메트릭은 Prometheus 형식으로 노출되므로, Prometheus와 Grafana로 쉽게 모니터링할 수 있습니다

• 프로덕션 환경에서는 Envoy의 리소스 제한을 적절히 설정하세요. 기본값은 대부분의 경우 충분하지만, 트래픽이 많으면 조정이 필요할 수 있습니다

---

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!