[Istio] Ambient Mesh

xgro·2025년 6월 8일

Istio

목록 보기

16/17

📌 Notice

Istio Hands-on Study (=Istio)
직접 실습을 통해 Isito를 배포 및 설정하는 내용을 정리한 블로그입니다.

CloudNet@에서 스터디를 진행하고 있습니다.

Gasida님께 다시한번 🙇 감사드립니다.

EKS 관련 이전 스터디 내용은 아래 링크를 통해 확인할 수 있습니다.

[AEWS] AWS EKS 스터디

[PKOS] KOPS를 이용한 AWS에 쿠버네티스 배포

[DOIK] Database Operator In Kubernetes study

[KANS3] Kubernetes Advanced Networking Study

📌 Overview

이번 블로그에서는 Istio Ambient Mesh가 다양한 Kubernetes CNI 및 플랫폼 환경과의 호환성을 확보하기 위해 도입한 인팟 트래픽 리디렉션 구조와, 1.24 버전을 통해 앰비언트 모드가 GA(General Availability)에 도달하면서 가져온 운영 상의 전환점을 함께 정리합니다.

초기 앰비언트 알파 구현은 사이드카 없는 메시 구조라는 개념적 혁신은 제시했지만, 실제 다양한 클러스터와 CNI 조합에서의 호환성에는 한계가 있었습니다.

이를 해결하기 위한 핵심 기술로 ztunnel과 istio-cni를 통한 포드 네임스페이스 내부 리디렉션 방식이 등장했으며, 이로 인해 Istio는 사이드카 없이도 모든 주요 CNI 및 클라우드 제공자 환경에서 안정적인 메시 구성을 지원할 수 있게 되었습니다.

앰비언트 모드가 GA에 도달하며 사이드카 모델과의 차별점, 점진적 채택 전략, L4/L7 기능 분리 구조 등을 통해 Istio의 운영 효율성과 유연성이 얼마나 향상되었는지를 함께 확인합니다.

📌 Istio Ambient Mesh

👉 Step 01. Introducing Ambient Mesh

Istio는 기존의 Sidecar 기반 아키텍처에서 벗어나, 새로운 사이드카 없는 데이터 플레인 모드인 Ambient Mesh를 도입하였습니다.

이 모드는 제로 트러스트 보안, 원격 측정(telemetry), 트래픽 관리와 같은 Istio의 핵심 기능을 그대로 유지하면서도, 프록시 운영 부담을 줄이고 인프라에 더욱 자연스럽게 통합될 수 있도록 설계되었습니다.

Ambient Mesh vs Sidecar Mesh

Sidecar Mesh: 파드마다 별도의 Envoy 프록시가 주입되며, 모든 L4/L7 트래픽을 처리합니다.
Ambient Mesh: 프록시 기능을 L4 전용 ztunnel과 L7 전용 Waypoint Proxy로 역할을 분리하여, 효율성과 보안성을 동시에 확보합니다.

ztunnel: Ambient Mesh의 기본 구성 요소

Ambient Mesh에서 파드들은 각 노드에 존재하는 공유 ztunnel을 통해 통신합니다.

ztunnel은 노드당 하나씩 배포되며, L4 보안 터널 역할을 수행합니다.
Istio CNI DaemonSet이 iptables를 설정하여, 파드 트래픽이 ztunnel로 자동으로 리디렉션됩니다.
ztunnel은 Geneve 터널 기반 L4 프록시 역할을 하며, HBONE(HTTP CONNECT over HTTP/2) 프로토콜을 통해 통신을 암호화합니다.

Waypoint Proxy: 정책과 L7 제어가 필요한 경우

L7 레벨의 트래픽 제어, 인증, 인가 정책이 필요한 경우, 해당 네임스페이스나 서비스 단위로 Waypoint Proxy를 설정합니다.
ztunnel은 목적지 파드에 대해 L7 처리가 필요하다고 판단되면, Waypoint Proxy로 트래픽을 중계합니다.

HBONE: HTTP/2 기반 보안 터널링

Ambient Mesh에서는 HBONE(HTTP Based Overlay Network Encapsulation) 프로토콜을 사용하여 ztunnel 간 표준 HTTP CONNECT 기반 터널링을 구현합니다.

TCP 상위 계층에 HTTP/2 프로토콜을 사용하며, TLS로 상호 인증 및 암호화가 제공됩니다.
ztunnel은 포트 15008을 통해 HBONE 터널을 수립합니다.

✅ Ambient Mesh 통신 흐름 예시

Ambient → Sidecar 통신 흐름

foo 네임스페이스는 istio.io/dataplane-mode=ambient 레이블을 사용
bar 네임스페이스는 기존 sidecar injection 방식 사용

요청 흐름:
(1)(2)(3) sleep 파드에서 bar NS의 httpbin 목적지로 요청 ⇒ Istio CNI DaemonSet에 의해서 설정된 iptables 에 따라, 요청 트래픽이 istioout → (Geneve Tunnel) → pistoout 전달

(4)(5) pistoout 은 iptables rule 을 통해 파드 내의 eth0 인터페이스에 port 15001로 redirect

(6) ztunnel 파드는 목적지 httpbin 정보를 기반으로 전달 ⇒ 노드 B eth0

(7) 요청 트패릭은 httpbin 파드 내의 iptables rule 을 통해 port 15006로 redirect 되고 이후 목적지 httpbin 파드에 도착

Sidecar → Ambient 통신 흐름 (Waypoint 미사용)

httpbin 파드는 ambient 모드이지만 Waypoint Proxy는 비활성화됨

(1)(2) Sleep 파드는 Sidecar Proxy 에 Iptables rule 에 의해 15001 포트로 redirect 됨

(3) 목적지 httpbin 파드는 waypoint proxy disabled로 목적지 파드가 있는 (오른쪽 상단) 워커 노드 B로 전달됨

(4)(5)(6) veth httpbin ↔ httpbin 파드 내 eth0 과 device pair 관계이지만, iptables rule에 의해 가로채어 istioin → pistioin device로 전달

(7)(8) ztunnel 파드 내에 iptables rule에 의해 port 15008 redirect

(9) 최종적으로 httpbin 파드로 전달

Sidecar → Ambient 통신 흐름 (Waypoint 사용)

helloworld 파드는 Waypoint Proxy가 활성화된 ambient 모드

(1)(2) Sleep 파드는 Sidecar Proxy 에 Iptables rule 에 의해 15001 포트로 redirect 됨

(3) 목적지 helloworld 파드는 waypoint proxy enabled로 waypoint 파드가 있는 (왼쪽 하단) 워커 노드 C(Port 15008)로 전달됨

(4) waypoint 파드는 control plane 을 통해 받은 라우팅 정보로 helloworld 파드가 있는 (오른쪽 하단) 워커 노드 D로 전달됨

(5)~(10) 위 httpbin 파드 내부 과정과 동일

✅ Istio and sidecars: 사이드카 제약

사이드카 기반 아키텍처의 특징

Istio의 초기 아키텍처는 각 애플리케이션 파드에 Envoy 사이드카 프록시를 주입하여 Istio의 기능을 제공하였습니다.
이 방식은 애플리케이션의 변경 없이 Istio 기능을 적용할 수 있다는 장점이 있지만, 여러 운영상의 제약을 동반합니다.

사이드카의 주요 제약

1. 침입성(Invasiveness)
사이드카는 Kubernetes 파드 스펙을 수정하고 트래픽을 리디렉션하기 때문에, 설치나 업그레이드를 위해 애플리케이션 재시작이 필요합니다. 이는 운영 중단을 유발할 수 있습니다.

2. 리소스 활용도 저하(Underutilization)
사이드카는 각 워크로드에 전념하므로, 최악의 경우를 대비한 리소스 프로비저닝이 필요합니다. 이로 인해 클러스터 전체 리소스 낭비가 발생할 수 있습니다.

3. 트래픽 차단(Traffic breaking)
사이드카가 수행하는 트래픽 캡처 및 HTTP 처리 과정은 높은 컴퓨팅 비용을 초래하고, 일부 HTTP 비표준 애플리케이션의 정상 작동을 방해할 수 있습니다.

➡️ 이러한 제약으로 인해 Istio는 보다 간섭이 적고 유연한 방식이 필요하다는 문제의식을 바탕으로 Ambient Mesh를 도입하게 되었습니다.

✅ Slicing the layers: L7 처리 계층과 보안 오버레이 분리

사이드카 아키텍처의 문제점

기존 Istio는 L4 전송 보안부터 고급 L7 정책까지 모든 기능을 사이드카 하나에 집중시켰습니다.
이로 인해 모든 워크로드에 동일한 오버헤드가 적용되며, 간단한 보안만 필요한 경우에도 불필요한 비용이 발생했습니다.

Ambient Mesh의 계층적 구조

보안 오버레이(Secure Overlay)

가장 기본 계층으로, 트래픽 라우팅과 제로 트러스트 보안(mTLS, 인증, L4 인가)을 처리합니다.

L7 처리 계층(L7 Processing Layer)

필요할 경우 Waypoint Proxy를 통해 활성화되는 계층입니다.
전체 Istio 기능(Virtual Service, L7 Telemetry, L7 Authorization)을 사용할 수 있지만, 애플리케이션 파드는 수정하지 않아도 됩니다.

➡️ 사용자는 네임스페이스 단위로 점진적으로 보안 오버레이 → L7 계층 → Full Istio 기능으로 전환할 수 있어 유연성이 매우 큽니다.

✅ Building an ambient mesh: 앰비언트 메시 구조 및 동작 방식

ztunnel: 공유 보안 터널 에이전트

Ambient 모드는 노드당 공유 ztunnel 에이전트를 통해 트래픽을 처리합니다.
ztunnel은 L7 처리를 하지 않으며, mTLS, 인증, 원격 측정, L4 인가 기능만을 수행합니다.
네트워크 스택이 자동으로 파드의 트래픽을 ztunnel로 리디렉션합니다.

➡️ 이를 통해 Istio 데이터 플레인은 애플리케이션과 완전히 분리되어 무중단으로 데이터 플레인을 배포·업그레이드할 수 있습니다.

보안 오버레이 생성 및 확장

특정 네임스페이스에 Ambient 모드를 설정하면 ztunnel을 기반으로 보안 오버레이가 자동 생성됩니다.
이 오버레이는 HTTP 종료 없이도 핵심 Istio 기능들을 제공할 수 있습니다.

Waypoint Proxy: 정책 및 L7 처리를 위한 경유지 프록시

L7 기능 활성화 시 구조

네임스페이스가 L7 기능이 필요할 경우, Envoy 기반 Waypoint Proxy를 배포합니다.
Istio Control Plane은 ztunnel을 통해 L7 처리가 필요한 트래픽을 Waypoint로 우회시킵니다.

운영 유연성과 리소스 최적화

Waypoint Proxy는 Kubernetes Deployment 객체처럼 동작하므로, HPA를 통해 실시간 트래픽 수요에 따라 자동 확장이 가능합니다.
이는 최악의 상황을 기준으로 하는 리소스 낭비를 방지할 수 있습니다.

HBONE: HTTP 기반 오버레이 네트워크

Ambient Mesh는 mTLS 기반 HTTP CONNECT 프로토콜을 통해 보안 터널을 구현합니다.
이 방식은 HBONE(HTTP-Based Overlay Network Environment) 라고 불리며 다음과 같은 특징이 있습니다:

장점

일반 TLS보다 더 나은 트래픽 캡슐화
기존 로드 밸런서 인프라와의 상호운용성 보장
FIPS 모드 기본 적용으로 규정 준수 보장

➡️ 향후 UDP 및 비-TCP 프로토콜 지원 계획도 존재하며, 향후 블로그에서 더 많은 정보가 제공될 예정입니다.

혼합 운영 및 호환성

Ambient 모드와 Sidecar 모드는 동일 메시 내에서 혼합 운용 가능합니다.

Istio의 제어 평면은 모든 구성 모델에 대해 일관된 정책 적용을 보장합니다.

Ambient Mesh는 단지 더 나은 인체공학성과 유연성을 제공하는 새로운 선택지일 뿐, 기존 기능을 대체하거나 축소하지 않습니다.

✅ Why no L7 processing on the local node? 로컬 노드에서 L7 처리를 하지 않는 이유

L7 처리 분리 이유
Ambient 모드는 노드마다 공유 ztunnel을 배치하여 제로 트러스트 보안을 담당하고, L7 처리는 별도 스케줄링된 Waypoint Proxy에서 수행됩니다. 그 이유는 다음과 같습니다:

1. Envoy는 멀티 테넌트에 적합하지 않음
공유된 L7 프록시에서 여러 테넌트의 L7 트래픽을 혼합 처리하는 경우 보안 위험이 증가합니다. 따라서 L4 처리로 범위를 제한하여 공격 면적을 줄입니다.

2. 리소스 최적화
L7 처리는 L4보다 훨씬 많은 리소스(CPU/메모리)를 소모합니다. Waypoint Proxy를 네임스페이스 단위로 운영하면 필요한 만큼만 확장 가능하며, 비용도 테넌트별로 분리됩니다.

3. 확장성과 대체 가능성 확보
ztunnel의 역할이 제한되어 있기 때문에, 다른 구현체로도 대체 가능하며 상호 운용성 계약만 충족하면 됩니다.

✅ But what about those extra hops? 추가 홉으로 인한 성능 저하는?

L7 처리 노드 분산 구조
Waypoint가 워크로드와 같은 노드에 있을 거라는 보장이 없지만, 전체 지연 시간은 사이드카 기반 Istio와 유사하거나 오히려 더 낮을 수 있습니다.

1. 네트워크 자체가 성능 저하의 주원인이 아님
오늘날 클라우드 네트워크는 매우 빠르며, 지연의 주요 원인은 L7 처리 그 자체입니다. Ambient 모드는 기존 사이드카 모델의 2단계 L7 처리 → 1단계로 통합하여 오히려 효율적입니다.

2. L7 기능을 선택적으로 활성화 가능
앰비언트 모드를 사용하면 기본 보안만 필요한 경우 L7 처리 비용을 아예 발생시키지 않도록 구성할 수 있습니다.

✅ Resource overhead 리소스 오버헤드

ztunnel의 공유 아키텍처
ztunnel은 노드당 공유 리소스로 작동하며, 책임이 제한적이기 때문에 워크로드당 예약 리소스를 최소화할 수 있습니다.

Waypoint Proxy의 동적 확장
Waypoint는 일반 Kubernetes 포드로 배포되어 실시간 트래픽 수요에 맞춰 자동 확장됩니다.

사이드카 대비 장점
사이드카는 각 워크로드별 최악의 시나리오 기준으로 리소스를 예약해야 하며, 이로 인해 노드 자원 낭비와 과도한 프로비저닝이 빈번합니다.

효율적 클러스터 운영
앰비언트 메시 구조는 고정 오버헤드는 낮고, 필요한 부분만 유연하게 확장되므로 리소스 사용률이 높고 예측 가능합니다.

✅ What about security? 보안은 안전한가요?

사이드카와 달리 완전 분리된 구성
애플리케이션이 손상되더라도 ztunnel과 Waypoint Proxy는 독립적으로 보안 정책을 유지할 수 있습니다.

ztunnel의 보안 특성

ztunnel은 L4 처리 전용으로, 공격 표면이 매우 작습니다.
노드 단위로만 워크로드 키를 접근할 수 있어 암호화 CNI와 동일한 수준의 방어가 가능합니다.

Waypoint Proxy의 보안 특성

Waypoint는 특정 서비스 계정에만 접근하도록 제한 가능
침해 시 해당 자격 증명만 노출되며, 타 워크로드에는 영향이 없습니다

✅ Is this the end of the road for the sidecar? 사이드카는 이제 끝인가요?

그렇지 않습니다.
Ambient Mesh는 많은 사용자에게 유연하고 경량화된 기본 옵션이 될 수 있지만, 전용 리소스가 필요한 워크로드(예: 컴플라이언스, 고성능 요구)에는 사이드카가 여전히 유효한 선택지입니다.

Istio의 전략
Istio는 사이드카 모드도 계속 지원하며, 앰비언트 모드와의 완벽한 상호운용성을 제공합니다. 실제로 현재 릴리스된 코드에서도 두 모드를 함께 사용할 수 있습니다.

👉 Step 02. Istio Ambient Mesh를 위한 Rust 기반 Ztunnel 소개

Istio Ambient Mesh 아키텍처에서 핵심 역할을 수행하는 Ztunnel은 노드별로 배포되는 경량 프록시 컴포넌트입니다. 이는 기존의 Sidecar Proxy와는 다르게, 워크로드 내부가 아닌 노드 단위에서 공유 방식으로 동작하며, 워크로드 간의 안전한 통신과 인증을 전담합니다.

✅ Istio 앰비언트 메시를 위한 노드별 프록시

: A purpose-built per-node proxy for Istio ambient mesh - Blog 링크

Ztunnel의 정의
ztunnel(Zero Trust Tunnel)은 Istio Ambient Mesh를 위해 특별히 설계된 per-node proxy입니다. 각 Kubernetes 노드에 하나씩 배포되어 제로 트러스트 기반의 안전한 워크로드 연결과 인증을 수행합니다.

기능 범위
ztunnel은 아래와 같은 기능에만 집중하며, HTTP 트래픽 종료나 HTTP 헤더 파싱은 수행하지 않습니다:

mTLS
인증(Authentication)
L4 권한 제어 (Authorization)
원격 측정(Telemetry)

Waypoint Proxy와의 연계
ztunnel은 모든 HTTP 트래픽을 자체적으로 처리하지 않고, 고급 기능(예: HTTP Telemetry, Load Balancing)은 Waypoint Proxy에 위임합니다. 이로써 ztunnel은 경량으로 유지되며, 트래픽을 효율적이고 안전하게 중계하는 역할을 합니다.

리소스 최적화
ztunnel은 모든 워커 노드에 배포되기 때문에 리소스 사용량을 작게 유지하는 것이 필수입니다. 이러한 설계 철학 덕분에 워크로드에 영향을 거의 주지 않는 "투명한" 인프라 구성 요소로 작동할 수 있습니다.

✅ Ztunnel architecture : xDS Client, CA Client, L4 Policy enforcement, L4 Telemetry

xDS Client 역할

ztunnel은 시작 시 서비스 계정 토큰을 이용해 Istiod 제어 평면에 TLS로 연결합니다.
연결이 완료되면, 사이드카와 유사하게 xDS 설정을 가져오는 클라이언트로 작동합니다.
단, Istiod는 ztunnel의 요청을 인식하고, ztunnel 전용 xDS 설정을 제공합니다.

CA Client 역할

ztunnel은 자신이 위치한 노드의 모든 워크로드를 대신하여 mTLS 인증서 발급과 갱신을 수행합니다.
이를 통해 워크로드는 직접 인증서를 관리하지 않고도 자동화된 보안 통신이 가능합니다.

Core L4 Proxy 기능

ztunnel은 노드에 존재하는 모든 워크로드의 인바운드 및 아웃바운드 트래픽을 가로채고 제어합니다.
메시 외부 트래픽은 일반 텍스트, 메시 내부 트래픽은 HBONE 방식으로 캡슐화하여 전달됩니다.

L4 Telemetry 및 디버깅 지원

ztunnel은 L4 수준의 메트릭과 로그를 수집하며, 내부적으로 디버깅 정보를 제공하는 관리 서버(admin server) 를 함께 운영합니다.
이는 ztunnel 동작 확인 및 문제 해결에 유용합니다.

Ztunnel은 Sidecar와 비교해 훨씬 단순하고, 보안 중심의 아키텍처를 제공하면서도 워크로드에 영향을 최소화합니다. Istio Ambient Mesh의 핵심 인프라 요소로서, 다양한 기능을 노드 단위에서 통합 관리할 수 있게 해줍니다.

✅ Why not reuse Envoy? Envoy를 재사용하지 않는 이유

초기 구현
Istio Ambient Mesh가 2022년 9월 발표될 당시, ztunnel은 Envoy를 기반으로 구현되었습니다. 이는 기존 사이드카, 게이트웨이, 웨이포인트 프록시와의 일관성을 고려한 자연스러운 선택이었습니다.

문제점
그러나 ztunnel의 요구사항은 기존 L7 중심의 Envoy 사용 사례와 크게 달랐습니다. ztunnel은 L7 처리를 하지 않기 때문에, Envoy의 풍부한 L7 기능과 확장성은 오히려 불필요한 부하가 되었습니다.

결론
⇒ ztunnel은 L7 기능이 필요하지 않으며, Envoy를 사용하는 것은 복잡성 증가와 성능 저하로 이어졌습니다.

✅ A purpose-built ztunnel

전용 구현으로의 전환
Envoy의 복잡한 구성을 맞추는 대신, ztunnel을 단순하고 목적 지향적으로 새롭게 구현하기로 결정했습니다. 이 접근 방식은 성능과 설계 유연성을 동시에 확보할 수 있게 해주었습니다.

핵심 구성 요소

ztunnel과 Istiod 간의 경량 구성 프로토콜
ztunnel 자체의 런타임 프록시 구현

✅ Configuration protocol 설정 프로토콜

xDS 기반 구성의 문제점
Envoy 기반 구성은 기본적으로 xDS 프로토콜을 사용하지만, 단일 서비스 포드조차도 ~350줄의 YAML 설정이 필요하고, 경우에 따라 N^2 확장 문제까지 발생했습니다.

경량화된 ztunnel 구성 예시

name: helloworld-v1-55446d46d8-ntdbk
namespace: default
serviceAccount: helloworld
protocol: TCP

맞춤형 구성 포맷의 장점

Envoy에 비해 구성 크기 최소화
Istiod와 ztunnel 간에 필요한 정보만 전송
구성 로직을 코드에 포함하여 복잡한 TLS 설정을 제거

✅ Runtime implementation & A Rust-based ztunnel

Envoy 기반 구현의 한계
Envoy는 필터 체인 구조를 가지고 있어 요청당 4회 필터 반복이 필요했고, 이는 성능과 복잡도 모두에 부담이 되었습니다.

Rust 기반 전용 프록시의 선택

직접 구현함으로써 스레드 간 연결 공유, 서비스 계정 격리 등 맞춤형 아키텍처 설계 가능
최종적으로 Rust 기반 구현을 채택

Rust 선택 배경

Go는 성능/설치 공간 요건 미달
C++은 메모리 안전성과 유지보수 한계
Rust는 고성능 네트워크 애플리케이션에서 성공 사례 다수

사용된 주요 라이브러리

Tokio

Hyper

✅ A quick tour of the Rust-based ztunnel

워크로드 구성 확인

명령어: istioctl pc workload
ztunnel의 config_dump에서도 직접 확인 가능

HBONE 업그레이드 예시

"protocol": "HBONE"

정책 구성 예시

"authorizationPolicies": [
  "default/hw-viewer"
]

특징

ambient가 활성화되면 트래픽은 자동으로 HBONE으로 업그레이드
정책 적용 시 workload xDS 설정에 반영됨

✅ L4 telemetry provided by ztunnel

직관적인 로그 출력 예시

CONNECT request to 10.244.2.8:5000

메트릭 수집

localhost:15020/metrics를 통해 접근 가능
기존 사이드카와 동일한 레이블을 사용한 TCP 메트릭 출력

istio_tcp_connections_opened_total{
  source_workload="sleep",
  destination_workload="helloworld-v1",
  connection_security_policy="mutual_tls"
} 1

Kiali UI에서 시각화 가능

Rust 기반 ztunnel은 복잡한 L7 처리를 제거하고, Istio Ambient Mesh의 보안성과 성능을 극대화하기 위한 경량 고성능 프록시로 재탄생한 결과물입니다.

전용 구성 프로토콜과 최적화된 런타임 구조를 통해 대규모 메시에서도 안정적인 확장이 가능합니다.

👉 Step 03. Istio Ambient Waypoint Proxy Made Simple

Istio Ambient Mesh 구조에서는 데이터 플레인을 보안 오버레이 계층과 L7 처리 계층으로 나누고, L7 처리를 담당하는 핵심 컴포넌트로 Waypoint Proxy를 사용합니다.

이 Waypoint Proxy는 Envoy 기반의 선택적 구성 요소로, 주로 네임스페이스 단위(또는 서비스 계정 단위)로 동작하며, 애플리케이션 파드 외부에서 실행되어 독립적으로 설치·확장·운영될 수 있습니다.

✅ Architecture of waypoint proxies 웨이포인트 프록시의 아키텍처

Waypoint Proxy는 Istio가 동적으로 구성하는 Envoy 프록시로, 사이드카처럼 애플리케이션 구성에 연동되지만 파드 외부에서 독립적으로 실행되므로 운영이 훨씬 유연합니다.

기본적으로 네임스페이스 단위로 하나의 Waypoint Proxy가 배포되며, Kubernetes Gateway 리소스 또는 istioctl 명령어를 통해 선언적으로 구성할 수 있습니다.

$ istioctl experimental waypoint generate
apiVersion: gateway.networking.k8s.io/v1beta1
kind: Gateway
metadata:
  name: namespace
spec:
  gatewayClassName: istio-waypoint
  listeners:
  - name: mesh
    port: 15008
    protocol: HBONE

이러한 리소스는 Istiod가 감지하고 자동으로 해당 Waypoint Proxy를 배포하고 관리합니다.

✅ Shift source proxy configuration to destination proxy 구성의 방향 전환

기존 사이드카 아키텍처에서는 대부분의 트래픽 제어 정책(예: 요청 라우팅, 트래픽 분산, 오류 주입 등)이 소스 프록시, 즉 클라이언트 측 사이드카에서 구현되었습니다.

반면, 보안 정책은 목적지 프록시, 즉 서버 측 사이드카에서 적용되었습니다.

이처럼 정책이 분산되어 있는 구조는 확장성 문제, 디버깅의 복잡성, 혼합 환경에서의 비일관성, 그리고 정책 귀속 관계의 불분명함과 같은 다양한 문제를 야기합니다.

Ambient Mesh에서는 이러한 구조적 문제를 해결하기 위해 모든 정책을 목적지에 위치한 Waypoint Proxy에서 적용합니다. 즉, 트래픽이 특정 네임스페이스로 유입되면 반드시 해당 네임스페이스의 Waypoint Proxy를 경유하게 되고, 이 Waypoint가 해당 네임스페이스의 모든 정책을 전담하여 적용하는 방식입니다.

이 구조 덕분에 Waypoint Proxy는 자신의 네임스페이스에 대한 구성 정보만 알면 되며, 메시 내의 다른 목적지에 대한 정보를 알 필요가 없으므로 스케일 확장 시 복잡도가 급격히 감소합니다.

예를 들어, 네임스페이스가 2개 있고 각각에 2개의 디플로이먼트가 있을 경우, 사이드카 모델에서는 각 워크로드마다 다른 모든 워크로드에 대한 구성을 가져야 하므로 총 16개의 구성 세트가 필요합니다.

반면, Waypoint 구조에서는 네임스페이스별로 단 2개의 구성만 필요하므로 구성량이 25% 수준으로 줄어듭니다.

더 나아가, 각 네임스페이스에 25개의 디플로이먼트가 있고 디플로이먼트당 10개의 포드가 있는 경우, HA를 위한 웨이포인트 복제까지 고려하면 구성 전파량은 사이드카 모델의 0.8% 수준으로 감소합니다.

이러한 구성 단순화는 제어 플레인과 데이터 플레인의 CPU, 메모리, 네트워크 사용량을 모두 줄이는 결과로 이어집니다.

기존에는 Sidecar 리소스나 exportTo 같은 고급 구성 기능을 통해 유사한 최적화를 수행해야 했지만, Ambient 모드에서는 별도 설정 없이도 이를 자동으로 달성할 수 있습니다.

✅ What if my destination doesn’t have a waypoint proxy? 목적지에 웨이포인트가 없다면?

Ambient Mesh는 보통 서비스 생산자(서버 측)가 트래픽 정책을 정의하고 적용하도록 설계되어 있습니다. 그러나 외부 서비스와 같이 직접 제어할 수 없는 목적지에 대해서는 클라이언트 측에서 트래픽 관리 정책이 필요할 수 있습니다.

예를 들어, 외부 API 서버인 example.com에 연결 시, 타임아웃이나 재시도 정책을 설정하고 싶다면 목적지에 웨이포인트가 없기 때문에 기존처럼 트래픽 이그레스 게이트웨이로 라우팅하고 해당 게이트웨이에 정책을 적용하는 방식이 필요합니다.

이 기능은 현재 커뮤니티에서 활발히 개발 중이며, 향후 블로그에서 자세히 다뤄질 예정입니다.

✅ A deep-dive of waypoint configuration 웨이포인트 프록시 구성 심화 분석

Istio Ambient 환경에서 bookinfo-reviews 서비스 계정에 Waypoint Proxy를 구성하면, 트래픽을 90%는 v1, 10%는 v2 리뷰 서비스로 라우팅하도록 설정할 수 있습니다. 이때 사용하는 명령어는 다음과 같습니다.

$ istioctl proxy-config listener deploy/bookinfo-reviews-istio-waypoint --waypoint

기본적으로 Waypoint Proxy는 포트 15008에서 HBONE 연결을 종료하고, Envoy의 internal listener를 통해 트래픽을 내부 필터 체인으로 전달하며, AuthorizationPolicy 같은 정책을 적용합니다.

이러한 내부 구조는 --waypoint 플래그로 조회 가능하며, IP 주소와 애플리케이션 프로토콜에 따라 각 필터 체인이 구성됩니다. 실제 서비스 VIP는 10.96.x.x, 포드 IP는 10.244.x.x와 같이 구성되어 있습니다.

Waypoint Proxy는 자신이 관리하는 서비스 계정에 대한 구성만 반영하고, 다른 서비스에 대한 클러스터 구성은 생성되지 않습니다. 예를 들어, reviews의 Waypoint Proxy는 productpage나 ratings의 경로 정보는 알지 못합니다. 별도의 exportTo 구성 없이도 자동으로 이와 같은 격리된 구성 구조를 제공합니다.

$ istioctl proxy-config routes deploy/bookinfo-reviews-istio-waypoint
$ istioctl proxy-config clusters deploy/bookinfo-reviews-istio-waypoint
$ istioctl proxy-config endpoints deploy/bookinfo-reviews-istio-waypoint

이 명령어들을 통해 라우팅 정책(예: 가중치 기반 트래픽 분산), 생성된 Envoy 클러스터, 연결된 엔드포인트 등을 확인할 수 있으며, 리뷰 서비스 외 다른 네임스페이스나 서비스에 대한 정보는 표시되지 않음을 확인할 수 있습니다.

Waypoint Proxy는 L7 정책 적용의 단일 경유지로 작동하며, 정책의 적용 범위를 네임스페이스 혹은 서비스 계정 단위로 제한하여 구성 확장을 단순화합니다.

이를 통해 구성 분산, 트래픽 정책 일관성, 디버깅 용이성, 스케일링 효율성까지 모두 개선할 수 있습니다.

👉 Step 04. Ambient Mode Security Deep Dive

Istio Ambient Mesh는 사이드카 없이도 네트워크 트래픽을 제어할 수 있는 혁신적인 방식으로, 단순히 운영을 간소화하는 것뿐만 아니라 보안 측면에서도 강력한 개선점을 제공합니다.

이번 단계에서는 사이드카 기반 아키텍처와 비교하여 Ambient Mesh 보안 구조의 차별성과 강점을 깊이 있게 살펴봅니다.

✅ 애플리케이션과 데이터 플레인의 분리

Ambient Mesh는 데이터 플레인 구성 요소를 애플리케이션 파드 외부에서 실행합니다.

즉, 사이드카가 파드 내에 포함되어 있던 기존 모델과 달리, ztunnel 및 waypoint proxy는 별도의 인프라 리소스로 분리되어 배포됩니다.

이를 통해 다음과 같은 이점을 얻습니다:

애플리케이션 침해 시에도 해당 파드에 포함된 데이터 플레인 구성 요소에 접근할 수 없어, 자격 증명, 키, 시크릿 노출을 방지할 수 있습니다.

Envoy가 L7 처리 시 복잡해지는 취약점(CVE)에 노출되지 않도록, L4와 L7 기능을 분리하여 필요한 네임스페이스에만 L7 기능을 부여합니다.

L7 프록시는 워크로드와 완전히 분리되어 배포되므로 공격 경로를 제공하지 않습니다.

✅ 보안 오버레이 계층은 CNI 구성요소처럼 동작

ztunnel은 모든 노드에 DaemonSet으로 배포되며, L4 수준에서 mTLS, 인증서 발급, 리디렉션 등의 역할을 수행합니다.

이 구성은 다음과 같은 방식으로 보안성을 확보합니다:

노드당 하나의 ztunnel만 존재하며, 해당 노드에서 실행 중인 파드의 트래픽만 처리합니다.
ztunnel은 각 파드마다 고유한 자격 증명을 사용하며, 이는 해당 파드가 노드에 존재할 때에만 발급됩니다.
침해 발생 시에도 유출 범위는 해당 노드의 현재 파드로만 제한됩니다.
클러스터 전체 자격 증명은 사용되지 않으며, 이는 보안 CNI 구성과 유사한 전략입니다.

✅ 운영의 단순함이 곧 보안

Istio Ambient Mode는 운영 측면에서도 보안을 강화합니다:

사이드카 모델은 프록시 주입, 디플로이 변경, 재시작 등 복잡한 운영 과정을 요구합니다.
ztunnel 및 waypoint proxy는 애플리케이션과 무관하게 독립적으로 업그레이드 및 패치할 수 있으며, 이는 더 빠르고 예측 가능한 보안 업데이트를 가능하게 합니다.
보안 기능을 플랫폼 인프라 수준으로 유지함으로써, 애플리케이션 배포와 별도로 신속한 보안 대응이 가능합니다.

✅ 다중 테넌트 L7 프록시를 피하는 구조

Ambient Mesh에서는 각 서비스 계정(Identity)별로 전용 L7 Proxy (Waypoint Proxy) 를 배포합니다.
이를 통해 여러 테넌트가 하나의 프록시를 공유하는 경우 발생할 수 있는 정책 충돌, 보안 리스크, 비용 귀속 문제를 방지합니다.
CVE 발생 가능성이 높은 L7 영역의 공격 표면을 워크로드 간 공유하지 않도록 설계되어 있습니다.

✅ 사이드카는 여전히 지원됨

사이드카 모델에 익숙한 사용자와 보안 경계에 익숙한 조직을 위해, Istio는 사이드카 기반 배포도 계속 지원합니다.
Ambient 모드와 사이드카 모드는 동일한 메시 내에서 공존 가능하며, 플랫폼 소유자가 선택적으로 운영할 수 있습니다.
특정 고급 최적화가 필요한 경우에는 여전히 사이드카가 유효한 선택지가 될 수 있습니다.

Ambient Mode는 단순히 사이드카를 제거하는 것 이상의 의미를 지닙니다.

L4-L7 계층 분리, 운영의 단순화, 다중 테넌트 격리 등을 통해 더욱 강화된 보안 태세를 갖출 수 있으며, 이는 실제 운영 환경에서의 보안 유지 보수 부담을 획기적으로 줄여줍니다.

요청하신 세 가지 항목만 ### ✅ 형식의 h3으로 사용하고, 나머지는 문장의 형태로 상세하게 풀어써서 정리한 버전을 아래에 제공합니다. 블로그용 마크다운 포맷에 맞춰 구성했습니다.

👉 Step 05. 앰비언트 메시 호환성 개선: 인팟 트래픽 리디렉션의 혁신

Istio Ambient Mesh는 사이드카 없는 메시 구조를 목표로 하며, 그 경량성과 단순성으로 인해 주목받았습니다. 그러나 초기 구현에서는 다양한 Kubernetes 클러스터 환경과 CNI(Container Network Interface) 구현체들과의 충돌 문제가 지속적으로 발생했습니다. 특히, 트래픽 리디렉션을 위해 사용되었던 초기 메커니즘은 호스트 네트워크 네임스페이스를 활용하면서 예상치 못한 부작용을 초래했습니다. 이를 해결하기 위해 Istio 프로젝트는 근본적인 아키텍처 개선을 추진하게 되었고, 그 핵심이 바로 '인팟(In-Pod) 트래픽 리디렉션' 메커니즘입니다.

✅ An innovative traffic redirection mechanism between workload pods and ztunnel

Istio Ambient의 새로운 리디렉션 메커니즘은, 사이드카 없이도 사이드카와 동일한 동작을 구현하는 방식으로 구성됩니다.

핵심은 ztunnel이라는 노드 로컬 프록시가 포드 외부에서 실행되지만, 포드의 네트워크 네임스페이스 안에 직접 리디렉션 소켓을 생성하여 포드 내부에서 프록시가 작동하는 것처럼 보이게 만드는 것입니다.

이를 위해 Istio는 Linux 커널의 저수준 기능을 활용합니다.

istio-cni 에이전트는 포드가 생성되거나 메시 등록 대상이 될 때, 포드의 네트워크 네임스페이스에 진입하여 해당 네임스페이스의 file descriptor를 추출합니다. 그리고 이 디스크립터를 ztunnel에게 전달함으로써, ztunnel이 포드 내부 네임스페이스에 리스닝 소켓을 생성할 수 있게 됩니다.

이 구조는 사이드카가 없는 상태에서 사이드카와 동일한 트래픽 캡처 및 프록싱을 가능하게 합니다.

네트워크 정책(NetworkPolicy) 적용도 유지됩니다.

리디렉션이 포드 내부에서만 이루어지므로, 외부에서 정책을 설정하는 CNI(Cilium, Calico, AWS VPC CNI 등)의 동작을 방해하지 않으며, 정책 간섭이나 충돌 없이 메시와 공존할 수 있게 됩니다.

✅ How did we get here? 우리는 어떻게 여기까지 왔을까?

초기 알파 단계에서 Ambient Mesh는 트래픽 리디렉션을 노드의 호스트 네임스페이스에서 수행했습니다.

포드에서 발생한 트래픽은 호스트 네트워크를 통해 ztunnel로 전달되었고, 이는 기본 CNI와 충돌할 수밖에 없는 구조였습니다.

예를 들어, 네트워크 정책을 eBPF나 iptables로 구현한 CNI가 호스트 네임스페이스에 네트워크 경로를 설정하고 있을 경우, Istio의 리디렉션 규칙이 이를 덮어쓰거나 비활성화시키는 문제가 생겼습니다. 또한, 호스트 네임스페이스 기반 리디렉션은 포드 간 네트워크 경로의 다양성(e.g. 오버레이, 터널, 사용자 공간 네트워크 처리 등)에 따른 예외 처리를 수용할 수 없었습니다.

이러한 이유로 프로젝트는 기존 방식을 폐기하고 새로운 접근 방식을 모색하게 되었습니다.

사이드카 방식의 장점을 차용하되, 사이드카를 직접 주입하지 않는 구조를 설계한 결과가 바로 인팟 리디렉션입니다.

✅ Technical deep dive of in-Pod traffic redirection

Istio Ambient Mesh는 사이드카 없이도 메시 기능을 제공하기 위해, 각 노드에 두 개의 Kubernetes DaemonSet 형태의 컴포넌트를 배포합니다.

하나는 메시 트래픽을 프록싱하고 L4 수준의 정책을 적용하는 ztunnel, 다른 하나는 포드를 메시로 등록하는 작업을 수행하는 istio-cni 노드 에이전트입니다.

기존 모델: 왜 폐기했는가?

초기 앰비언트 메시 구현에서 포드는 다음과 같은 방식으로 메시로 등록되었습니다. 먼저, istio-cni 노드 에이전트는 네임스페이스에 istio.io/dataplane-mode=ambient 라벨이 지정된 포드를 감지합니다. 그리고 해당 포드의 모든 트래픽(수신/송신)을 가로채기 위해 호스트 네트워크 네임스페이스에 리디렉션 규칙을 설치하고, 이 트래픽을 노드 내의 ztunnel로 전달하도록 구성했습니다.

이 방식은 알파 버전의 자리표시자로써 동작은 했지만, 여러 가지 구조적인 한계가 명확히 드러났습니다.

Linux 네트워킹 스택은 다양한 방식으로 구현될 수 있으며, 네트워크 네임스페이스 간 패킷을 전달하는 메커니즘도 제각기 다릅니다. 일부는 터널링을 사용하고, 일부는 오버레이 네트워크, 또는 사용자 공간 기반 라우팅을 사용합니다. 이런 다양한 환경에서는 호스트 네임스페이스에서의 리디렉션 방식이 제대로 동작하지 않거나 충돌을 일으키는 경우가 많았습니다.

또한, 호스트 네임스페이스에 규칙을 설정하는 방식은 CNI가 설정한 정책과 충돌하거나 정책을 무력화시킬 위험이 있었으며, 네트워크 정책이 언제 어떻게 적용되는지도 불확실해졌습니다. 이로 인해 Istio는 보다 일반적인 환경에서도 안정적으로 동작할 수 있는 새로운 모델이 필요하다는 결론에 이르렀습니다.

새로운 모델: 네트워크 네임스페이스 내부에서의 리디렉션

새로운 앰비언트 메시 모델에서는 포드의 트래픽 리디렉션을 포드 네트워크 네임스페이스 내부에서 수행하도록 변경하였습니다. 이 구조는 사이드카처럼 동작하지만, 실제로는 사이드카 없이 외부의 ztunnel이 내부 동작을 대신 수행합니다.

과정은 다음과 같습니다:

새로운 포드가 시작되거나 기존 포드가 앰비언트로 추가되면, CRI(Container Runtime Interface)는 CNI 플러그인을 트리거합니다. 이 플러그인은 노드에 있는 istio-cni 에이전트에 이벤트를 전달하고, 리디렉션 구성이 완료될 때까지 포드 시작을 잠시 차단합니다.
istio-cni는 포드의 네트워크 네임스페이스에 직접 진입하여 로컬 네트워크 리디렉션 규칙(iptables 또는 eBPF 기반)을 설정합니다. 이를 통해 수신/송신 트래픽은 ztunnel의 잘 알려진 포트(15001, 15006, 15008)로 리디렉션됩니다.
동시에, istio-cni는 Unix Domain Socket을 통해 ztunnel에 포드의 네임스페이스 file descriptor를 전달하여, ztunnel이 해당 네임스페이스 내에 직접 리스닝 소켓을 생성할 수 있도록 합니다.
결과적으로, ztunnel은 자체적으로 프록시 인스턴스를 스핀업하고 해당 포드 전용으로 작동하며, 모든 리디렉션은 포드 내부에서 투명하게 수행됩니다.

이 과정을 통해 포드가 앰비언트 메시로 성공적으로 추가되면, 트래픽은 완전히 암호화된 상태(mTLS)로 메시를 통과하며, 사용자 애플리케이션은 메시 존재를 인식하지 못합니다.

다음은 트래픽 흐름에 대한 다이어그램 예시입니다:

그리고 또 하나의 다이어그램은 메시 내 포드 간 mTLS 암호화 트래픽 흐름을 보여줍니다:

또한 메시 외부에서 들어오는 평문 트래픽도 여전히 허용 및 정책 적용이 가능하며, 이전 구조와 동일한 방식으로 처리됩니다.

이 방식으로 얻는 것들

이 새로운 트래픽 리디렉션 모델의 가장 큰 성과는 다음과 같습니다:

모든 리디렉션이 포드 내부 네임스페이스에서 이루어지므로, 사이드카가 없는 사이드카 구조가 실현됩니다.
외부 CNI(Cilium, Calico, AWS CNI 등)의 동작을 침범하지 않으며, 네트워크 정책과 충돌이 발생하지 않습니다.
ztunnel은 여전히 외부에 존재하지만, 마치 포드 내부 프록시처럼 동작하며 완전한 호환성과 보안을 제공합니다.
Istio Ambient Mesh는 이제 모든 주요 Kubernetes 플랫폼과 CNI 구현에서 안정적으로 작동할 수 있습니다.

👉 Step 06. Fast, Secure, and Simple: Istio Ambient Mode의 GA 도달

Istio 프로젝트는 1.24 릴리스를 통해 앰비언트 데이터 플레인 모드의 General Availability(GA) 도달을 공식 발표했습니다. 이번 발표를 통해 ztunnel, 웨이포인트, 그리고 관련 API가 Stable 단계로 승격되었으며, 이는 Istio의 기능 개발 로드맵에서 마지막 단계에 해당합니다. 이제 앰비언트 모드는 모든 프로덕션 환경에서 사용할 준비가 완료되었으며, 사용자들에게 사이드카 없는 경량 메시 구조를 선택할 수 있는 완전한 자유를 제공합니다.

앰비언트 메시의 참조 구현은 2022년 9월에 소개되었으며, 그 이후로 26개월에 걸쳐 Solo.io, Google, Microsoft, Intel, Huawei, IBM, Red Hat 등 수많은 기여자들의 협업을 통해 안정성과 확장성이 대폭 향상되었습니다. 이번 GA 발표는 Istio가 사이드카 기반 구조 외에도 경량화된 메시 형태로도 실무 배포에 적합하다는 확신을 제공합니다.

✅ How does ambient mode make adoption easier?

앰비언트 메시의 핵심 아키텍처 혁신은 L4(네트워크 계층)와 L7(애플리케이션 계층)의 기능을 서로 다른 두 구성요소로 분리했다는 점입니다. 이를 통해 기존의 사이드카 방식보다 훨씬 유연하고 경량화된 방식으로 Istio를 적용할 수 있게 되었습니다.

데이터 평면의 구조: ztunnel과 웨이포인트의 역할

ztunnel(제로 트러스트 터널) 은 L4 계층의 공유 노드 프록시로 동작하며, 암호화된 트래픽(mTLS), 간단한 인증 정책, 원격 측정 기능 등을 제공합니다. 사이드카 방식과 달리, 각 애플리케이션 포드에 독립적으로 사이드카를 배포할 필요가 없기 때문에, 클러스터의 전체 리소스 사용량이 대폭 감소합니다.
웨이포인트(Waypoint Proxy) 는 선택적인 L7 프록시 역할을 수행하며, 트래픽 라우팅, 고급 인가 정책 적용, 재시도 및 로드 밸런싱 같은 복잡한 애플리케이션 계층 기능을 외부에서 처리합니다. 웨이포인트는 네임스페이스 단위로 확장할 수 있으며, 포드 수에 비례하여 늘리지 않아도 되기 때문에 사이드카 방식 대비 상당한 수준의 리소스 절감이 가능합니다.

유연한 채택 경로 제공

기존의 사이드카 방식은 "주입 여부"라는 이진적 선택만 제공했던 반면, 앰비언트 모드는 점진적 채택 경로를 제공합니다. 예를 들어 다음과 같은 단계적 채택이 가능합니다:

L4 보안 오버레이부터 시작
가장 먼저 ztunnel만 배포하여 전체 트래픽을 mTLS로 암호화하고 인증 정책 및 원격 측정을 수행할 수 있습니다. 이 단계만으로도 많은 조직의 보안/관찰 요구사항을 충족시킬 수 있습니다.
필요한 네임스페이스에만 L7 프록시 적용
전체 워크로드가 아닌, L7 기능이 필요한 네임스페이스에만 웨이포인트를 추가하여 트래픽 제어 및 고급 라우팅 기능을 사용할 수 있습니다.

이 접근 방식은 기능을 온디맨드 방식으로 확장할 수 있게 하며, 운영 복잡도를 낮추고 자원 사용량을 최소화할 수 있습니다.

사이드카 우회 문제 해결 및 보안 강화

과거 사이드카 모델에서는 컨테이너가 사이드카를 우회하거나 충돌을 일으킬 가능성이 존재했습니다. 반면, 앰비언트 모델에서는 모든 트래픽이 L4 수준에서 제어되기 때문에 우회가 불가능하며, 훨씬 더 안전한 구조로 메시가 동작하게 됩니다.

또한, 포트 충돌 문제 해결, 예약 포트의 자유로운 사용, 서버 우선 프로토콜 지원 등 기존 모델의 제약을 모두 해소할 수 있습니다.

GA의 의미와 기대 효과

앰비언트 모드가 GA에 도달했다는 것은 단순한 기능 릴리스가 아니라, Istio가 새로운 데이터 평면 구조를 중심으로 미래를 설계하고 있다는 것을 의미합니다.

사이드카 없는 구조로 메시의 진입 장벽을 낮추고,
점진적 도입으로 리스크 없이 실험과 확장이 가능하며,
ztunnel과 웨이포인트 구조를 통해 보안과 성능을 모두 확보할 수 있습니다.

결론적으로, 이번 GA는 Istio 사용자들에게 사이드카 방식과 앰비언트 방식을 상황에 따라 선택하고 조합할 수 있는 유연성을 제공하며, 운영 효율성과 성능 최적화라는 두 마리 토끼를 동시에 잡을 수 있는 새로운 시대를 여는 전환점이라 할 수 있습니다.

📌 Conclusion

이번 스터디를 통해, Istio Ambient Mesh가 단순한 개념 단계를 넘어 실제 프로덕션 환경에서도 확장성과 호환성을 갖춘 실용적인 구조로 진화했음을 확인할 수 있었습니다.

특히 다음과 같은 관점에서 의미 있는 인사이트를 얻을 수 있었습니다:

트래픽 리디렉션을 포드 내부에서 수행함으로써, Cilium, Calico, AWS VPC CNI 등 모든 주요 CNI와의 충돌 없이 메시 구성이 가능해졌습니다.
ztunnel과 웨이포인트 구조를 통해, 사용자는 메시 기능을 필요에 따라 L4/L7 단위로 조절할 수 있으며, 리소스 낭비 없이 운영 규모에 따라 조정할 수 있습니다.
사이드카가 제거됨으로써 배포 복잡도와 운영 오버헤드가 감소하였으며, 실제 클러스터 리소스 절감 측면에서도 높은 효과를 기대할 수 있습니다.

이러한 구조는 특히 다음과 같은 환경에서 적극적으로 고려해볼 수 있습니다:

보안 요구는 높지만 L7 복잡도가 낮은 마이크로서비스 환경
사이드카 주입이 어려운 시스템 아키텍처나 플랫폼(KNative 등)
메시의 점진적 도입을 시도 중인 대규모 조직

xgro

안녕하세요! DevOps 엔지니어 이재찬입니다. 블로그에 대한 피드백은 언제나 환영합니다! 기술, 개발, 운영에 관한 다양한 주제로 함께 나누며, 더 나은 협업과 효율적인 개발 환경을 만드는 과정에 대해 인사이트를 나누고 싶습니다. 함께 여행하는 기분으로, 즐겁게 읽어주시면 감사하겠습니다! 🚀

다음 포스트