앰비언트 데이터 플레인

앰비언트 데이터 플레인 (Ambient data plane)

앰비언트 모드에서 워크로드는 세 가지 범주로 나뉠 수 있어요:

출처: Istio 문서

본문

  1. Out of Mesh: 메시 기능이 전혀 활성화되지 않은 일반 파드예요. Istio와 앰비언트 데이터 플레인이 활성화되지 않았어요.
  2. In Mesh: 앰비언트 데이터 플레인에 포함된 파드로, ztunnel이 Layer 4 수준에서 트래픽을 가로채요. 이 모드에서는 파드 트래픽에 L4 정책을 적용할 수 있어요. 이 모드는 istio.io/dataplane-mode=ambient 레이블을 설정하면 활성화돼요. 자세한 내용은 레이블 문서를 참고하세요.
  3. In Mesh, Waypoint enabled: 메시 안에 있으면서 웨이포인트 프록시가 배포된 파드예요. 이 모드에서는 파드 트래픽에 L7 정책을 적용할 수 있어요. 이 모드는 istio.io/use-waypoint 레이블을 설정하면 활성화돼요. 자세한 내용은 레이블 문서를 참고하세요.

워크로드가 어떤 범주에 속하느냐에 따라 트래픽 경로가 달라져요.

메시 내 라우팅 (In Mesh Routing)

아웃바운드 (Outbound)

앰비언트 메시 안의 파드가 아웃바운드 요청을 보내면, 그 요청은 투명하게 리디렉션되어 노드 로컬 ztunnel로 전달되고, ztunnel이 요청을 어디로 어떻게 보낼지 결정해요. 일반적으로 트래픽 라우팅은 쿠버네티스 기본 트래픽 라우팅처럼 동작해요. Service로의 요청은 그 Service 안의 엔드포인트로 보내지고, Pod IP로의 직접 요청은 그 IP로 바로 전달돼요.

다만 목적지의 능력에 따라 동작이 달라져요. 목적지도 메시에 추가되었거나, (사이드카 같은) Istio 프록시 능력을 갖추고 있다면, 요청은 암호화된 HBONE 터널로 업그레이드돼요. 목적지가 웨이포인트 프록시를 가진 경우에는 HBONE으로 업그레이드되는 것에 더해, L7 정책 적용을 위해 요청이 그 웨이포인트로 전달돼요.

Service로 가는 요청의 경우, 그 서비스에 웨이포인트가 있다면 트래픽에 L7 정책을 적용하기 위해 요청이 그 웨이포인트로 보내져요. 마찬가지로 Pod IP로 가는 요청도 그 파드에 웨이포인트가 있다면 L7 정책을 적용하기 위해 그 웨이포인트로 보내져요. Deployment 안의 파드에 연관된 레이블은 다양하게 둘 수 있기 때문에, 어떤 파드는 웨이포인트를 쓰고 어떤 파드는 안 쓸 수도 있긴 해요. 다만 이런 고급 사용 사례는 피하는 걸 일반적으로 권장해요.

인바운드 (Inbound)

앰비언트 메시 안의 파드가 인바운드 요청을 받으면, 그 요청은 투명하게 리디렉션되어 노드 로컬 ztunnel로 전달돼요. ztunnel이 요청을 받으면 Authorization Policy를 적용하고, 그 검사를 통과한 요청만 전달해요.

파드는 HBONE 트래픽이나 평문(plaintext) 트래픽을 받을 수 있어요. 기본적으로 둘 다 ztunnel이 수락해요. 메시 밖에서 온 요청은 Authorization Policy를 평가할 때 피어 신원이 없어요. 사용자는 신원(아무 신원이든, 특정 신원이든)을 요구하는 정책을 설정해서 모든 평문 트래픽을 차단할 수 있어요.

목적지가 웨이포인트 활성화 상태일 때, 소스가 앰비언트 메시에 있다면 소스의 ztunnel이 요청이 정책이 적용되는 웨이포인트를 반드시 거치도록 보장해요. 하지만 메시 밖의 워크로드는 웨이포인트 프록시에 대해 아무것도 모르기 때문에, 목적지가 웨이포인트 활성화 상태여도 요청을 웨이포인트를 거치지 않고 목적지로 직접 보내요. 현재로서는 사이드카와 게이트웨이에서 온 트래픽도 웨이포인트 프록시를 거치지 않으며, 웨이포인트 프록시를 인지하게 되는 것은 향후 릴리스에서 다뤄질 거예요.

데이터플레인 세부사항 (Dataplane details)

신원 (Identity)

앰비언트 메시 안의 워크로드들 사이의 모든 인바운드·아웃바운드 L4 TCP 트래픽은 HBONE, ztunnel, x509 인증서를 통한 mTLS로 데이터 플레인이 보호해요.

mTLS가 강제하듯, 소스와 목적지는 고유한 x509 신원을 가져야 하고, 그 신원들이 그 연결의 암호화된 채널을 맺는 데 사용되어야 해요.

이를 위해 ztunnel은 프록시하는 워크로드들을 대신해 여러 개의 서로 다른 워크로드 인증서를 관리해야 해요. 노드 로컬 파드마다 각각의 고유한 신원(service account)마다 하나씩이에요. ztunnel 자신의 신원은 워크로드들 사이의 mTLS 연결에는 절대 사용되지 않아요.

인증서를 가져올 때, ztunnel은 자기 자신의 신원으로 CA에 인증을 하지만, 다른 워크로드의 신원을 요청해요. 여기서 중요한 것은 CA가 ztunnel이 그 신원을 요청할 권한이 있는지 반드시 강제해야 한다는 점이에요. 노드에서 실행되지 않는 신원에 대한 요청은 거부돼요. 이는 침해된 노드가 전체 메시를 손상시키지 않도록 보장하는 데 핵심적이에요.

이 CA 강제는 Istio의 CA가 파드 정보를 인코딩하는 쿠버네티스 Service Account JWT 토큰을 사용해 수행돼요. 이 강제는 ztunnel과 통합하는 대체 CA에도 요구사항이에요.

ztunnel은 노드에 있는 모든 신원에 대한 인증서를 요청해요. 컨트롤 플레인에서 받은 구성에 기반해서 이를 결정해요. 노드에서 새 신원이 발견되면, 최적화를 위해 낮은 우선순위로 인증서 가져오기 큐에 넣어져요. 다만 요청이 아직 가져오지 않은 특정 신원을 필요로 하면, 즉시 요청돼요.

ztunnel은 또한 이 인증서들이 만료에 가까워지면 순환(rotation)도 처리해요.

텔레메트리 (Telemetry)

ztunnel은 전체 Istio 표준 TCP 메트릭 세트를 내보내요.

L4 트래픽을 위한 데이터플레인 예제 (Dataplane example for Layer 4 traffic)

L4 앰비언트 데이터플레인은 아래 그림에 묘사되어 있어요.

그림은 앰비언트 메시에 추가된 여러 워크로드가 쿠버네티스 클러스터의 노드 W1과 W2에서 실행 중인 모습을 보여줘요. 각 노드에는 ztunnel 프록시 인스턴스가 하나씩 있어요. 이 시나리오에서 애플리케이션 클라이언트 파드 C1, C2, C3는 파드 S1이 제공하는 서비스에 접근해야 해요. L7 트래픽 라우팅이나 L7 트래픽 관리 같은 고급 L7 기능이 필요하지 않으므로, mTLS와 L4 정책 적용을 얻기엔 L4 데이터 플레인으로 충분해요. 웨이포인트 프록시는 필요 없어요.

그림은 노드 W1에서 실행되는 파드 C1과 C2가 노드 W2에서 실행되는 파드 S1과 연결하는 모습을 보여줘요.

C1과 C2의 TCP 트래픽은 ztunnel이 만든 HBONE 연결을 통해 안전하게 터널링돼요. 터널링되는 트래픽의 암호화와 상호 인증에는 Mutual TLS(mTLS)가 사용돼요. 연결 양쪽의 워크로드를 식별하는 데는 SPIFFE 신원이 사용돼요. 터널링 프로토콜과 트래픽 리디렉션 메커니즘에 대한 자세한 내용은 HBONE 및 ztunnel traffic redirection 가이드를 참고하세요.

그림에서 워커 노드 W2의 목적지 파드 S1으로 가는 파드 C3부터의 로컬 트래픽도 로컬 ztunnel 프록시 인스턴스를 지난다는 점을 주목하세요. 그래야 L4 Authorization, L4 Telemetry 같은 L4 트래픽 관리 기능이 노드 경계를 넘는지 여부와 관계없이 트래픽에 동일하게 적용되기 때문이에요.

웨이포인트 활성화 상태의 메시 내 라우팅 (In Mesh routing with Waypoint enabled)

Istio 웨이포인트는 HBONE 트래픽만 받아요. 웨이포인트는 요청을 받으면, 그 트래픽이 자기를 사용하는 Pod나 Service를 위한 것인지 확인해요.

트래픽을 받아들였으면 웨이포인트는 전달하기 전에 L7 정책(AuthorizationPolicy, RequestAuthentication, WasmPlugin, Telemetry 등)을 적용해요.

Pod로 가는 직접 요청은 정책 적용 후 그냥 바로 전달돼요.

Service로 가는 요청에는 웨이포인트가 라우팅과 로드 밸런싱도 적용해요. 기본적으로 Service는 자기 자신으로 라우팅하며, 자기의 엔드포인트들에 걸쳐 L7 로드 밸런싱을 수행해요. 이는 그 Service에 대한 Route로 재정의될 수 있어요.

예를 들어 아래 정책은 echo 서비스로 가는 요청이 echo-v1로 전달되도록 보장해요:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: echo
spec:
  parentRefs:
  - group: ""
    kind: Service
    name: echo
  rules:
  - backendRefs:
    - name: echo-v1
      port: 80

아래 그림은 L7 정책 적용을 위해 웨이포인트가 구성된 경우 ztunnel과 웨이포인트 사이의 데이터 경로를 보여줘요. 여기서 ztunnel은 L7 처리를 위해 트래픽을 웨이포인트 프록시로 HBONE 터널링으로 보내요. 처리가 끝나면 웨이포인트는 선택된 서비스 목적지 파드가 있는 노드의 ztunnel로 두 번째 HBONE 터널을 통해 트래픽을 보내요. 일반적으로 웨이포인트 프록시는 소스나 목적지 파드와 같은 노드에 있을 수도 있고 아닐 수도 있어요.

더 알아보기 (Learn more)