Ambient Mesh (1)

이번에는 이스티오 블로그를 바탕으로 이론 위주의 내용이 진행될 것이다. 

1️⃣ Ambient Mesh

Introducing Ambient Mesh

 

Ambient Mesh는 사이드카가 없는 istio 데이터 플레인 모드를 의미한다. 사용자에게 사이드카 프록시 대신 인프라에 통합된 데이터 플레인을 사용할 수 있는 옵션을 제공하며 동시에 istio의 핵심 기능인 제로 트러스트 보안, 원격 측정, 트래픽 관리는 그대로 유지된다. ztunnel의 z는 제로 트러스트를 의미한다.

ztunnel은 L4의 역할을 하기 때문에 보안 등의 문제로 L7이 필요할 경우 L7 프록시를 생성하여 두 개의 레이어를 거쳐 목적지에 도달한다. 

사이드카 방식은 각 파드에 사이드카 프록시가 붙어 있어 파드 수명과 동일하게 가져간다. 

 

파드들은 해당 노드에 ztunnel 파드를 공유하여 다른 파드들(동일 노드, 다른 노드)과 안전한 통신 환경을 제공한다. 따라서 파드의 생명주기와 상관없이 프록시가 존재한다. 통신할 때는 hbone이라는 통로를 사용하여 안전하게 통신한다. 

 

 

ztunnel은 L4 기능만 하기 때문에 위에서 말했듯이 Layer7 통제와 정책이 필요 시, Waypoint Proxy 파드를 통하여 기능을 구현한다. 

 

HBONE(HTTP Based Overlay Network Encapsulation)는 애플리케이션 통신 트래픽을 HTTP CONNECT 메서드를 통해 표준 HTTP 터널링을 사용한다. TCP 상위에 HTTP/2를 사용하며, TLS를 통해 상호 인증과 암호를 제공합니다. HBONE tunnel 은 TCP 15008 포트를 사용한다. 

HBONE Protocol

Ztunnel 동작

Ztunnel architecture

Istiod에서 ztunnel 에 xDS Config 구성하며 인증서 베이스로 통신한다. 

 

L4 단계의 통제 보안 정책은 ztunnel을 통해 Secure Overlay를 제공하고 L7 단계의 필터/통제는 목적지 파드에 매칭되는 Waypoint proxy를 통해 기능을 구현한다. 

 

✔️ 통신 흐름

sidecar proxy 를 경유하기 위해서 파드 내에서 초기화 컨테이너로 iptables 설정한 것 처럼, ztunnel 를 경유하기 위해서 istio cni DaemonSet 이 CNI Network Plugin 으로 호스트 네트워크 네임스페이스에 iptables 과 ztunnel 파드 내부에 iptables 에 설정한다. 하지만 현재는 다른 형식을 사용한다. 

 

1) Ambient mode sleep → sidecar mode httpbin

※ foo 네임스페이스는 ambient mode 활성화 : istio.io/dataplane-mode=ambient

※ bar 네임스페이스는 sidecar mode 활성화 : istio-injection: enabled

① sleep 파드에서 bar NS의 httpbin 목적지로 요청

② Istio CNI DaemonSet에 의해서 설정된 iptables 에 따라, 요청 트래픽이 istioout

③ Geneve Tunnel을 통해 pistoout 전달

④⑤ pistoout 은 iptables rule 을 통해 파드 내의 eth0 인터페이스에 port 15001로 redirect

⑥ ztunnel 파드는 목적지 httpbin 정보를 기반으로 노드 B eth0에 전달

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

 

2) Sidecar mode sleep → ambient mode httpbin and helloworld (waypoint proxy enabled)

※ httpbin은 waypoint proxy disabled / helloworld는 waypoint proxy enabled

- Sidecar mode sleep → ambient mode httpbin (waypoint proxy disabled)

①② Sleep 파드는 Sidecar Proxy 에 Iptables rule 에 의해 15001 포트로 redirect 됨

③ 목적지 httpbin 파드는 waypoint proxy disabled로 목적지 파드가 있는 워커 노드 B로 전달됨

④⑤⑥ veth httpbin ↔ httpbin 파드 내 eth0 과 device pair 관계이지만, iptables rule에 의해 가로채어 istioin → pistioin device로 전달

⑦⑧ ztunnel 파드 내에 iptables rule에 의해 port 15008 redirect

⑨ 최종적으로 httpbin 파드로 전달

- Sidecar mode sleep → ambient mode helloworld (waypoint proxy enabled)

①② Sleep 파드는 Sidecar Proxy 에 Iptables rule 에 의해 15001 포트로 redirect

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

④ waypoint 파드는 control plane 을 통해 받은 라우팅 정보로 helloworld 파드가 있는 워커 노드 D로 전달됨

나머지 위와 동일

 

✔️ 사이드카 제약

Istio 아키텍처의 핵심적인 특징 중 하나는 애플리케이션 컨테이너와 함께 배포되는 프로그래밍 가능한 프록시인 사이드카를 사용하는 것이었다. 사이드카를 통해 운영자는 애플리케이션에 큰 수정이나 관련 비용 없이 Istio의 이점을 누릴 수 있다. 

사이드카는 애플리케이션 리팩토링에 비해 상당한 이점을 제공하지만, 애플리케이션과 Istio 데이터 플레인을 완벽하게 분리하지는 못한다. 이로 인해 다음과 같은 몇 가지 제약이 발생한다. 

1) 침입성 (간섭)

사이드카는 쿠버네티스 포드 사양을 수정하고 포드 내 트래픽을 리디렉션하여 애플리케이션에 주입해야 한다. 따라서 사이드카를 설치하거나 업그레이드하려면 애플리케이션 포드를 다시 시작해야 하며, 이는 워크로드에 지장을 줄 수 있다. 

2) 리소스 활용도 저하

사이드카 프록시는 관련 워크로드에 전념하므로, 각 개별 포드의 최악의 사용 상황을 고려하여 CPU 및 메모리 리소스를 프로비저닝해야 한다. 이로 인해 대규모 예약이 발생하여 클러스터 전체의 리소스 활용도가 저하될 수 있다.

3) 트래픽 차단

Istio의 사이드카에서 일반적으로 수행되는 트래픽 캡처 및 HTTP 처리에는 컴퓨팅 비용이 많이 들고 HTTP 구현에 맞지 않는 일부 애플리케이션을 중단시킬 수 있다.

 

✔️ 두 개의 레이어 분리 ( L7 Processing Layer, Secure Overlay )

전통적으로 Istio는 기본 암호화부터 고급 L7 정책까지 모든 데이터 플레인 기능을 단일 아키텍처 구성 요소인 사이드카에 구현한다. 하지만 실제로는 이러한 방식으로 사이드카는 '모두 아니면 전부'의 문제가 된다. 워크로드에 간단한 전송 보안만 필요한 경우에도 관리자는 사이드카를 구축하고 유지하는 데 드는 운영 비용을 부담해야 한다. 사이드카는 워크로드당 고정된 운영 비용을 가지며, 사용 사례의 복잡성에 따라 확장되지 않는다. 

앰비언트 데이터 플레인은 다른 접근 방식을 취합니다. Istio의 기능을 두 개의 개별 계층으로 분할한다. 가장 아래에는 라우팅과 트래픽에 대한 제로 트러스트 보안을 처리하는 보안 오버레이가 있다. 그 위에는 필요에 따라 사용자가 L7 프로세싱을 활성화하여 모든 Istio 기능에 액세스할 수 있다. L7 프로세싱 모드는 보안 오버레이보다 무겁지만, 인프라의 앰비언트 구성 요소로 실행되므로 애플리케이션 파드를 수정할 필요가 없다.

이러한 계층적 접근 방식을 통해 사용자는 Istio를 더욱 점진적으로 도입하여 필요에 따라 네임스페이스별로 메시 없음에서 보안 오버레이, 그리고 완전한 L7 처리로 원활하게 전환할 수 있다. 또한, 서로 다른 앰비언트 계층에서 실행되거나 사이드카를 통해 실행되는 워크로드가 원활하게 상호 운용되므로 사용자는 시간이 지남에 따라 변화하는 특정 요구 사항에 따라 기능을 조합하고 조정할 수 있다. 

 

✔️ 엠비언트 메시의 동작

Istio의 앰비언트 데이터 플레인 모드는 쿠버네티스 클러스터의 각 노드에서 실행되는 공유 에이전트를 사용한다. 이 에이전트는 제로 트러스트 터널(또는 ztunnel )이며, 주요 역할은 메시 내 요소를 안전하게 연결하고 인증하는 것이다. 노드의 네트워킹 스택은 로컬 ztunnel 에이전트를 통해 참여 워크로드의 모든 트래픽을 리디렉션한다. 이를 통해 Istio 데이터 플레인과 애플리케이션의 문제가 완전히 분리되어 운영자가 애플리케이션을 중단하지 않고 데이터 플레인을 활성화, 비활성화, 확장 및 업그레이드할 수 있다. ztunnel은 워크로드 트래픽에 대해 L7 처리를 수행하지 않으므로 사이드카보다 훨씬 효율적이다. 복잡성과 관련 리소스 비용이 크게 감소하여 공유 인프라로 제공하기에 적합하다. 

Ztunnels는 서비스 메시의 핵심 기능인 제로 트러스트를 지원한다. 네임스페이스에 대해 앰비언트 모드가 활성화되면 보안 오버레이가 생성된다. HTTP를 종료하거나 파싱하지 않고도 mTLS, 원격 분석, 인증 및 L4 권한 부여를 위한 워크로드에게 제공한다. 

Ambient 모드가 활성화되고 보안 오버레이가 생성된 후 L7 기능을 활용하도록 네임스페이스를 구성할 수 있다. 이를 통해 네임스페이스는 Virtual Service API , L7 원격 측정 및 L7 권한 부여 정책을 포함한 Istio 전체 기능을 구현할 수 있다. 이 모드에서 작동하는 네임스페이스는 하나 이상의 Envoy 기반 웨이포인트 프록시를 사용하여 해당 네임스페이스의 워크로드에 대한 L7 처리를 수행한다. Istio의 제어 평면은 클러스터의 ztunnel을 구성하여 L7 처리가 필요한 모든 트래픽을 웨이포인트 프록시를 통해 전달한다. 중요한 점은 Kubernetes 관점에서 웨이포인트 프록시는 다른 Kubernetes 배포와 마찬가지로 자동 확장이 가능한 일반 포드일 뿐이다. 웨이포인트 프록시는 최악의 경우 운영자가 예상하는 최대 부하가 아닌 제공하는 네임스페이스의 실시간 트래픽 수요에 맞게 자동 확장될 수 있으므로 이를 통해 사용자에게 상당한 리소스 절감 효과가 있을 것으로 예상한다. 

앰비언트 메시는 mTLS 기반 HTTP CONNECT를 사용하여 보안 터널을 구현하고 경로에 웨이포인트 프록시를 삽입한다. 이 패턴을 HBONE(HTTP 기반 오버레이 네트워크 환경) 이라고 한다. HBONE은 TLS 단독 사용 시보다 트래픽을 더욱 깔끔하게 캡슐화하는 동시에 일반적인 로드 밸런서 인프라와의 상호 운용성을 지원한다. 규정 준수 요건을 충족하기 위해 FIPS 빌드가 기본적으로 사용된다. 

단일 메시 환경에서 사이드카 모드와 앰비언트 모드를 혼합하더라도 시스템의 기능이나 보안 속성에 제한이 발생하지 않는다. Istio 제어 평면은 선택한 배포 모델에 관계없이 정책이 적절하게 시행되도록 보장한다. 엠비언트 모드는 단순히 더 나은 인체공학성과 유연성을 제공하는 옵션을 제공할 뿐이다.

 

✔️ 로컬 노드에서 L7 처리가 없는 이유

앰비언트 모드는 노드에서 공유 ztunnel 에이전트를 사용하여 메시의 제로 트러스트 기능을 처리하는 반면, L7 처리는 별도로 예약된 포드의 웨이포인트 프록시에서 수행된다. 노드에서 공유 전체 L7 프록시를 사용하지 않고 간접 연결을 사용하는 이유는 무엇일까?

1) Envoy는 본질적으로 멀티 테넌트가 아니다. 

따라서 공유 인스턴스에서 제약이 없는 여러 테넌트의 L7 트래픽에 대한 복잡한 처리 규칙을 혼합하는 데 보안 문제가 있다. 이는 L4 처리로 엄격하게 제한함으로써 취약점 노출 영역을 크게 줄였다.

2) ztunnel이 제공하는 mTLS 및 L4 기능은 웨이포인트 프록시에 필요한 L7 처리량에 비해 훨씬 적은 CPU 및 메모리 사용량을 필요로 한다. 

웨이포인트 프록시를 공유 네임스페이스 리소스로 실행하면 해당 네임스페이스의 요구에 따라 독립적으로 확장할 수 있으며, 관련 없는 테넌트에 비용이 불공평하게 분배되지 않다. 

3) ztunnel의 범위를 줄이면 잘 정의된 상호 운용성 계약을 충족할 수 있는 다른 보안 터널 구현으로 대체될 수 있다. 

 

✔️ 추가 홉 처리 방식

엠비언트 모드에서는 웨이포인트가 해당 워크로드와 동일한 노드에 있을 것이라고 보장할 수 없다.언뜻 보기에는 성능 문제로 보일 수 있지만, 궁극적으로는 Istio의 현재 사이드카 구현 방식과 동일한 수준의 지연 시간을 제공할 것이다. 

1) Istio 네트워크 지연 시간의 대부분은 사실 네트워크 자체에서 발생하는 것이 아니다. 

가장 큰 원인은 Istio가 정교한 기능 세트를 구현하는 데 필요한 집중적인 L7 처리이다. 각 연결에 대해 두 단계의 L7 처리 단계(사이드카당 하나씩)를 구현하는 사이드카와 달리, 엠비언트 모드는 이 두 단계를 하나로 통합한다. 대부분의 경우, 이렇게 감소된 처리 비용은 추가 네트워크 홉을 상쇄할 것이다. 

2) 사용자는 종종 첫 번째 단계로 메시를 구축하여 제로 트러스트 보안 태세를 구축한 후 필요에 따라 선택적으로 L7 기능을 활성화한다. 

엠비언트 모드를 사용하면 L7 처리 비용이 전혀 들지 않을 때 L7 처리 비용을 완전히 절감할 수 있다.

 

✔️ 리소스 오버헤드

전반적으로 Istio의 엠비언트 모드는 대부분의 사용자에게 점점 더 예측 가능한 리소스 요구 사항이 줄어들 것으로 예상된다. ztunnel의 제한된 책임으로 인해 노드에서 공유 리소스로 배포할 수 있다. 이렇게 하면 대부분의 사용자에게 필요한 워크로드당 예약을 크게 줄일 수 있다. 또한, 웨이포인트 프록시는 일반적인 쿠버네티스 포드이므로, 제공하는 워크로드의 실시간 트래픽 수요에 따라 동적으로 배포하고 확장할 수 있다. 

반면 사이드카는 각 워크로드에 대해 최악의 상황을 대비하여 메모리와 CPU를 예약해야 한다. 이러한 계산은 복잡하기 때문에 실제로 관리자는 과도하게 프로비저닝하는 경향이 있다. 이로 인해 다른 워크로드를 예약할 수 없는 과도한 예약으로 인해 노드 활용도가 낮아진다. 엠비언트 모드는 노드당 고정 오버헤드가 낮고 동적으로 확장되는 웨이포인트 프록시를 사용하므로 전체적으로 훨씬 적은 리소스 예약이 필요하므로 클러스터를 더욱 효율적으로 사용할 수 있다.

 

✔️ 보안

사이드카는 서비스하는 워크로드와 함께 배치되므로, 한쪽의 취약점이 다른 쪽을 손상시킨다. 엠비언트 메시 모델에서는 애플리케이션이 손상되더라도 ztunnel과 웨이포인트 프록시는 손상된 애플리케이션의 트래픽에 대해 엄격한 보안 정책을 적용할 수 있다. Envoy는 세계 최대 규모의 네트워크 운영업체에서 사용하는 검증된 소프트웨어라는 점을 고려할 때, 함께 실행되는 애플리케이션보다 취약성이 낮을 가능성이 높다.

ztunnel은 공유 리소스이지만 현재 실행 중인 노드에 있는 워크로드의 키에만 접근할 수 있다. 따라서 공격 반경은 노드별 키에 기반한 암호화된 CNI보다 나쁘지 않다. 또한 ztunnel의 제한된 L4 전용 공격 표면 영역과 앞서 언급한 Envoy의 보안 특성을 고려할 때, 이러한 위험은 제한적이며 허용 가능할 것이다. 

마지막으로, 웨이포인트 프록시는 공유 리소스이지만 하나의 서비스 계정만 지원하도록 제한될 수 있다. 하나의 웨이포인트 프록시가 손상되면 해당 웨이포인트와 연결된 자격 증명만 손실되고 다른 것은 아무것도 남지 않다.

 

✔️ 사이드카 사용 유무

그렇다고 해서 사이드카를 사용하지 않는 것은 아니다. 앞으로 많은 메시 사용자에게 엠비언트 메시가 최선의 선택이 될 것이라고 생각하지만, 규정 준수나 성능 튜닝과 같이 전용 데이터 플레인 리소스가 필요한 사용자에게는 사이드카가 여전히 좋은 선택이다. Istio는 사이드카를 계속 지원할 것이며, 중요한 것은 사이드카가 앰비언트 모드와 원활하게 상호 운용될 수 있도록 지원할 것이다. 실제로 출시되고 있는 엠비언트 모드 코드는 이미 사이드카 기반 Istio와의 상호 운용성을 지원한다. 

 

2️⃣ Istio Ambient Mesh를 위한 노드별 프록시

Introducing Rust-Based Ztunnel for Istio Ambient Service Mesh

 

ztunnel(제로 트러스트 터널) 구성 요소는 Istio 비언트 메시를 위해 특별히 설계된 노드별 프록시이다. 엠비언트 메시 내에서 워크로드를 안전하게 연결하고 인증하는 역할을 한다. Ztunnel은 워크로드 HTTP 트래픽을 종료하거나 워크로드 HTTP 헤더를 파싱하지 않고도 mTLS, 인증, L4 권한 부여, 원격 측정과 같은 엠비언트 메시 내 워크로드를 위한 소수의 기능에 집중하도록 설계되었다. ztunnel은 HTTP 원격 측정 및 부하 분산과 같은 Istio의 모든 기능이 구현된 웨이포인트 프록시로 트래픽이 효율적이고 안전하게 전송되도록 보장한다. 

ztunnel은 모든 쿠버네티스 워커 노드에서 실행되도록 설계되었으므로 리소스 사용량을 작게 유지하는 것이 중요하다. Ztunnel은 워크로드에 미치는 영향을 최소화하면서 서비스 메시의 보이지 않는 부분으로 설계되었다. 

사이드카와 유사하게 ztunnel은 xDS 클라이언트 및 CA 클라이언트 역할도 수행한다. 통신 순서는 다음과 같다. 

1) 시작 시 서비스 계정 토큰을 사용하여 Istiod 제어 평면에 안전하게 연결

ztunnel에서 Istiod로의 연결이 TLS를 사용하여 안전하게 설정되면 xDS 클라이언트로서 xDS 구성을 가져오기 시작한다. 이는 사이드카, 게이트웨이 또는 웨이포인트 프록시와 유사하게 작동하지만, Istiod가 ztunnel의 요청을 인식하고 ztunnel용으로 특별히 제작된 xDS 구성을 전송한다는 점이 다르다. 

2) 관리하는 모든 공동 작업 부하를 대신하여 mTLS 인증서를 관리하고 제공하는 CA 클라이언트 역할도 수행

3) 트래픽이 들어오고 나갈 때, 관리하는 모든 공동 배치 워크로드에 대한 인바운드 및 아웃바운드 트래픽(메시 외부 일반 텍스트 또는 메시 내부 HBONE)을 처리하는 핵심 프록시 역할

4) 필요한 경우 ztunnel을 디버깅하는 데 도움이 되는 디버깅 정보가 포함된 관리 서버와 함께 L4 원격 측정(메트릭 및 로그)을 제공

 

✔️ Envoy를 재사용하지 않는 이유

ztunnel은 Envoy 프록시를 사용하여 구현되었습니다. 사이드카, 게이트웨이, 웨이포인트 프록시 등 Istio의 나머지 부분에도 Envoy를 사용하고 있다는 점을 고려하면, Envoy를 사용하여 ztunnel을 구현하는 것은 당연한 일이었다.

Envoy가 다른 사용 사례에는 매우 적합했지만, Envoy에서 ztunnel을 구현하는 것은 쉽지 않았다. 사이드카 프록시나 인그레스 게이트웨이와는 장단점, 요구 사항, 사용 사례가 크게 다르기 때문이다. 게다가 Envoy를 다른 사용 사례에 매우 적합하게 만드는 풍부한 L7 기능 세트와 확장성 같은 요소들이 ztunnel에서는 쓸모없게 되었다. ztunnel에는 이러한 기능이 필요하지 않았기 때문이다.

 

✔️ A purpose-built ztunnel

Envoy를 필요에 맞게 변형하는 데 어려움을 겪은 후 ztunnel을 특수 목적에 맞게 구현하는 방법을 모색하기 시작했다. 처음부터 단일 사용 사례에 집중하여 설계하면, 범용 프로젝트를 저희의 맞춤형 사용 사례에 맞춰 만드는 것보다 더 간단하고 성능이 뛰어난 솔루션을 개발할 수 있을 것이라는 가설이 있었다. ztunnel을 단순하게 만들기로 한 명확한 결정이 이 가설의 핵심이었다. 예를 들어, 지원되는 기능과 통합 기능이 매우 많은 게이트웨이를 다시 작성하는 경우에는 이러한 논리가 적용되지 않을 것이다. 이 특수 목적의 터널에는 두 가지 주요 영역이 포함된다. 

- ztunnel과 Istiod 간의 구성 프로토콜

- ztunnel의 런타임 구현

 

✔️ 설정 프로토콜

Envoy 프록시는 구성에 xDS 프로토콜을 사용한다. 이는 Istio가 원활하게 작동하도록 하는 핵심 요소이며, 풍부하고 동적인 구성 업데이트를 제공한다. 하지만 기존 방식을 벗어나면서 구성은 점점 더 맞춤형으로 바뀌어 훨씬 더 크고 생성 비용도 더 많이 든다. 사이드카에서 1개의 포드를 가진 단일 서비스는 약 350줄의 xDS(YAML 형식)를 생성하는데, 이는 이미 확장이 어려운 문제였다. Envoy 기반 ztunnel은 훨씬 더 나빴고, 일부 영역에서는 N^2개의 확장 속성을 사용했다. ztunnel 구성을 최대한 작게 유지하기 위해, 필요한 정보만 효율적인 형식으로 정확하게 포함하는 특수 제작 구성 프로토콜을 사용하여 조사한 결과 단일 포드는 다음과 같이 간결하게 표현할 수 있었다. 

name: helloworld-v1-55446d46d8-ntdbk
namespace: default
serviceAccount: helloworld
node: ambient-worker2
protocol: TCP
status: Healthy
waypointAddresses: []
workloadIp: 10.244.2.8
canonicalName: helloworld
canonicalRevision: v1
workloadName: helloworld-v1
workloadType: deployment

 

이 정보는 xDS 전송 API를 통해 전송되지만, custom ambient-specific type 을 사용한다. 

전용 API를 사용하면 Envoy 구성 대신 프록시에 로직을 푸시할 수 있다. 예를 들어 Envoy에서 mTLS를 구성하려면 각 서비스의 TLS 설정을 정밀하게 조정하는 동일한 대규모 구성 세트를 추가해야 한다. ztunnel에서는 mTLS 사용 여부를 선언하는 열거형 하나만 있으면 된다. 나머지 복잡한 로직은 ztunnel 코드에 직접 내장된다. 

Istiod와 ztunnel 간의 효율적인 API를 통해 10만 개의 포드가 있는 메시와 같은 대규모 메시에 대한 정보로 ztunnel을 구성할 수 있었고, 구성이 엄청나게 줄어 CPU, 메모리, 네트워크 비용이 절감되었다. 

 

✔️ 런타임 구현 & A Rust-based ztunnel

이름에서 알 수 있듯이 ztunnel은 HTTPS 터널을 사용하여 사용자 요청을 전달한다. Envoy는 이 터널링을 지원하지만, 구성 모델이 저희의 요구 사항에는 제한적이다. Envoy는 요청을 수락하는 것부터 시작하여 요청을 전송하는 것까지 일련의 필터를 통해 요청을 전송하는 방식으로 작동한다. 터널 자체와 사용자 요청이라는 여러 계층의 요청이 있고, 로드 밸런싱 후 포드별 정책을 적용해야 하는 저희의 요구 사항을 고려했을 때, 이전 Envoy 기반 ztunnel을 구현할 때 연결당 이러한 필터를 4번씩 반복해야 했다. Envoy는 메모리에서 자기 자신에게 요청을 전송하는 데 있어 몇 가지 최적화를 제공했지만 여전히 매우 복잡하고 비용이 많이 들었다. 

자체 구현을 구축함으로써 이러한 제약 조건을 처음부터 고려하여 설계할 수 있었다. 또한, 설계의 모든 측면에서 더 큰 유연성을 확보할 수 있었다. 예를 들어, 여러 스레드 간에 연결을 공유하거나 서비스 계정 간 격리를 중심으로 더욱 맞춤형 요구 사항을 구현할 수 있었다. 특수 목적 프록시가 실행 가능하다는 것을 확인한 후 구현 세부 사항을 선택하기 시작했다. 

A Rust-based ztunnel

ztunnel을 빠르고 안전하며 가볍게 만들겠다는 목표에 따라 Rust는 당연한 선택이었다. 하지만 Rust가 첫 번째 선택은 아니었다. Istio가 현재 Go를 광범위하게 사용하고 있다는 점을 고려했을 때, 저희는 Go 기반 구현으로 이러한 목표를 달성할 수 있기를 바랐다. 초기 프로토타입에서는 Go 기반 구현과 Rust 기반 구현의 간단한 버전을 모두 구축했다. 테스트 결과, Go 기반 버전은 성능 및 설치 공간 요구 사항을 충족하지 못했다. 더 최적화할 수 있었을 가능성도 있지만, Rust 기반 프록시가 장기적으로 최적의 구현을 제공할 것이라고 판단했다. 

이러한 제거 과정을 거쳐 Rust가 탄생했고, Rust는 우리에게 딱 맞는 선택이었다. Rust는 고성능, 저리소스 애플리케이션, 특히 네트워크 애플리케이션(서비스 메시 포함)에서 탄탄한 성공 사례를 보유하고 있다. 생태계의 사실상 표준으로 자리 잡은 두 가지 라이브러리인 Tokio와 Hyper 라이브러리를 기반으로 개발하기로 했다. 이 라이브러리들은 광범위한 실전 테스트를 거쳤으며, 고성능 비동기 코드를 쉽게 작성할 수 있다.

 

✔️ Rust-based ztunnel

Workload xDS configuration 워크로드 xDS 구성으로 되어 있으며 localhost:15000/config_dump 워크로드 xDS 구성은 이해하고 디버깅하기가 매우 쉽다. ztunnel 포드 중 하나에서 요청을 보내거나 편리한 명령을 사용하여 확인할 수 있다.

istioctl pc workload

 

워크로드 xDS 구성에는 워크로드와 정책이라는 두 가지 주요 구성이 있다. 워크로드가 앰비언트 메시에 포함되기 전에는 ztunnel의 구성 덤프에서 해당 워크로드를 확인할 수 있다. ztunnel은 엠비언트 활성화 여부와 관계없이 모든 워크로드를 인식하기 때문이다. 예를 들어, 아래는 새로 배포된 helloworld v1 포드의 샘플 워크로드 구성입니다. 이 포드는 메시 외부(out-of-mesh)로 표시되어 있습니다.

{
  "workloads": {
    "10.244.2.8": {
      "workloadIp": "10.244.2.8",
      "protocol": "TCP",
      "name": "helloworld-v1-cross-node-55446d46d8-ntdbk",
      "namespace": "default",
      "serviceAccount": "helloworld",
      "workloadName": "helloworld-v1-cross-node",
      "workloadType": "deployment",
      "canonicalName": "helloworld",
      "canonicalRevision": "v1",
      "node": "ambient-worker2",
      "authorizationPolicies": [],
      "status": "Healthy"
    }
  }
}

protocol: TCP

 

포드가 ambient에 포함된 후(네임스페이스 default를 로 레이블 지정) 해당 protocol값은 로 바뀌어 HBONE ztunnel이 helloworld-v1 포드에서 들어오고 나가는 모든 통신을 HBONE으로 업그레이드하도록 지시한다. 

{
  "workloads": {
    "10.244.2.8": {
      "workloadIp": "10.244.2.8",
      "protocol": "HBONE",
      ...
}

 

워크로드 수준 권한 부여 정책을 배포한 후 정책 구성은 Istiod에서 ztunnel로 xDS 구성으로 푸시되고 아래에 표시된다. 

{
  "policies": {
    "default/hw-viewer": {
      "name": "hw-viewer",
      "namespace": "default",
      "scope": "WorkloadSelector",
      "action": "Allow",
      "groups": [[[{
        "principals": [{"Exact": "cluster.local/ns/default/sa/sleep"}]
      }]]]
    }
  }
  ...
}

 

또한 승인 정책을 참조하여 워크로드의 구성이 업데이트된 것을 확인할 수 있다. 

{
  "workloads": {
    "10.244.2.8": {
    "workloadIp": "10.244.2.8",
    ...
    "authorizationPolicies": [
        "default/hw-viewer"
    ],
  }
  ...
}

 

 

✔️ ztunnel에서 제공하는 L4 원격 측정

예를 들어 목적지 ztunnel에서 소스 포드 IP( peer_ip)와 목적지 포드 IP를 나타내는 HTTP Connect 요청이 표시된다. 

2023-02-15T20:40:48.628251Z  INFO inbound{id=4399fa68cf25b8ebccd472d320ba733f peer_ip=10.244.2.5 peer_id=spiffe://cluster.local/ns/default/sa/sleep}: ztunnel::proxy::inbound: got CONNECT request to 10.244.2.8:5000

 

localhost:15020/metrics사이드카에서 노출하는 것과 동일한 레이블을 사용하여 전체 TCP 표준 메트릭 세트를 제공하는 API 에 액세스하여 워크로드의 L4 메트릭을 볼 수 있다. 

istio_tcp_connections_opened_total{
  reporter="source",
  source_workload="sleep",
  source_workload_namespace="default",
  source_principal="spiffe://cluster.local/ns/default/sa/sleep",
  destination_workload="helloworld-v1",
  destination_workload_namespace="default",
  destination_principal="spiffe://cluster.local/ns/default/sa/helloworld",
  request_protocol="tcp",
  connection_security_policy="mutual_tls"
  ...
}

 

Prometheus와 Kiali를 설치하면 Kiali UI에서 이러한 지표를 쉽게 볼 수 있다.