[K8S] Service Mesh와 Istio

개요

---

Service Mesh와 Istio에 대해 이해한다.

 

 

1. Service Mesh

---

1.1. Service Mesh가 필요한 이유

MSA 환경에서는 서비스가 수십 개로 쪼개지면서, 서비스 간 통신에 필요한 일들 (retry, timeout, 라우팅, mTLS(서비스 간 암호화) 등)을 모두 앱이 각자 코드로 떠안아야 하는 문제가 생긴다. 파편화되는 만큼 Request의 추적이 어렵고 서비스 간의 순환 호출 등의 문제가 발생해 장애 여파가 커지기도 한다.

 

1.2. Service Mesh를 통해 해결할 수 있는 것

핵심은 단순하게 모든 서비스 간 트래픽이 프록시(Envoy)를 한 번 거치게 된다는 것이다. 트래픽이 반드시 지나야 하는 길목이 생기면, 그 길목에서 통신을 제어하고 들여다보는 일이 전부 가능해진다. 1.1에서 앱이 각자 떠안아야 했던 일들이 이 프록시 계층으로 옮겨간다.

 

1.3. Service Mesh 구조

Service Mesh는 공통적으로 두 개의 Plane으로 나뉜다. 

 

1.3.1. Control Plane

• 메시의 두뇌 역할로, Istio Proxy를 제어한다. 선언된 정책(라우팅 규칙, 보안 정책 등)을 받아서, 각 프록시(data plane)가 이해할 수 있는 설정으로 변환해 내려준다. 
• Control Plane은 실제 트래픽을 받지 않는다.

1.3.1. Data Plane

• 실제 트래픽을 처리하는 프록시들의 집합이다.

즉, 정책은 중앙에서 선언(Control Plane)하고, 실행은 분산된 프록시가 담당(Data Plane)한다. 이 관심사 분리 덕분에 앱 코드를 바꾸지 않고도 통신 정책을 중앙에서 일괄 제어할 수 있게 된다.

 

 

2. Istio

---

Istio는 위 Service Mesh 구조를 구현한 대표적인 오픈소스다. Control Planed으로는 istiod를, Data Plane으로는 Envoy 프록시를 사용한다.

 

2.1. Istio 구조

Istio Architecture

 

istio-proxy라는 컨테이너가 각 Pod에 sidecar 패턴으로 뜨고, 해당 컨테이너에 프로세스 형태로 pilot-agent, envoy가 구성된다.

 

2.2. Control Plane: istiod

Istio Control Plane은 v1.5를 기준으로 구조가 크게 바뀌었다. 와 복잡.. 하지만 이걸 이해해야 istiod를 알 수 있으니, 차근히 살펴보자.

 

2.2.1. v1.5 이전, 분리 구조

Control Plane이 Pilot / Mixer / Citadel / Galley 4개의 독립 컴포넌트로 각각 떠 있다.

https://istio.io/v1.4/docs/ops/deployment/architecture/

 

✔ Galley

Galley는 Istio 컨트롤 플레인에서 설정 관리를 담당하는 컴포넌트다. 공식 문서 표현으로는 설정의 검증(validation)·수집(ingestion)·가공(processing)·배포(distribution)를 맡는다. 즉, 관리자가 써놓은 설정을 받아서 검사하고 다듬은 뒤, 나머지 컴포넌트(Pilot 등)에 나눠주는 역할이다.

• 설정 수집
  • 관리자는 Istio 설정을 대부분 쿠버네티스 리소스 형태(CRD, 예: VirtualService, DestinationRule, Gateway 등)로 정의한다. Galley는 Kubernetes API Server에서 이 설정들을 읽어와 수집한다.
  • 나머지 컴포넌트는 그 과정을 몰라도 되게 격리한다.
• 설정 검증
  • 수집한 설정이 문법적·논리적으로 올바른지 검사한다.
  • 관리자가 kubectl apply로 잘못된 설정을 넣으려는 바로 그 시점에 거부할 수 있다. 
• 가공 및 배포
  • 검증을 통과한 설정을 컴포넌트들이 소비하기 좋은 표준 내부 형태로 가공한 뒤, Pilot 같은 다른 컴포넌트에 배포한다.

 

✔ Pilot

Pilot은 Istio 컨트롤 플레인에서 트래픽 관리(traffic management)와 서비스 디스커버리(service discovery)를 담당하는 컴포넌트다.

• Service Discovery
  • Kubernetes 환경에서는 Pod가 수시로 생성·삭제되며 각 Pod의 IP가 계속 바뀐다. Pilot은 Kubernetes API Server를 통해 이 정보를 감지하고, 엔드포인트(ip 정보)를 최신 상태로 유지한다.
  • 플랫폼마다 다른 디스커버리 방식을 추상화해 Envoy가 이해할 수 있는 표준 포맷으로 변환한다.
• 설정 변환 + 배포
  • 관리자가 정의한 상위 레벨 라우팅 규칙(VirtualService, DestincationRule 등)을 Envoy 전용 설정으로 변환하고, 이를 각 Pod의 Envoy 사이드카 프록시에 런타임으로 전파한다. (이 전파에 쓰이는 프로토콜이 xDS (CDS/RDS/EDS/LDS 각 용도에 맞게 변환))

 

✔ Citadel

Citadel은 컨트롤 플레인에서 보안을 담당한다. 서비스 간 통신을 mTLS로 암호화·인증할 수 있도록, 각 워크로드에 인증서를 발급·관리하는 CA(인증기관) 역할을 한다.

 

 

2.2.2. Pilot / Citadel / Galley는 istiod로 통합

Pilot / Citadel / Galley가 istiod라는 단일 바이너리로 통합되었고, Mixer는 Deprecated되었다. 지금은 istio-system 네임스페이스에 istiod Deployment 하나로 뜬다.

 

Mixer가 하던 일은 Deprecated

매 요청마다 Envoy가 Mixer로 `이 요청 허용 가능?` `이 지표 기록`과 같은 호출을 하면서 네트워크 왕복이 발생 → 비효율을 없애기 위해 해당 기능을 Envoy 안으로 밀어 넣게 됨

기존	대체
App 간 통신 허용 및 차단(Access Control)	Authorization Policy - Envoy 네이티브 인가 (RBAC)로 처리, 설정은 istiod가 배포
Rate Limit	Envoy 자체 기능 (local rate limit)
Metric 수집 및 중계	Telemetry v2 : 프록시가 메트릭을 직접 노출하고, Prometheus가 프록시에서 직접 스크랩

 

 

2.3. Data Plane

2.3.1. pilot-agent (프로세스)

 

pilot-agent는 Envoy를 부트스트랩하는 에이전트다. 각 Pod마다 Envoy 프록시와 같은 컨테이너에서 나란히 동작하면서, Envoy를 초기화·관리하는, Envoy의 Control Plane 역할을 한다. [istio docs]

Envoy와 같은 컨테이너에서 나란히 동작한다는 것의 의미:

istio-proxy 라는 컨테이너 사이드카 내부에서...
- pilot-agent (PID 1, 부모 프로세스)
- envoy (자식 프로세스)
형태를 갖는다.

 

• Envoy bootstrap: Envoy 프로세스를 시작하고 초기 설정(config)을 생성 및 주입
• 트래픽 리다이렉션 설정: iptables를 통해 inbound/outbound 트래픽을 Envoy로 우회
• xDS 프록시: Control Plane(istiod)과 Envoy 사이에서 xDS(설정) 전달을 중계
• 보안/인증서 관리: 인증서 발급·갱신,  istiod로 부터 내려오는 xDS 설정을 받아 Envoy에 반영하고, 인증서를 받아 mTLS에 쓰도록 전달
• 헬스체크·생명주기: Envoy 상태 확인, Pod 종료 시 graceful shutdown 등의 처리

 

2.3.2. Envoy (프로세스)

Istio의 Data Plane은 Envoy 프록시로 이뤄진다. Envoy는 Mesh 내부의 모든 서비스의 inbound/outbound 트래픽을 전부 중개한다. Istio 컴포넌트 중 실제 Data Plane 트래픽과 직접 상호작용하는 건 오직 Envoy 뿐이다. 

 

Envoy는 각 서비스 옆에 사이드카 패턴으로 배포되어, 서비스가 원래갖고 있지 않던 네트워크 기능들을 앱 단의 코드 수정 없이 얹어준다. Envoy는 Control Plane(istiod)이 내려주는 설정 대로, 다음과 같은 일을 한다.

• 트래픽 제어: 로드밸런싱, HTTP/2·gRPC 프록시, %기반 트래픽 분할(단계적 롤아웃)
• Resiliency(복원력): 서킷 브레이커, 헬스 체크, retry, failover, fault injection
• 보안: TLS termination, 접근 제어 및 rate limiting
• observability: 메트릭 수집

 

3. 실제 Cluster에 Istio 설정하기

---

3.1. istiod(Control Plane) 설정 

1) istioctl 설치

# 최신 릴리스 자동 다운로드 (특정 버전은 ISTIO_VERSION 지정)
curl -L https://istio.io/downloadIstio | sh -
cd istio-*
export PATH=$PWD/bin:$PATH

istioctl version

 

2) demo 프로파일 설치

istioctl install --set profile=demo -y
# ✔ Istio core installed
# ✔ Istiod installed
# ✔ Ingress gateways installed
# ✔ Egress gateways installed
# ✔ Installation complete

 

istio는 용도별로 여러 프로파일을 제공한다. [istio docs]

• default: 운영(프로덕션)용 최소 구성
• demo: 학습·테스트용으로 거의 모든 기능을 켜서, 관측성이 높게 설계된다.
• minimal: 컨트롤 플레인만 설치

 

3) 설치 확인

kubectl get pods -n istio-system

 

설치가 끝난 상태에서 구성요소를 확인한다. Istio 관련 파드는 모두 istio-system 네임스페이스에 배포된다. Ingress Gateway는 클러스터 외부 → 내부로의 진입점이고, Egress는 그 반대다.

 

여기까지가 Control Plane 배포다. 아직 Data Plane은 없다: 사이드카(Data Plane, Envoy)는 Pod가 뜰 때 주입되기 때문이다.

 

마치며

---

이번 글에서는

• Service Mesh가 왜 필요한지
• Istio가 이를 Control/Data Plane으로 어떻게 구현하는지
• kind Cluster에 Control Plane을 실제로 설치하는 것

까지 확인했다. 다음 글에서 실제 앱과 Sidecar를 띄우며 Data Plane인 Envoy에 대해 살펴보도록 한다.