결론부터 말하면, 새로 Istio를 도입하는 Kubernetes 환경이라면 이제 Ambient를 먼저 검토할 이유가 충분하다. 다만 Ambient는 “L7 프록시를 없애는 기술”이 아니다. 모든 Pod에 붙이던 Envoy sidecar를 없애고, L4 보안은 노드별 ztunnel로 공통화하며, HTTP·gRPC 같은 L7 기능이 필요한 곳에만 waypoint Envoy를 두는 구조다.
Istio를 검토할 때 여전히 가장 익숙한 그림은 애플리케이션 컨테이너 옆에 Envoy sidecar가 붙어 있는 모습입니다. 이 구조는 오랫동안 운영되며 충분히 검증됐고, mTLS부터 세밀한 L7 트래픽 제어까지 일관되게 제공합니다.
그런데 서비스와 Pod 수가 늘어날수록 질문도 생깁니다. 모든 Pod가 정말 자기 전용 L7 프록시를 가져야 할까요? 데이터베이스 연결이나 단순한 내부 TCP 통신에도 HTTP를 해석할 수 있는 Envoy가 항상 필요할까요? 플랫폼 팀이 프록시를 업그레이드하려고 애플리케이션 Pod까지 다시 시작해야 하는 구조가 최선일까요?
Istio Ambient Mesh는 이 문제를 정면으로 다룹니다. 2024년 11월 Istio 1.24에서 안정 상태가 됐고, Istio 프로젝트는 이후 신규 사용자뿐 아니라 기존 sidecar 사용자도 Ambient 전환을 적극적으로 검토하고 있다고 설명합니다. 그렇다고 sidecar가 폐기되는 것은 아닙니다. 공식 로드맵도 sidecar를 폐기하지 않으며 전환은 자발적이라고 분명히 밝힙니다.
이 글에서는 Ambient가 실제로 무엇을 바꾸는지, 사람들이 왜 이 방식에 끌리는지, 어떤 환경에서는 여전히 sidecar가 더 안전한 선택인지 차근차근 살펴보겠습니다.
먼저 바로잡을 오해: Ambient는 프록시 없는 메시가 아니다
“sidecarless”라는 표현 때문에 Ambient를 프록시 없는 서비스 메시로 이해하기 쉽습니다. 하지만 Ambient에도 프록시는 있습니다. 단지 프록시의 위치와 책임을 바꿉니다.
| 계층 | Sidecar 모드 | Ambient 모드 |
| L4 보안·전송 | 각 Pod의 Envoy가 처리 | 각 노드의 ztunnel이 처리 |
| L7 HTTP·gRPC 처리 | 각 Pod의 Envoy가 항상 가능 | 필요한 서비스·namespace의 waypoint가 처리 |
| 배포 단위 | 애플리케이션 Pod마다 1개 | 노드별 ztunnel + 선택적 waypoint |
| 프록시 구현 | Envoy | ztunnel은 Rust, waypoint는 Envoy |
| 운영 책임 | 애플리케이션 배포와 강하게 결합 | 플랫폼 구성요소로 분리 |
ztunnel은 L3·L4만 처리하는 가벼운 노드 프록시입니다. 워크로드 identity 기반 mTLS, L4 authorization, TCP 관측성과 암호화된 터널을 담당합니다. HTTP 요청을 종료하거나 헤더를 읽지는 않습니다.
반면 waypoint는 Envoy 기반 L7 프록시입니다. HTTP 헤더 기반 라우팅, retry, timeout, circuit breaking, fault injection, L7 authorization, 요청 단위 메트릭과 추적이 필요할 때 사용합니다. 보통 namespace나 서비스 같은 보안 경계 단위로 공유하며, 애플리케이션 Pod 밖에서 별도로 설치하고 확장합니다.
따라서 정확한 표현은 “Ambient가 L7 프록시를 제거한다”가 아니라 “모든 워크로드에 L7 프록시를 강제하지 않는다”입니다.
그림: ztunnel과 waypoint를 거치는 Ambient L7 데이터 경로 · 출처: Istio Ambient data plane 공식 문서, Apache-2.0
사람들이 Ambient로 가고 싶어하는 첫 번째 이유: 프록시 비용의 단위가 바뀐다
Sidecar 모드에서는 Pod가 하나 늘어날 때 Envoy도 하나 늘어납니다. 애플리케이션이 20개이고 각 서비스가 10개 Pod로 실행된다면 프록시도 200개입니다. 각 프록시는 CPU와 메모리를 요청하고, 설정을 받아 들고, 연결과 텔레메트리를 처리합니다.
이 방식의 장점은 격리가 명확하다는 것입니다. 각 워크로드가 자기 프록시를 가지므로 부하와 장애 범위가 Pod 단위로 나뉩니다. 반면 실제 트래픽이 적은 Pod에도 최악의 순간을 고려해 프록시 자원을 예약해야 하므로, 복제본 수가 많고 트래픽 편차가 큰 환경에서는 사용하지 않는 여유 자원이 누적됩니다.
Ambient는 비용의 단위를 바꿉니다.
- ztunnel은 노드마다 하나씩 실행됩니다.
- L7이 필요 없는 워크로드는 ztunnel만 사용합니다.
- L7이 필요한 서비스만 waypoint를 사용합니다.
- waypoint는 일반 Kubernetes Deployment처럼 여러 워크로드가 공유하고 수평 확장할 수 있습니다.
즉 비용이 사라지는 것이 아니라 Pod별 고정 비용이 노드별·L7 경계별 공유 비용으로 이동합니다. 플랫폼 팀은 실제 L4와 L7 트래픽 규모에 맞춰 ztunnel과 waypoint를 각각 용량 계획할 수 있습니다.
공식 Istio 1.24 벤치마크에서 초당 1,000개의 1KB HTTP 요청을 처리할 때, 2 worker sidecar 하나는 약 0.20 vCPU와 60MB, waypoint 하나는 약 0.25 vCPU와 60MB, ztunnel 하나는 약 0.06 vCPU와 12MB를 사용했습니다. 이 수치는 특정 하드웨어와 테스트 조건의 참고값이지 운영 환경의 성능 보장이 아닙니다. 중요한 것은 개별 숫자보다 ztunnel과 waypoint를 독립적으로 배치할 수 있다는 구조입니다.
그림: Istio 1.24 공식 HTTP/1.1 P99 지연 시간 비교. 특정 벤치마크 환경의 결과이며 일반적인 성능 보장이 아니다 · 출처: Istio Performance and Scalability 공식 문서, Apache-2.0
두 번째 이유: 메시 도입과 애플리케이션 재시작을 분리한다
Sidecar 주입은 애플리케이션 Pod의 형태를 바꿉니다. namespace에 injection label을 붙여도 이미 실행 중인 Pod에는 sidecar가 생기지 않으므로 재시작이 필요합니다. 프록시 버전이나 주입 템플릿을 바꿀 때도 워크로드 롤링 재시작을 관리해야 합니다.
Ambient에서는 namespace나 워크로드에 ambient label을 붙이는 것만으로 실행 중인 Pod를 L4 메시 안에 등록할 수 있습니다. 애플리케이션 컨테이너의 spec을 바꾸지 않고 sidecar를 추가하지도 않습니다.
이 변화가 특히 중요한 대상은 다음과 같습니다.
- 재시작 비용이 큰 stateful workload
- 실행 시간이 짧아 sidecar 시작·종료와 충돌하기 쉬운 Job
- 수백 개 Deployment를 여러 팀이 나눠 관리하는 클러스터
- 플랫폼 팀이 애플리케이션 릴리스와 별개로 메시를 업그레이드하려는 조직
다만 기존 sidecar에서 Ambient로 옮길 때는 순서를 지켜야 합니다. 공식 가이드는 waypoint 활성화, ambient 등록, sidecar injection 제거, 기존 Pod 재시작의 순서를 권장합니다. Ambient 등록 자체에는 재시작이 필요 없지만, 기존 Pod에서 이미 실행 중인 sidecar를 제거하려면 결국 한 번은 Pod를 교체해야 합니다.
세 번째 이유: L4 보안과 L7 기능을 단계적으로 도입할 수 있다
전통적인 sidecar는 기능이 풍부한 대신 사실상 묶음 상품입니다. mTLS만 필요해도 각 Pod는 HTTP 라우팅과 retry를 수행할 수 있는 Envoy 전체를 가집니다.
Ambient는 메시 도입을 두 단계로 나눕니다.
- 먼저 ztunnel로 워크로드 identity, mTLS, L4 authorization과 TCP telemetry를 적용합니다.
- 실제로 HTTP 인식이 필요한 namespace나 서비스에만 waypoint를 추가합니다.
이 방식은 서비스 메시를 한 번에 전사 적용하기 어려운 조직에 현실적인 진입점을 제공합니다. 처음에는 “클러스터 내부 통신을 identity 기반 mTLS로 암호화하고 L4 정책을 통일한다”는 목표만 달성하고, 이후 canary routing이나 L7 authorization이 필요한 서비스만 선택할 수 있습니다.
L7 기능이 필요한 대표적인 경우는 다음과 같습니다.
- URL·헤더·메서드 기반 라우팅과 인가
- HTTP retry, timeout과 circuit breaking
- 트래픽 분할과 fault injection
- 요청 단위 메트릭, 액세스 로그와 분산 추적
Ambient의 매력은 L7을 포기하는 데 있지 않습니다. L7이 필요한 이유와 비용을 서비스별로 명시하게 만드는 데 있습니다.
네 번째 이유: 플랫폼 팀과 애플리케이션 팀의 책임 경계가 선명해진다
Sidecar는 애플리케이션 Pod 안에 있지만 대부분 플랫폼 팀이 관리합니다. 이 애매한 위치가 운영 갈등을 만듭니다.
- 애플리케이션 팀은 요청하지 않은 컨테이너와 리소스 예약을 받아들여야 합니다.
- 플랫폼 팀은 프록시를 업그레이드하려고 애플리케이션 배포 일정을 조율해야 합니다.
- 장애가 나면 애플리케이션과 sidecar 중 어느 쪽이 원인인지 함께 조사해야 합니다.
- HPA, startup probe와 Job 종료 같은 동작이 sidecar 수명주기의 영향을 받을 수 있습니다.
Ambient의 ztunnel과 waypoint는 애플리케이션 Pod 밖에 있는 명시적인 인프라 구성요소입니다. 플랫폼 팀은 프록시 배포, 확장과 업그레이드를 책임지고, 애플리케이션 팀은 어떤 L4·L7 정책이 필요한지 선언합니다.
특히 waypoint가 Kubernetes Gateway API를 사용한다는 점도 중요합니다. waypoint 자체는 Gateway 리소스로 배포하고, HTTPRoute와 AuthorizationPolicy 같은 정책은 대상 서비스에 연결합니다. 프록시 토폴로지와 애플리케이션 배포를 분리하면서 Kubernetes 표준에 가까운 운영 모델을 만들 수 있습니다.
다섯 번째 이유: L7 요청이 프록시를 통과하는 횟수를 줄일 수 있다
Sidecar 모드에서 서비스 A가 서비스 B를 호출하면 일반적으로 요청은 A의 sidecar와 B의 sidecar를 차례로 통과합니다. L7 처리가 출발지와 목적지 두 곳에서 발생합니다.
Ambient에서 L7 정책은 기본적으로 목적지 waypoint가 담당합니다. A의 ztunnel이 B를 담당하는 waypoint로 요청을 보내고, waypoint가 정책을 처리한 뒤 B 노드의 ztunnel로 전달합니다. 같은 요청에 대해 L7 Envoy를 한 번만 통과하는 구조입니다.
이것이 항상 더 빠르다는 뜻은 아닙니다. waypoint까지의 네트워크 경로, 공유 프록시의 부하, 연결 재사용, 패킷 크기와 정책 복잡도에 따라 결과는 달라집니다. 그러나 동일한 L7 처리를 양쪽 sidecar에서 반복하던 경로를 목적지 중심의 한 지점으로 단순화할 가능성은 분명합니다.
성능을 판단할 때는 제품 소개 자료의 평균값보다 실제 환경에서 다음을 측정해야 합니다.
- L4 전용 경로와 L4+L7 경로의 p50·p95·p99 지연 시간
- waypoint가 없는 서비스와 있는 서비스의 CPU·메모리 사용량
- waypoint 수평 확장 중 연결과 오류율 변화
- 장애가 난 ztunnel 또는 waypoint의 영향 범위
- 텔레메트리 수준에 따른 비용 변화
보안은 무조건 좋아지는 것이 아니라 신뢰 경계가 달라진다
Ambient를 설명할 때 “sidecar보다 더 안전하다”고 단정하면 중요한 트레이드오프를 놓칩니다.
Sidecar 모드는 워크로드마다 별도의 프록시와 identity key를 가지므로 프록시 자체가 침해되지 않았다는 전제에서는 가장 세밀한 격리를 제공합니다. 하지만 애플리케이션 컨테이너와 sidecar가 같은 Pod의 네트워크와 보안 경계를 공유합니다. 애플리케이션 Pod가 완전히 침해되면 공격자가 sidecar 통신이나 메시 자격증명에 접근할 위험이 있습니다.
Ambient에서는 애플리케이션 Pod에 메시 키를 두지 않습니다. ztunnel이 자기 노드에 있는 워크로드의 identity와 트래픽을 담당하므로, 일반 애플리케이션 컨테이너가 침해돼도 메시 자격증명을 직접 얻기 어렵습니다.
반대로 ztunnel은 노드의 여러 워크로드를 공유합니다. ztunnel이 침해되면 그 노드에 있는 워크로드의 네트워크와 키가 영향을 받을 수 있습니다. 즉 Ambient는 애플리케이션 Pod와 프록시 사이의 신뢰 경계를 분리하는 대신, 노드 단위 공유 프록시를 중요한 보안 경계로 만듭니다.
| 보안 관점 | Sidecar | Ambient |
| 메시 키 위치 | 각 애플리케이션 Pod의 sidecar | 노드의 ztunnel |
| 애플리케이션 침해 시 | 같은 Pod의 프록시·키 접근 위험 | 메시 키가 애플리케이션 Pod 밖에 있음 |
| 프록시 침해 영향 | 해당 워크로드 중심 | 해당 노드 워크로드로 확대 가능 |
| 격리 단위 | Pod | ztunnel은 노드, waypoint는 선택한 경계 |
어느 쪽이 더 안전한지는 위협 모델에 따라 달라집니다. “애플리케이션 컨테이너를 신뢰할 수 없는 경계로 본다”면 Ambient의 분리가 강점입니다. “공유 노드 프록시의 영향 범위를 최소화하는 것이 최우선”이라면 sidecar의 Pod별 격리가 더 익숙할 수 있습니다.
그렇다면 신규 Istio는 Ambient-first가 정답일까
다음 조건이 많다면 Ambient를 기본 후보로 삼는 편이 합리적입니다.
- Kubernetes 중심의 신규 Istio 환경이다.
- 우선 필요한 기능은 mTLS, workload identity와 L4 authorization이다.
- L7 정책은 일부 namespace나 서비스에만 필요하다.
- Pod와 Job에 sidecar를 주입하고 재시작하는 운영 부담을 피하고 싶다.
- 플랫폼 팀이 메시 데이터 플레인을 애플리케이션과 독립적으로 관리하려 한다.
- Gateway API를 중심으로 트래픽 정책을 표준화할 계획이다.
- 작은 Pod가 많아 Pod별 프록시 자원 예약의 비효율이 크다.
특히 “서비스 메시를 도입하고 싶지만 모든 팀에 sidecar 운영 부담을 전가하고 싶지 않다”면 Ambient의 가치가 큽니다. L4 보안 기반을 먼저 제공하고, L7은 실제 요구가 생길 때 추가할 수 있기 때문입니다.
여전히 Sidecar가 더 보수적인 선택인 경우
Ambient가 안정 상태에 도달했어도 모든 Istio 기능이 같은 성숙도로 옮겨온 것은 아닙니다. 다음 조건에서는 sidecar를 유지하거나 충분한 검증 뒤 전환하는 편이 안전합니다.
1. VM 워크로드를 메시 안에 포함해야 한다
현재 Ambient는 VM 워크로드를 지원하지 않습니다. Kubernetes Pod와 VM을 같은 메시로 묶는 것이 핵심 요구사항이면 sidecar 기반 Istio가 더 적합합니다.
2. 복잡한 멀티클러스터·멀티네트워크 구성이 핵심이다
Ambient의 multi-network, multi-primary multicluster는 Istio 1.29부터 Beta로 제공됩니다. 그러나 primary-remote 토폴로지는 지원하지 않고, 단일 네트워크 구성도 현재 공식 설치 경로의 중심이 아닙니다. 여러 CNI, VM과 복잡한 토폴로지가 섞여 있다면 sidecar의 오랜 운영 경험이 더 안전합니다.
3. EnvoyFilter나 특수 확장에 크게 의존한다
waypoint를 대상으로 하는 EnvoyFilter는 현재 지원되지 않습니다. custom Envoy filter, 특수 Wasm 확장이나 세밀한 프록시 조정이 핵심이라면 기능별 호환성을 먼저 확인해야 합니다.
4. 기존 VirtualService가 매우 복잡하다
Ambient 마이그레이션 가이드에서 VirtualService 지원은 Alpha로 표시되며, Gateway API의 HTTPRoute로 전환하는 경로가 권장됩니다. 같은 워크로드에 VirtualService와 HTTPRoute를 섞을 수도 없습니다. 전용 API에 복잡한 정책이 많이 쌓였다면 변환과 회귀 테스트 비용이 큽니다.
5. L7 authorization에 단 한 순간의 공백도 허용할 수 없다
Sidecar와 Ambient는 같은 클러스터에서 공존할 수 있고 namespace 단위로 되돌릴 수 있습니다. 하지만 L7 정책을 사용하는 기존 워크로드는 현재 완전한 무중단 마이그레이션이 어렵습니다. 전환 중 잠깐의 정책 집행 공백이 생길 수 있어 지속적인 L7 enforcement가 필수라면 유지보수 창이 필요합니다.
기존 Sidecar 환경에서 특히 조심할 마이그레이션 함정
Ambient는 점진적으로 도입할 수 있지만 label 하나로 모든 작업이 끝나는 것은 아닙니다.
혼합 구간에서 waypoint 우회 가능성을 확인한다
Sidecar에서 출발한 트래픽은 마이그레이션 중 목적지 waypoint를 우회할 수 있습니다. 목적지에 waypoint 기반 L7 AuthorizationPolicy를 만들었더라도 출발지 워크로드가 아직 sidecar라면 기대한 정책이 적용되지 않을 수 있습니다.
Ingress에서 들어오는 트래픽도 기본적으로 waypoint를 우회한다
Ingress gateway가 backend로 보내는 요청은 기본 설정에서 waypoint를 거치지 않습니다. waypoint에서 L7 정책을 강제하려면 istio.io/ingress-use-waypoint 설정을 검토해야 합니다.
정책의 대상 지정 방식이 바뀐다
Ambient의 L7 AuthorizationPolicy는 selector 대신 targetRefs로 waypoint나 서비스를 지정합니다. RequestAuthentication과 WasmPlugin도 waypoint에 연결해야 합니다. 기존 YAML을 그대로 옮기면 의도와 다른 계층에 정책이 적용될 수 있습니다.
관측성의 모양도 달라진다
Sidecar에서 ztunnel과 waypoint로 이동하면 reporter label, 메트릭 수집 위치와 tracing span의 형태가 바뀝니다. 기존 대시보드와 알람을 그대로 유지할 수 있다고 가정하면 안 됩니다. istioctl proxy-status도 ztunnel 상태를 보여주지 않으므로 istioctl ztunnel-config workloads 같은 Ambient 전용 점검 방법을 운영 절차에 반영해야 합니다.
의사결정표: 우리 팀에는 무엇이 맞을까
| 질문 | Ambient가 유리한 답 | Sidecar가 유리한 답 |
| 모든 워크로드에 L7이 필요한가 | 일부에만 필요 | 거의 모두 필요 |
| 플랫폼과 앱 릴리스를 분리하고 싶은가 | 강하게 원함 | 현재 결합이 문제없음 |
| VM이 메시의 핵심인가 | 아니오 | 예 |
| 기존 EnvoyFilter 의존도가 높은가 | 낮음 | 높음 |
| Gateway API로 이동할 수 있는가 | 가능 | 복잡한 VirtualService 유지 필요 |
| 공유 프록시를 운영할 준비가 됐는가 | waypoint 용량·장애 격리 가능 | Pod별 격리가 더 익숙함 |
| 기존 L7 정책의 순간적 공백을 허용할 수 있는가 | 유지보수 창 확보 가능 | 전환 공백 불가 |
| 신규 구축인가 | Ambient-first 검토 | 검증된 sidecar 요구가 명확함 |
실무적인 기본값은 다음처럼 정리할 수 있습니다.
신규 Kubernetes 메시라면 Ambient로 L4 기반을 먼저 만들고, L7이 필요한 경계에만 waypoint를 추가한다. 기존 sidecar 환경이라면 기능 목록보다 정책·관측성·보안 집행 경로를 기준으로 namespace 단위 마이그레이션을 설계한다.
Ambient를 검증할 때 확인할 체크리스트
프로덕션 전 작은 namespace에서 다음 항목을 실제로 검증하는 것이 좋습니다.
기능
- ztunnel만 사용할 때 mTLS와 L4 AuthorizationPolicy가 기대대로 작동하는가
- waypoint를 추가한 뒤 HTTPRoute, retry와 timeout이 정확히 적용되는가
- ingress, egress와 cross-namespace 호출이 waypoint를 예상대로 거치는가
- 기존 VirtualService, DestinationRule과 EnvoyFilter 중 대체가 필요한 것은 무엇인가
보안
- waypoint가 없는 L4 구간과 있는 L7 구간의 정책 경계가 명확한가
- STRICT PeerAuthentication과 AuthorizationPolicy 조합이 의도대로 동작하는가
- sidecar와 Ambient가 공존하는 기간에 우회 경로가 없는가
- ztunnel과 waypoint service account의 권한이 최소화돼 있는가
운영
- ztunnel과 waypoint 장애 시 영향 범위와 복구 시간이 얼마인가
- waypoint autoscaling 기준과 최소 replica 수가 적절한가
- 업그레이드와 rollback을 애플리케이션 배포 없이 수행할 수 있는가
- 기존 Grafana dashboard, alert와 trace가 새 데이터 경로를 반영하는가
성능
- L4와 L4+L7 경로의 p95·p99 지연 시간은 얼마인가
- 트래픽이 집중될 때 waypoint CPU·메모리와 queue가 어떻게 변하는가
- sidecar 대비 노드 총예약 자원과 실제 사용량이 얼마나 달라지는가
- 대규모 설정 배포와 endpoint 변화가 안정적으로 수렴하는가
결론: Ambient는 Sidecar의 삭제가 아니라 역할의 재배치다
사람들이 Ambient로 가고 싶어하는 이유는 단순히 sidecar 컨테이너 하나를 없애기 위해서가 아닙니다.
Ambient는 서비스 메시의 책임을 다시 나눕니다. 모든 워크로드에 공통으로 필요한 identity, mTLS와 L4 정책은 노드의 ztunnel로 모으고, 비용이 더 큰 L7 처리는 실제로 필요한 서비스의 waypoint에만 둡니다. 프록시의 생명주기를 애플리케이션 배포에서 분리하고, 플랫폼 팀이 공유 인프라로 운영할 수 있게 합니다.
그래서 신규 Kubernetes 중심 환경이라면 Ambient-first가 자연스러운 기본 후보가 되고 있습니다. 자원 예약, Pod 재시작, Job 호환성, 설정 배포 규모와 팀 간 책임 경계에서 sidecar보다 다루기 쉬운 운영 모델을 제공하기 때문입니다.
하지만 Ambient가 sidecar의 완전한 상위 호환은 아닙니다. VM, 복잡한 multicluster, EnvoyFilter, 기존 VirtualService와 무중단 L7 정책 전환 같은 요구사항은 여전히 주의해야 합니다. 공유 ztunnel과 waypoint가 만드는 장애·보안 경계도 새로 설계해야 합니다.
가장 좋은 선택은 유행을 따르는 것이 아니라 데이터 경로를 명시하는 것입니다. 우리 워크로드 중 어디까지 L4면 충분한지, 어느 서비스에 L7이 필요한지, 누가 프록시를 운영할지, 전환 중 어떤 정책 공백을 허용할 수 있는지를 먼저 답해야 합니다. 그 답이 나왔을 때 Ambient는 단순한 “sidecar 없는 Istio”가 아니라 더 단계적이고 운영 가능한 서비스 메시 설계가 됩니다.
참고한 공식 문서
'클라우드 > Istio' 카테고리의 다른 글
| [Istio] 엥? 내 istio-proxy가 어디 갔지? 🧐 - Kubernetes Native Sidecar 완벽 분석 (0) | 2025.12.19 |
|---|---|
| ICA 시험 완벽 대비! 상황별 Istio 리소스 매핑 치트시트 (VS vs DR 종결) (0) | 2025.11.29 |
| [실전 Istio] Egress Gateway로 외부 트래픽 보안 챙기기 (feat. TLS 발신 설정) (0) | 2025.11.29 |
| [Istio] 우리 집 문단속하기 🚪: 외부 트래픽 전면 차단과 허용 (ALLOW_ANY vs REGISTRY_ONLY) (0) | 2025.11.29 |
| [Istio] 암호화된 트래픽을 열어보지도 않고 라우팅하는 비결: SNI와 PASSTHROUGH 모드 🔒🚦 (0) | 2025.11.29 |
