Istio Ambient는 애플리케이션 Pod마다 Sidecar 프록시를 넣는 대신, 노드 단위 ztunnel과 필요에 따라 배치하는 waypoint로 메시 기능을 제공하는 방식이다. 기본 보안 연결과 애플리케이션 계층 처리를 나누어 점진적으로 도입할 수 있다. Ambient 개요는 이 계층 구조를 설명한다.
L4와 L7을 나누는 구조
ztunnel은 노드에서 L4 연결을 처리하며 워크로드 신원을 이용한 상호 TLS, 연결 기반 인가와 관측의 기반이 된다. L4만으로는 HTTP 경로나 헤더를 해석하는 L7 정책을 모두 제공할 수 없다. HTTP 단위의 기능이 필요할 때는 해당 트래픽 경로에 waypoint를 추가한다.
waypoint는 Envoy 기반 프록시이며 애플리케이션과 별도로 설치·확장할 수 있다. 네임스페이스나 서비스 등 선택한 범위에 적용한다. waypoint 안내에 따르면 어떤 트래픽 유형이 waypoint를 사용하는지와 실제 연결 경로를 함께 확인해야 한다.
장점과 한계
애플리케이션마다 프록시 컨테이너를 넣는 관리 부담을 줄이고, L4 보호에서 필요한 L7 기능으로 확장할 수 있다. 프록시 업그레이드와 확장을 업무 Pod의 배포에서 분리하기도 좋다. 다만 워크로드 수와 트래픽에 따라 자원 효과가 다르므로 항상 더 저렴하거나 빠르다고 단정할 수 없다.
노드 단위 구성과 공유 waypoint의 용량·장애 범위를 관리해야 한다. Sidecar 모드의 기능과 설정을 그대로 옮기기보다 지원 기능과 경로를 확인해야 한다. 네임스페이스 등록과 모든 보안 정책 집행이 한 번에 끝나는 것은 아니며, 메시 밖 요청과 외부 시스템 연결도 고려한다.
예약 서비스의 단계적 도입 예시
Ambient 제어면·CNI·ztunnel이 정상 설치된 격리 실습 클러스터를 가정한다. 다음은 새로운 reading-room 네임스페이스를 Ambient 대상으로 선언하는 구조다. 기존 업무 환경에 바로 적용하는 설치 명령이 아니라 라벨의 의미를 설명하는 예시다.
apiVersion: v1
kind: Namespace
metadata:
name: reading-room
labels:
istio.io/dataplane-mode: ambient이 단계에서는 등록된 예약 서비스의 L4 연결을 확인한다. 이후 /reservations 경로에만 적용할 HTTP 정책이 필요하면 waypoint와 적절한 L7 정책을 별도로 구성한다. 등록 라벨 하나가 HTTP 경로별 제어, 재시도, 모든 지표를 자동으로 완성하는 것은 아니다.
waypoint를 반드시 거쳐야 할 때
use-waypoint 라벨은 경로 선택 의도를 나타내지만 그 자체가 모든 우회 경로를 차단하는 보안 규칙은 아니다. waypoint가 준비되지 않았거나 다른 목적지 유형으로 접근할 경우를 검토한다. 반드시 waypoint를 통한 접근만 허용해야 한다면 목적지의 인가 정책으로 그 신원을 요구하는 설계와 실제 거부 시험이 필요하다.
또한 외부 ingress에서 들어온 요청과 메시 내부 서비스 간 요청의 waypoint 사용 조건은 다를 수 있다. 문제를 조사할 때는 호출 주체, 목적지가 Service인지 Pod IP인지, ztunnel과 waypoint 중 어디를 거치는지를 순서대로 확인한다. 기능이 보이지 않는다고 무조건 애플리케이션에 Sidecar를 추가하지 않는다.