Istio의 내부 아키텍처, Ambient 모드와 사이드카 모드의 비교, 설치와 기본 설정까지 Istio의 핵심을 깊이 있게 분석합니다.
Istio는 2017년 Google, IBM, Lyft가 공동으로 발표한 이후 서비스 메시의 대명사로 자리 잡았습니다. CNCF Graduated 프로젝트로서 가장 풍부한 기능 세트와 가장 큰 커뮤니티를 보유하고 있습니다. 이 장에서는 Istio의 아키텍처를 심층 분석하고, 2024년 GA에 도달한 Ambient 모드를 중심으로 현대적인 Istio 활용법을 살펴보겠습니다.
Istio의 아키텍처는 컨트롤 플레인과 데이터 플레인으로 나뉘며, 두 가지 운영 모드를 제공합니다.
전통적인 방식으로, 각 Pod에 Envoy 사이드카를 자동 주입합니다. Istiod가 모든 Envoy에 xDS 설정을 푸시합니다.
2024년 11월 GA에 도달한 새로운 방식입니다. 사이드카를 제거하고 두 계층으로 분리합니다.
ztunnel(Zero Trust Tunnel)은 Rust로 작성된 경량 프록시로, 각 노드에 DaemonSet으로 배포됩니다.
핵심 기능:
제공하지 않는 기능:
apiVersion: v1
kind: Namespace
metadata:
name: my-app
labels:
istio.io/dataplane-mode: ambient # Ambient 모드 활성화이 라벨 하나로 해당 네임스페이스의 모든 Pod 트래픽이 자동으로 ztunnel을 통과하며, mTLS가 적용됩니다. 애플리케이션 Pod를 재시작할 필요도 없습니다.
L7 기능이 필요한 서비스에만 웨이포인트 프록시를 배포합니다. 네임스페이스 단위 또는 서비스 단위로 생성할 수 있습니다.
# 네임스페이스 단위 Waypoint 생성
istioctl waypoint apply -n my-app
# 특정 서비스에만 Waypoint 적용
istioctl waypoint apply -n my-app --name reviews-waypointWaypoint 프록시는 Kubernetes Gateway API를 사용하여 배포됩니다.
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
name: my-app-waypoint
namespace: my-app
labels:
istio.io/waypoint-for: service
spec:
gatewayClassName: istio-waypoint
listeners:
- name: mesh
port: 15008
protocol: HBONE벤치마크 결과에 따르면 Ambient 모드는 사이드카 대비 극적인 성능 개선을 보여줍니다.
| 지표 | 사이드카 모드 | Ambient (L4만) | Ambient (L4+L7) |
|---|---|---|---|
| mTLS 지연 오버헤드 | 166% | 8% | ~40% |
| Pod당 메모리 | ~50MB | 0 (공유) | Waypoint 공유 |
| Pod 시작 시간 영향 | +2~5초 | 없음 | 없음 |
| 초당 쿼리 (QPS/코어) | 기준값 | +56% | +20% |
Ambient 모드의 핵심 가치는 "점진적 도입"입니다. 모든 서비스에 mTLS를 무비용으로 적용하고(L4), HTTP 라우팅이나 인가 같은 고급 기능이 필요한 서비스에만 Waypoint를 추가하면 됩니다.
Istio는 Kubernetes CRD(Custom Resource Definition)를 통해 트래픽 관리, 보안, 관측 정책을 선언적으로 정의합니다.
서비스로 들어오는 트래픽의 라우팅 규칙을 정의합니다.
apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
name: reviews
spec:
hosts:
- reviews
http:
- match:
- headers:
end-user:
exact: jason
route:
- destination:
host: reviews
subset: v2
- route:
- destination:
host: reviews
subset: v1이 예시는 end-user: jason 헤더가 있는 요청을 v2로, 나머지를 v1으로 라우팅합니다.
대상 서비스에 대한 트래픽 정책(로드 밸런싱, 서킷 브레이커, 서브셋)을 정의합니다.
apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
name: reviews
spec:
host: reviews
trafficPolicy:
connectionPool:
tcp:
maxConnections: 100
http:
h2UpgradePolicy: DEFAULT
http1MaxPendingRequests: 100
outlierDetection:
consecutive5xxErrors: 5
interval: 30s
baseEjectionTime: 30s
subsets:
- name: v1
labels:
version: v1
- name: v2
labels:
version: v2서비스 간 접근 제어 정책을 정의합니다.
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
name: reviews-policy
namespace: my-app
spec:
selector:
matchLabels:
app: reviews
action: ALLOW
rules:
- from:
- source:
principals: ["cluster.local/ns/my-app/sa/productpage"]
to:
- operation:
methods: ["GET"]
paths: ["/reviews/*"]이 정책은 productpage 서비스 어카운트에서 오는 GET 요청만 reviews 서비스에 허용합니다.
mTLS 모드를 설정합니다.
apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
name: default
namespace: istio-system
spec:
mtls:
mode: STRICT # 모든 트래픽에 mTLS 강제Istio는 istioctl을 통해 설치하며, 용도에 따른 설치 프로파일을 제공합니다.
# Ambient 프로파일로 설치 (권장)
istioctl install --set profile=ambient -y
# 설치 확인
istioctl verify-install
kubectl get pods -n istio-system주요 설치 프로파일:
| 프로파일 | 구성 | 용도 |
|---|---|---|
ambient | Istiod + ztunnel + istio-cni | Ambient 모드 (권장) |
default | Istiod + Ingress Gateway | 사이드카 모드 기본 |
demo | 모든 컴포넌트 + 트레이싱 | 데모/학습 |
minimal | Istiod만 | 커스텀 구성의 시작점 |
Istio는 전통적인 자체 CRD(VirtualService, Gateway) 외에도 Kubernetes Gateway API를 지원합니다. Gateway API는 Kubernetes 표준으로 자리 잡고 있어, 향후 Istio CRD보다 Gateway API가 주된 설정 방식이 될 전망입니다.
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
name: reviews-route
spec:
parentRefs:
- name: my-gateway
rules:
- matches:
- path:
type: PathPrefix
value: /reviews
backendRefs:
- name: reviews-v1
port: 8080
weight: 90
- name: reviews-v2
port: 8080
weight: 10신규 프로젝트에서는 Gateway API를 우선 사용하는 것을 권장합니다. Istio의 VirtualService/DestinationRule은 Gateway API로 표현하기 어려운 고급 기능(세밀한 폴트 인젝션, 미러링 등)에만 보조적으로 사용하세요.
다음 장에서는 Istio의 트래픽 관리 기능을 실전 시나리오와 함께 깊이 있게 다루겠습니다.
이 글이 도움이 되셨나요?
Istio의 트래픽 관리 기능을 실전 시나리오로 살펴봅니다. 가중치 기반 라우팅, 카나리 배포, 서킷 브레이커, 폴트 인젝션, 트래픽 미러링까지.
서비스 메시의 핵심 구성요소인 데이터 플레인과 컨트롤 플레인의 역할, Envoy 프록시의 내부 구조, 그리고 다양한 배포 모델을 분석합니다.
Linkerd의 설계 철학, Rust 기반 마이크로 프록시 아키텍처, 설치와 운영, 그리고 Istio와의 비교를 통해 Linkerd의 강점을 분석합니다.