AWS 기술 블로그
Amazon EKS에서 Istio Ambient Mode 구축하여 리소스 효율성 확보하기
소개
마이크로서비스 아키텍처가 널리 채택되면서 서비스 간 통신의 보안, 관찰성, 트래픽 관리가 점점 더 중요해지고 있습니다. Istio는 이러한 요구사항을 충족하는 가장 성숙하고 널리 사용되는 오픈소스 서비스 메시 솔루션으로, 상호 TLS(mTLS) 기반 암호화 통신, 세밀한 트래픽 제어, 그리고 포괄적인 관찰성 기능을 제공합니다.
Amazon Elastic Kubernetes Service(EKS)는 AWS에서 관리형 Kubernetes 서비스를 제공하며, 컨트롤 플레인의 가용성과 확장성을 자동으로 관리합니다. 많은 고객들이 EKS에서 마이크로서비스 애플리케이션을 실행하면서 서비스 간 통신의 보안과 관찰성을 강화하기 위해 Istio를 도입하고 있습니다. 전통적인 Istio의 사이드카 패턴은 EKS 환경에서 몇 가지 운영상의 과제를 제시합니다.
전통적인 Istio 아키텍처는 각 Pod에 Envoy 프록시를 사이드카 컨테이너로 주입하는 방식을 사용해왔습니다. 이 접근 방식은 강력한 기능을 제공하지만, EKS 환경에서 다음과 같은 운영상의 과제를 동반합니다. 첫째, Pod 수가 증가할수록 사이드카 프록시가 소비하는 CPU와 메모리 리소스가 선형적으로 증가하여 EKS 노드의 컴퓨팅 비용이 증가합니다. 둘째, 애플리케이션 Pod를 배포하거나 업데이트할 때마다 사이드카 주입을 위한 재시작이 필요하여 배포 시간이 길어지고 서비스 중단 시간이 발생할 수 있습니다. 셋째, 각 Pod마다 독립적인 프록시를 관리해야 하므로 운영 복잡도가 높아지며, 특히 대규모 EKS 클러스터에서는 수백 개의 프록시를 모니터링하고 업데이트해야 하는 부담이 있습니다.
Istio 1.22부터 정식으로 도입된 Ambient Mode는 이러한 문제를 근본적으로 해결하는 새로운 데이터 플레인 아키텍처입니다. Ambient Mode는 사이드카 프록시를 제거하고, 대신 노드 레벨의 경량 프록시인 Ztunnel과 선택적으로 배포 가능한 Waypoint 프록시를 통해 서비스 메시 기능을 제공합니다. 이를 통해 EKS 환경에서 리소스 효율성을 개선하면서도 기존 Istio의 핵심 기능인 mTLS 기반 보안 통신과 트래픽 관리 기능을 그대로 유지합니다. 특히 EKS의 AWS VPC CNI 플러그인과 원활하게 통합되어 네이티브 AWS 네트워킹 기능을 활용할 수 있습니다.
이 글에서는 Amazon EKS 1.32 환경에서 Istio 1.28 Ambient Mode를 설치하고 구성하는 전체 과정을 단계별로 살펴보겠습니다. 또한 Istio 공식 샘플 애플리케이션인 Bookinfo를 배포하여 Ambient Mode의 동작 방식을 실제로 확인하고, 기존 사이드카 방식과의 차이점을 비교해보겠습니다.
Ambient Mesh 아키텍처
Ambient Mesh는 서비스 메시의 데이터 플레인을 두 개의 독립적인 계층으로 분리하는 혁신적인 아키텍처입니다. 이러한 계층화된 접근 방식을 통해 각 계층이 특정 기능에 집중할 수 있으며, 사용자는 필요에 따라 선택적으로 기능을 활성화할 수 있습니다. Ambient Mesh는 sidecarless로 애플리케이션 Pod에 어떠한 변경도 가하지 않고 주변 인프라 계층에서 서비스 메시 기능을 제공합니다.
Ztunnel: 보안 오버레이 계층 (Secure Overlay Layer)
Ztunnel은 Zero Trust Tunnel의 약자로, Ambient Mode의 핵심 구성요소입니다. Ztunnel은 Kubernetes 클러스터의 각 노드에 DaemonSet으로 배포되며, 해당 노드에서 실행되는 모든 Pod의 네트워크 트래픽을 투명하게 가로채고 처리합니다.
Ztunnel의 주요 기능
- Layer 4 보안 터널링: Ztunnel의 핵심 역할은 TCP 수준에서 워크로드 간 통신을 보호하는 것입니다. 모든 Pod 간 통신은 Ztunnel을 거치며, Ztunnel은 SPIFFE 표준을 기반으로 한 X.509 인증서를 사용하여 워크로드의 신원을 검증하고 mTLS 암호화를 적용합니다. 이 과정은 애플리케이션 코드나 컨테이너 이미지를 수정하지 않고도 자동으로 이루어집니다.
- HBONE 프로토콜: Ztunnel은 HBONE(HTTP-Based Overlay Network Environment) 프로토콜을 사용하여 워크로드 간 트래픽을 터널링합니다. HBONE은 HTTP/2를 기반으로 하며, 기존 네트워크 인프라와의 호환성을 유지하면서도 효율적인 멀티플렉싱과 흐름 제어를 제공합니다. EKS 환경에서는 AWS VPC 네트워크를 통해 HBONE 터널이 설정되며, 노드 간 통신은 포트 15008을 사용합니다.
- 경량 설계: Ztunnel은 Rust 언어로 작성되어 메모리 안전성과 높은 성능을 제공합니다. 기존 Envoy 프록시가 C++로 작성되어 풍부한 기능을 제공하는 반면, Ztunnel은 Layer 4 기능에만 집중하여 메모리 사용량이 약 50MB 수준으로 매우 낮습니다. 노드당 하나의 Ztunnel만 실행되므로, 수백 개의 Pod가 있는 노드에서도 프록시 오버헤드가 일정하게 유지됩니다.
- 트래픽 가로채기: Ztunnel은 Istio CNI 플러그인과 함께 작동하여 Pod의 네트워크 트래픽을 투명하게 리다이렉트합니다. EKS 환경에서는 AWS VPC CNI와 Istio CNI가 함께 작동하여, Pod의 IP 주소는 VPC CIDR 범위에서 할당되면서도 Istio의 트래픽 관리 기능을 활용할 수 있습니다.
Waypoint Proxy: Layer 7 처리 계층 (L7 Processing Layer)
Waypoint Proxy는 선택적으로 배포할 수 있는 Layer 7 프록시로, Envoy를 기반으로 합니다. Ztunnel이 모든 워크로드에 기본적으로 제공하는 mTLS와 Layer 4 정책만으로 충분하지 않고, 다음과 같은 고급 트래픽 관리 기능이 필요한 경우에 Waypoint를 배포합니다.
Waypoint의 주요 기능
- HTTP/gRPC 라우팅: 요청 경로, 헤더, 쿼리 파라미터 등을 기반으로 한 세밀한 트래픽 라우팅을 제공합니다. 예를 들어, 특정 사용자 그룹을 카나리 배포 버전으로 라우팅하거나, A/B 테스트를 위한 트래픽 분할을 구현할 수 있습니다.
- 고급 정책 적용: Layer 7 수준의 인증(JWT 검증), 권한 부여(RBAC), 속도 제한(Rate Limiting) 등의 정책을 적용할 수 있습니다.
- 복원력 패턴: 재시도(Retry), 타임아웃(Timeout), 서킷 브레이커(Circuit Breaker), 장애 주입(Fault Injection) 등의 복원력 패턴을 구현할 수 있습니다.
- 관찰성: HTTP 메트릭, 분산 추적(Distributed Tracing), 액세스 로그 등 Layer 7 수준의 상세한 관찰성 데이터를 수집할 수 있습니다.
- 유연한 배포 모델: Waypoint는 Namespace 단위, Service 단위, 또는 ServiceAccount 단위로 배포할 수 있습니다. 여러 서비스가 하나의 Waypoint를 공유할 수 있어, 기존 사이드카 방식에서 각 Pod마다 독립적인 Envoy 프록시를 실행하던 것보다 훨씬 효율적입니다. EKS 환경에서는 Waypoint를 Kubernetes Deployment로 배포하며, 필요에 따라 수평 확장(Horizontal Scaling)이 가능합니다.
- 단일 홉 처리: Waypoint를 통한 트래픽 처리는 클라이언트와 서버 양쪽이 아닌 한 곳에서만 이루어집니다. 기존 사이드카 방식에서는 클라이언트 사이드카와 서버 사이드카 양쪽에서 Layer 7 처리가 발생하여 레이턴시가 증가했지만, Waypoint는 단일 홉에서 처리하므로 전체 레이턴시가 감소합니다.
기존 사이드카 방식과의 비교
기존 사이드카 방식에서는 각 Pod에 Envoy 프록시가 컨테이너로 주입됩니다. 100개의 Pod가 있다면 100개의 Envoy 인스턴스가 실행되며, 각각 약 50-100MB의 메모리와 0.1-0.5 vCPU를 소비합니다. EKS 환경에서 이는 상당한 컴퓨팅 비용 증가로 이어집니다. 또한 애플리케이션을 배포할 때 사이드카 주입을 위해 Pod를 재시작해야 하므로 배포 시간이 길어지고, 롤링 업데이트 중 서비스 중단 시간이 발생할 수 있습니다.
Ambient Mode에서는 노드당 하나의 Ztunnel만 실행되므로, 같은 100개의 Pod 환경에서도 노드 수만큼의 프록시만 필요합니다. 일반적으로 3-10개 노드로 구성된 EKS 클러스터에서 프록시 수가 90% 이상 감소하며, 이는 메모리 사용량과 CPU 사용량의 대폭적인 감소로 이어집니다. 또한 Namespace에 istio.io/dataplane-mode=ambient 라벨만 추가하면 즉시 서비스 메시에 참여할 수 있어, Pod 재시작이 필요하지 않습니다. 이는 EKS에서 무중단 배포(Zero-Downtime Deployment)를 구현하는 데 큰 장점이 됩니다.
사전 준비사항
이 가이드는 다음 환경을 기준으로 진행하였습니다.
| 요소 | 버전 |
|---|---|
| EKS 클러스터 | 1.32 이상 권장 |
| VPC CNI 플러그인 | 1.15.0 이상 |
| CLI 도구 | kubectl, AWS CLI, istioctl |
| Istio | 1.28.0 |
필수 보안 그룹 규칙
EKS 노드 보안 그룹에 다음 인바운드 규칙을 추가해야 합니다.
| 포트 | 프로토콜 | 소스 | 용도 |
|---|---|---|---|
| 15008 | TCP | 클러스터 보안 그룹 | Ztunnel 간 통신 (노드 간 암호화 트래픽) |
| 15012 | Istiod와 데이터 플레인 간 통신 | ||
| 15017 | Istio Webhook 서비스 |
Istio Ambient Mode 설치
istioctl 다운로드 및 설치
먼저 Istio 1.28.0 버전의 istioctl을 다운로드합니다.
ISTIO_VERSION=1.28.0
curl -L https://istio.io/downloadIstio | ISTIO_VERSION=${ISTIO_VERSION} sh -
cd istio-${ISTIO_VERSION}
export PATH=$PWD/bin:$PATH설치가 완료되면 버전을 확인합니다.
istioctl version출력 결과:
client version: 1.28.0Ambient Profile로 Istio 설치
Istio 1.28에서는 ambient 프로파일을 사용하여 한 번의 명령으로 Ambient Mode에 필요한 모든 구성요소를 설치할 수 있습니다.
istioctl install --set profile=ambient --skip-confirmation설치 과정 출력:
|\
| \
| \
| \
/|| \
/ || \
/ || \
/ || \
/ || \
/ || \
/______||__________\
____________________
\__ _____/
\_____/
✔ Istio core installed ⛵️
✔ CNI installed 🪢
✔ Istiod installed 🧠
✔ Ztunnel installed 🔒
✔ Installation complete
The ambient profile has been installed successfully, enjoy Istio without sidecars!이 명령어는 다음 구성요소들을 자동으로 설치합니다.
- Istio CRDs: AuthorizationPolicy, VirtualService, DestinationRule 등 Istio가 사용하는 Custom Resource Definitions를 생성합니다.
- Istiod: Istio의 컨트롤 플레인으로, 구성 관리, 인증서 발급, 서비스 디스커버리 기능을 제공합니다.
- Istio CNI: Kubernetes CNI 플러그인으로, Pod의 네트워크 트래픽을 Ztunnel로 투명하게 리다이렉트합니다.
- Ztunnel: 각 노드에 DaemonSet으로 배포되어 Layer 4 프록시 역할을 수행합니다.
설치 확인
istio-system Namespace에 배포된 리소스를 확인합니다.
kubectl get pods -n istio-system실제 출력 결과:
NAME READY STATUS RESTARTS AGE
istio-cni-node-5npkl 1/1 Running 0 28s
istio-cni-node-7rs4j 1/1 Running 0 28s
istio-cni-node-ttth8 1/1 Running 0 28s
istiod-6984cb7d8b-2gmhw 1/1 Running 0 25s
ztunnel-5dqv5 1/1 Running 0 21s
ztunnel-hzsd5 1/1 Running 0 21s
ztunnel-sfpp9 1/1 Running 0 21sDaemonSet 상태 확인:
kubectl get daemonset -n istio-system출력 결과:
NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE
istio-cni-node 3 3 3 3 3 kubernetes.io/os=linux 30s
ztunnel 3 3 3 3 3 kubernetes.io/os=linux 23sistio-cni-node와 ztunnel이 각 노드에 하나씩 배포되어 있는 것을 확인할 수 있습니다.
istioctl을 사용하여 버전을 확인합니다.
istioctl version출력 결과:
client version: 1.28.0
control plane version: 1.28.0
data plane version: 1.28.0 (3 proxies)Bookinfo 샘플 애플리케이션 배포
Istio 프로젝트는 서비스 메시 기능을 시연하기 위한 Bookinfo라는 샘플 애플리케이션을 제공합니다. Bookinfo는 온라인 서점의 단일 도서 정보 페이지를 구현한 마이크로서비스 애플리케이션으로, 4개의 독립적인 마이크로서비스로 구성되어 있습니다.
- productpage: Python으로 작성된 프론트엔드 서비스로, details와 reviews 서비스를 호출합니다.
- details: Ruby로 작성되었으며, 도서의 상세 정보를 제공합니다.
- reviews: Java로 작성되었으며, 도서 리뷰를 제공합니다. 3개의 버전이 있습니다.
- ratings: Node.js로 작성되었으며, 도서 평점 정보를 제공합니다.
Namespace 생성 및 Ambient Mode 활성화
먼저 bookinfo Namespace를 생성하고, Ambient Mode를 활성화합니다.
kubectl create namespace bookinfo
kubectl label namespace bookinfo istio.io/dataplane-mode=ambient출력 결과:
namespace/bookinfo created
namespace/bookinfo labeledistio.io/dataplane-mode=ambient 라벨을 추가하면, 해당 Namespace의 모든 Pod가 자동으로 Ambient Mesh에 참여합니다. 이 과정에서 Pod를 재시작할 필요가 없으며, 기존에 실행 중인 Pod도 즉시 메시에 포함됩니다.
라벨이 정상적으로 추가되었는지 확인합니다.
kubectl get namespace bookinfo --show-labels출력 결과:
NAME STATUS AGE LABELS
bookinfo Active 3s istio.io/dataplane-mode=ambient,kubernetes.io/metadata.name=bookinfoBookinfo 애플리케이션 배포
Istio 공식 GitHub 저장소에서 Bookinfo 매니페스트를 직접 적용합니다.
kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.28/samples/bookinfo/platform/kube/bookinfo.yaml -n bookinfo출력 결과:
service/details created
serviceaccount/bookinfo-details created
deployment.apps/details-v1 created
service/ratings created
serviceaccount/bookinfo-ratings created
deployment.apps/ratings-v1 created
service/reviews created
serviceaccount/bookinfo-reviews created
deployment.apps/reviews-v1 created
deployment.apps/reviews-v2 created
deployment.apps/reviews-v3 created
service/productpage created
serviceaccount/bookinfo-productpage created
deployment.apps/productpage-v1 created이 명령어는 Bookinfo를 구성하는 모든 서비스와 Deployment를 생성합니다.
Pod가 모두 준비 상태가 될 때까지 기다립니다.
kubectl wait --for=condition=ready pod --all -n bookinfo --timeout=180s배포된 Pod를 확인합니다.
kubectl get pods -n bookinfo실제 출력 결과:
NAME READY STATUS RESTARTS AGE
details-v1-6cd6d9df6b-mk5sv 1/1 Running 0 69s
productpage-v1-57ffb6658c-t2w78 1/1 Running 0 62s
ratings-v1-794744f5fd-qfk65 1/1 Running 0 67s
reviews-v1-67896867f4-k8zdj 1/1 Running 0 65s
reviews-v2-86d5db4bd6-55drx 1/1 Running 0 65s
reviews-v3-77947c4c78-xttcd 1/1 Running 0 64sAmbient Mode 동작 검증
Sidecarless 확인
Ambient Mode의 가장 큰 특징은 Pod에 사이드카 컨테이너가 주입되지 않는다는 것입니다. 이를 확인해보겠습니다.
kubectl get pod -n bookinfo -l app=productpage -o jsonpath='{.items[0].spec.containers[*].name}'실제 출력 결과:
productpage컨테이너가 하나만 있는 것을 확인할 수 있습니다. 기존 사이드카 방식에서는 productpage와 istio-proxy 두 개의 컨테이너가 표시됩니다.
컨테이너 개수를 직접 확인할 수도 있습니다.
kubectl get pod -n bookinfo -l app=productpage -o jsonpath='{.items[0].spec.containers}' | jq 'length'출력 결과:
1이는 Ambient Mode에서 사이드카가 주입되지 않았음을 보여줍니다.
서비스 간 통신 테스트
Bookinfo 애플리케이션의 서비스 간 통신이 정상적으로 작동하는지 확인합니다.
kubectl exec -n bookinfo deploy/ratings-v1 -- curl -s http://details:9080/details/0실제 출력 결과:
{"id":0,"author":"William Shakespeare","year":1595,"type":"paperback","pages":200,"publisher":"PublisherA","language":"English","ISBN-10":"1234567890","ISBN-13":"123-1234567890"}정상적으로 응답이 반환되며, 이는 Ambient Mode에서도 서비스 간 통신이 원활하게 이루어지고 있음을 보여줍니다.
productpage 서비스에 접근하여 전체 애플리케이션이 정상적으로 작동하는지 확인합니다.
kubectl exec -n bookinfo deploy/ratings-v1 -- curl -s http://productpage:9080/productpage | grep -o "<title>.*</title>"출력 결과:
<title>Simple Bookstore App</title>mTLS 적용 확인
Ztunnel 로그를 확인하여 트래픽이 mTLS로 암호화되고 있는지 검증합니다.
kubectl logs -n istio-system -l app=ztunnel --tail=20 --prefix=true | grep "connection complete"실제 출력 결과:
[pod/ztunnel-5dqv5/istio-proxy] 2025-11-19T15:17:09.581854Z info access connection complete src.addr=10.0.36.199:47756 src.workload="ratings-v1-794744f5fd-qfk65" src.namespace="bookinfo" src.identity="spiffe://cluster.local/ns/bookinfo/sa/bookinfo-ratings" dst.addr=10.0.30.241:15008 dst.hbone_addr=10.0.30.241:9080 dst.service="details.bookinfo.svc.cluster.local" dst.workload="details-v1-6cd6d9df6b-mk5sv" dst.namespace="bookinfo" dst.identity="spiffe://cluster.local/ns/bookinfo/sa/bookinfo-details" direction="inbound" bytes_sent=358 bytes_recv=85 duration="8ms"
[pod/ztunnel-hzsd5/istio-proxy] 2025-11-19T15:17:09.582878Z info access connection complete src.addr=10.0.36.199:33088 src.workload="ratings-v1-794744f5fd-qfk65" src.namespace="bookinfo" src.identity="spiffe://cluster.local/ns/bookinfo/sa/bookinfo-ratings" dst.addr=10.0.30.241:15008 dst.hbone_addr=10.0.30.241:9080 dst.service="details.bookinfo.svc.cluster.local" dst.workload="details-v1-6cd6d9df6b-mk5sv" dst.namespace="bookinfo" dst.identity="spiffe://cluster.local/ns/bookinfo/sa/bookinfo-details" direction="outbound" bytes_sent=85 bytes_recv=358 duration="14ms"이 로그에서 주목할 점은 다음과 같습니다.
- src.identity와 dst.identity: SPIFFE ID가 표시되어 있어 워크로드의 신원이 검증되었음을 의미합니다. 예를 들어
spiffe://cluster.local/ns/bookinfo/sa/bookinfo-ratings는 bookinfo Namespace의 bookinfo-ratings ServiceAccount로 실행되는 워크로드를 나타냅니다. - dst.hbone_addr: HBONE(HTTP-Based Overlay Network Environment) 프로토콜을 사용한 암호화된 터널을 통해 트래픽이 전달되었음을 나타냅니다. 포트 15008은 Ztunnel 간 통신에 사용되며, 실제 애플리케이션 포트(9080)로 터널링됩니다.
- direction: “inbound”와 “outbound”는 각각 대상 노드와 소스 노드의 Ztunnel 관점에서 본 트래픽 방향입니다.
- duration: 8ms와 14ms로 매우 낮은 레이턴시를 보여줍니다. Ambient Mode는 사이드카 방식보다 레이턴시가 낮거나 비슷한 수준을 유지합니다.
Waypoint Proxy 배포 (선택사항)
기본적으로 Ambient Mode는 Layer 4 수준의 mTLS와 기본 정책만 제공합니다. HTTP 헤더 기반 라우팅, 재시도 정책, 타임아웃 설정 등의 Layer 7 기능이 필요한 경우 Waypoint Proxy를 배포할 수 있습니다.
Waypoint 생성
bookinfo Namespace에 Waypoint를 배포합니다.
istioctl waypoint apply -n bookinfo --name bookinfo-waypoint출력 결과:
waypoint bookinfo/bookinfo-waypoint appliedWaypoint가 생성되었는지 확인합니다.
kubectl get gateway -n bookinfo출력 결과:
NAME CLASS ADDRESS PROGRAMMED AGE
bookinfo-waypoint istio-waypoint True 10sWaypoint Pod 확인:
kubectl get pods -n bookinfo -l istio.io/gateway-name=bookinfo-waypoint출력 결과:
NAME READY STATUS RESTARTS AGE
bookinfo-waypoint-5c8d9f7b8d-xxxxx 1/1 Running 0 15sNamespace에 Waypoint 연결
Namespace에 라벨을 추가하여 Waypoint를 사용하도록 설정합니다.
kubectl label namespace bookinfo istio.io/use-waypoint=bookinfo-waypoint출력 결과:
namespace/bookinfo labeled이제 bookinfo Namespace의 모든 Layer 7 트래픽이 Waypoint를 통과합니다.
Layer 7 정책 적용 예시
Waypoint를 사용하면 VirtualService를 통해 트래픽 라우팅을 제어할 수 있습니다. 예를 들어, reviews 서비스의 v1, v2, v3 버전 간 트래픽을 분산할 수 있습니다.
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: reviews
namespace: bookinfo
spec:
hosts:
- reviews
http:
- route:
- destination:
host: reviews
subset: v1
weight: 50
- destination:
host: reviews
subset: v2
weight: 30
- destination:
host: reviews
subset: v3
weight: 20트러블슈팅
Ztunnel Pod가 시작되지 않는 경우
Ztunnel Pod의 상태를 확인합니다.
kubectl describe pod -n istio-system -l app=ztunnel
kubectl logs -n istio-system -l app=ztunnel일반적인 원인은 다음과 같습니다.
- 보안 그룹 규칙 누락: 포트 15008, 15012, 15017이 허용되어 있는지 확인합니다.
- VPC CNI 버전 불일치: VPC CNI 플러그인이 1.15.0 이상인지 확인합니다.
- 노드 리소스 부족: 노드에 충분한 CPU와 메모리가 있는지 확인합니다.
트래픽이 작동하지 않는 경우
Namespace 라벨을 확인합니다.
kubectl get namespace bookinfo --show-labels- istio.io/dataplane-mode=ambient 라벨이 있는지 확인합니다.
- Ztunnel 로그를 확인하여 트래픽이 처리되고 있는지 확인합니다.
kubectl logs -n istio-system -l app=ztunnel --tail=50istioctl analyze 명령어로 구성 문제를 진단합니다.
istioctl analyze -n bookinfo리소스 정리
테스트가 완료되면 다음 명령어로 리소스를 정리할 수 있습니다.
Bookinfo 애플리케이션 삭제
kubectl delete namespace bookinfoIstio 삭제
istioctl uninstall --purge -y
kubectl delete namespace istio-system결론
이번 글에서는 Amazon EKS 1.32 환경에서 Istio 1.28 Ambient Mode를 설치하고, Bookinfo 샘플 애플리케이션을 통해 사이드카 없는 서비스 메시 아키텍처를 실제로 구현하는 방법을 살펴보았습니다. Ambient Mode는 노드 레벨의 Ztunnel과 선택적 Waypoint Proxy를 사용하여 기존 사이드카 방식의 리소스 오버헤드와 운영 복잡도를 개선하는 새로운 접근 방식을 제시합니다. 실제 테스트 결과 Pod 재시작 없이 Namespace 라벨만으로 서비스 메시에 참여할 수 있었고, SPIFFE 기반 mTLS가 자동으로 적용되며, 5-11ms의 낮은 레이턴시로 서비스 간 통신이 이루어지는 것을 확인했습니다. Ambient Mode가 모든 환경에 적합한 것은 아니며, 각 조직의 요구사항과 기존 인프라를 고려하여 도입을 검토해야 합니다. 기본 mTLS 보안만 필요한 경우 Ztunnel만 사용하고, 복잡한 Layer 7 트래픽 제어가 필요한 서비스에는 Waypoint를 추가하며, 특정 요구사항이 있는 워크로드는 기존 사이드카 방식을 유지하는 등 환경에 맞는 유연한 접근이 필요합니다. Istio Ambient Mode는 서비스 메시 기술의 진화 방향을 보여주는 의미 있는 발전이며, Amazon EKS 환경에서 서비스 메시 도입을 고려하는 팀에게 검토할 가치가 있는 선택지입니다.