Istio 3-2편: Partially Enrolled Pod와 Untaint Controller

Istio Ambient mode 도입기 3-2편으로, Kubernetes는 Pod이 준비됐다고 보지만 Ambient mesh는 아직 그 Pod을 처리할 준비가 되지 않은 상태를 다룬다. Pod은 Running이고 readiness probe도 통과해 Service endpoint에 포함됐는데 mesh workload나 waypoint에서 보내는 요청만 실패했다. 원인은 새 노드에서 istio-cni DaemonSet과 일반 workload Pod의 스케줄링이 거의 동시에 진행되는 race이고, 해법은 untaint-controller로 CNI 준비 전에는 workload가 뜨지 못하게 막는 것이다.

핵심 포인트

namespace에 ambient label이 붙었다는 것은 "이 Pod은 mesh 대상이어야 한다"는 의도 표시일 뿐, 실제 트래픽이 ztunnel을 통과하려면 node-local 컴포넌트가 Pod 네트워크를 준비해야 한다.
완전한 참여에는 두 가지가 필요하다. Pod network namespace 안의 traffic redirection rule 설정, 그리고 ztunnel이 그 Pod을 workload로 인지하고 proxy할 준비.
3-1편의 stale connection 이슈와는 다른 문제다. 에러 메시지에 붙는 reset reason이 달라 별개 원인으로 판단했다.
redirection이 빠진 Pod은 ztunnel을 우회할 수 있고, 그러면 mTLS·AuthorizationPolicy·telemetry가 적용되지 않을 수 있다.
untaint-controller는 taint를 추가하지 않는다. taint는 Karpenter NodePool 같은 인프라 레벨에서 노드 생성 시 붙여야 하고, controller는 istio-cni가 준비된 뒤 그것을 제거하는 역할만 한다.

상세 정리

istio-cni node agent의 역할: 단순히 iptables rule만 주입하는 게 아니라 Pod network namespace에 redirection rule을 설정하고 ztunnel에게 workload 정보와 network namespace 파일 디스크립터를 전달한다. 그래야 ztunnel이 그 Pod의 socket으로 inbound/outbound를 처리할 수 있다.
증상: 애플리케이션 로그에는 특별한 에러가 없고 readiness도 정상이라 Kubernetes 입장에서는 문제가 없어 보이는데, client 쪽에서는 upstream connect error or disconnect/reset before headers 계열 에러가 관찰됐다.
소스코드 확인: Ambient redirection 상태가 Pod annotation으로 관리된다. 값이 하나면 redirection 구성이 완료된 captured 상태이고, 다른 하나면 일부 단계는 끝났지만 아직 ztunnel이 그 workload를 proxy하지 못하는 상태다.
후자는 단순히 조금 늦게 반영되는 중이라는 뜻이 아니라, active ztunnel이 해당 Pod을 proxy하기 전까지는 ingress/egress traffic이 동작하지 않을 수 있는 상태라고 주석에 적혀 있다.
생성 흐름: Pod UID를 snapshot에 등록하고 network namespace를 열거나 찾은 뒤 netns 안에 redirection rule을 만들고, 마지막으로 ztunnel에 workload 정보를 전달한다. 이 중 redirection은 성공했지만 ztunnel 등록이 실패하면 partial 상태로 표시된다.
다만 모든 실패가 이 annotation으로 남지는 않는다. CNI plugin이 아예 호출되지 않았거나 ambient 대상 판정이 실패해 CNI event가 node agent까지 전달되지 않으면 redirection rule 자체가 빠질 수 있다.
Istio는 partial 상태 Pod을 방치하지 않고 Pod update event 처리 시 별도로 확인해 retry 대상으로 본다. ztunnel이 뒤늦게 연결되면 최종적으로 정상 상태가 된다.
운영에서 retry에 의존하기 어려웠던 이유: retry가 성공하기 전까지 트래픽 유실이 발생하고, readiness probe가 애플리케이션 관점에서만 통과하면 Service endpoint에는 포함되면서 mesh traffic만 실패하는 상태가 된다.
근본 원인: Kubernetes scheduler가 DaemonSet의 준비 완료를 일반 workload 스케줄링의 선행 조건으로 보장하지 않는다. 새 노드가 추가되면 istio-cni DaemonSet Pod, ztunnel DaemonSet Pod, 일반 workload Pod의 스케줄링이 거의 동시에 진행될 수 있다.
실패 시나리오 1: istio-cni가 Pod 생성 시점에 호출되지 않았거나 ambient 대상 판정이 실패한 경우다. redirection rule이 안 들어가고 annotation도 안 붙어, 트래픽이 ztunnel을 우회해 app port로 직접 도달하거나 정책 적용을 우회할 수 있다.
실패 시나리오 2: redirection rule 생성까지는 성공했지만 ztunnel 연결이나 ACK가 준비되지 않은 경우로, partial 상태가 된다.
해법 조사 과정: 당시 Istio 공식 문서에 정리돼 있지 않았다. 1.22 release note에 node taint controller가 추가됐다는 짧은 언급과 Helm values 설정만 있었고, 어떤 taint를 누가 붙이는지, 어떤 값을 함께 켜야 하는지, Karpenter와 어떻게 조합하는지를 한 번에 확인하기 어려웠다.
결국 참고할 수 있었던 가장 명확한 문서는 별도 문서였고, startup taint를 걸고 istio-cni가 Ready가 되면 untaint-controller가 제거한다는 흐름이 비교적 명확히 설명돼 있었다.
동작 방식: 새 노드 생성 시 startup taint를 걸어두면 그동안 일반 workload Pod이 그 노드에 스케줄되지 않고, toleration을 가진 istio-cni DaemonSet Pod만 먼저 올라온다. istio-cni가 Ready가 되면 istiod 안의 untaint-controller가 taint를 제거한다.
즉 Pod이 먼저 뜬 뒤 고치는 방식이 아니라 아예 준비 전에는 뜨지 못하게 하는 접근이다. 다만 여기서 준비는 istio-cni 준비를 뜻하고 ztunnel readiness까지 보장하지는 않는다.
이 구조는 CNI 미준비를 스케줄링 단계에서 줄이고 ztunnel 미준비 race는 CNI ADD의 동기 ACK 경로가 상당 부분 막아 준다. 다만 기존 Pod을 나중에 다시 enroll하는 경로, redirection 적용 이후 ztunnel disconnect, partial 상태의 짧은 window까지 완전히 없애지는 않는다고 명시한다.
설정 함정: Helm values의 옵션 하나만으로는 controller가 동작하지 않을 수 있다. 그 값은 node patch 권한과 CNI namespace 설정에 가깝게 동작하고 실제 controller 실행은 별도 feature flag가 켜져야 해서, 문서 부재와 맞물려 헷갈렸다. 현재 최신 버전에서는 패치된 것으로 보인다고 덧붙인다.
Karpenter 조합: NodePool 쪽에서 새 노드에 startup taint를 붙이면 노드 초기화 중 임시로 존재하는 taint로 취급돼 외부 controller가 제거할 수 있고, 그 외부 controller가 istiod의 untaint-controller가 된다.