Istio Ambient mode의 Pod 불완전 참여 문제 해결책
Istio Ambient mode에서 ztunnel 및 istio-cni 컴포넌트 준비 지연으로 인해 Pod이 불완전하게 메시에 참여하는 Partially Enrolled Pod 문제 발생
Kubernetes는 Pod Ready 상태로 인식하나, 실제로는 트래픽 리디렉션(Traffic Redirection) 규칙 미설정 또는 ztunnel 워크로드 등록 실패로 트래픽 유실 발생
Untaint Controller 도입으로 새 노드에 cni.istio.io/not-ready startup taint를 적용하여 istio-cni 준비 전 워크로드 Pod 스케줄링 차단
Partially Enrolled Pod 발생 메커니즘
Istio Ambient mode에서 Partially Enrolled Pod는 Kubernetes의 Pod Ready 상태와 달리, ztunnel 및 istio-cni 컴포넌트의 준비 상태가 Pod의 네트워크 네임스페이스 설정 및 ztunnel 등록과 동기화되지 않을 때 발생함.
Istio CNI Node Agent: Pod 네트워크 네임스페이스에 트래픽 리디렉션 규칙을 설정하고 ztunnel에 워크로드 정보를 전달하는 핵심 컴포넌트임.
ztunnel: 해당 Pod의 소켓을 통해 인바운드/아웃바운드 트래픽을 처리하는 역할을 수행함.
이 두 컴포넌트 중 하나라도 준비되지 않은 상태에서 워크로드 Pod이 스케줄링되면, Kubernetes는 정상으로 보지만 실제로는 메시 데이터플레인(Mesh Dataplane) 관점에서 불완전한 상태가 되어 트래픽 처리에 실패함. 이는 `ambient.istio.io/redirection` annotation이 `pending` 상태로 남는 경우에 해당하며, 트래픽 유실(Traffic Loss)로 이어질 수 있음.
Kubernetes 스케줄링과 Istio CNI 준비 간의 경합
새로운 노드가 클러스터에 추가될 때, Kubernetes 스케줄러는 Istio CNI DaemonSet Pod의 준비 완료를 일반 워크로드 Pod 스케줄링의 선행 조건으로 보장하지 않음.
동시 스케줄링: 새 노드에서 Istio CNI Pod과 워크로드 Pod이 거의 동시에 스케줄링될 수 있음.
실패 시나리오 1: Istio CNI가 Pod 생성 시점에 호출되지 않거나 Ambient 대상 판정에 실패하면, 트래픽 리디렉션 규칙이 적용되지 않고 워크로드 Pod이 메시 데이터플레인을 우회할 수 있음.
실패 시나리오 2: Istio CNI가 리디렉션 규칙 생성은 성공했으나, ztunnel 연결 또는 워크로드 등록 ACK가 준비되지 않은 경우 `pending` 상태가 발생하며, 이는 ztunnel이 해당 워크로드를 프록시하기 전까지 트래픽 처리가 불가함을 의미함.
결론적으로, Istio CNI의 준비 상태가 워크로드 Pod의 스케줄링보다 선행되어야 함을 시사함.
Untaint Controller를 통한 해결 전략
Untaint Controller는 Istio Ambient mode에서 Partially Enrolled Pod 문제를 방지하기 위한 핵심 해결책으로 제시됨.
Startup Taint 적용: 새 노드 생성 시 `cni.istio.io/not-ready` startup taint를 적용하여, Istio CNI 컴포넌트가 준비되기 전까지 일반 워크로드 Pod의 스케줄링을 차단함.
Taint 제거: Istio CNI DaemonSet Pod이 Ready 상태가 되면, Istiod 내의 Untaint Controller가 해당 taint를 제거하여 워크로드 Pod 스케줄링을 허용함.
이 방식은 스케줄링 단계에서부터 CNI 미준비 상태를 방지하며, ztunnel 미준비로 인한 경합 가능성을 크게 줄여줌. 다만, 이는 CNI 준비 상태에 초점을 맞춘 해결책이며 ztunnel readiness까지 보장하지는 않음.
Istio CNI Node Agent의 역할과 중요성
Istio CNI Node Agent는 Ambient mode에서 워크로드 Pod의 트래픽 리디렉션을 실제로 구성하는 핵심 수단임.
네트워크 네임스페이스 설정: Pod의 네트워크 네임스페이스에 직접 접근하여 트래픽 리디렉션 규칙을 설정함.
ztunnel과의 연동: 설정된 규칙과 함께 해당 Pod의 워크로드 정보 및 네트워크 네임스페이스 파일 디스크립터를 ztunnel에 전달하여, ztunnel이 Pod의 소켓을 통해 트래픽을 처리할 수 있도록 함.
이 컴포넌트가 준비되지 않으면 Pod은 Kubernetes 입장에서는 정상 상태여도 Ambient mesh에서는 완전히 참여하지 못한 상태가 되므로, 항상 Running 상태를 유지하는 것이 필수적임.
Untaint Controller 설정 및 고려사항
Untaint Controller를 활성화하기 위해서는 Istio 설정에서 두 가지 주요 구성 요소를 모두 설정해야 함.
`pilot.taint.enabled=true`: Node Patch 권한 및 CNI 네임스페이스 설정을 담당함.
`PILOT_ENABLE_NODE_UNTAINT_CONTROLLERS` 환경 변수 활성화: 실제 Controller 실행을 위한 Feature Flag 역할을 함.
이 두 설정이 함께 적용되어야 하며, 특히 문서화 부족으로 인해 혼동이 발생할 수 있는 지점이었음. 또한, Karpenter와 같은 노드 프로비저닝 도구에서는 `startupTaints` 설정을 통해 노드 초기화 시점에 임시 Taint를 적용하고, Istio의 Untaint Controller가 이를 제거하도록 연동해야 함.
