Istio Ambient mode 안전 업그레이드 런북 공개

Istio Ambient mode의 버전 업그레이드는 Control Plane(istiod), CNI Node Agent(istio-cni), Data Plane(ztunnel) 세 가지 컴포넌트를 대상으로 진행됩니다. istiod는 in-place 업그레이드를 통해 설정 전파 및 Gateway controller 역할을 수행하며, istio-cni 역시 DaemonSet rollout을 통한 in-place 방식으로 업그레이드됩니다. 기존 Pod의 네트워크 네임스페이스는 유지되므로 트래픽 중단 위험이 적습니다. 하지만 ztunnel은 노드 단위 L4 데이터 플레인으로, 교체 시 long-lived connection이 리셋될 수 있어 가장 신중한 접근이 필요합니다.

ztunnel 업그레이드는 node pool 단위의 Blue-Green 배포 방식을 통해 안전성을 확보합니다. 먼저, 기존 ztunnel(Blue)과 신규 ztunnel(Green)을 서로 다른 노드 레이블에 매핑하고, istiod의 trustedZtunnelName 설정을 업데이트하여 신규 ztunnel과의 신뢰 관계를 구축합니다. 이후 Karpenter 등을 활용해 신규 노드 풀(Green Node Pool)을 구성하고, 기존 노드(Blue Node Pool)를 점진적으로 drain하여 워크로드를 신규 노드로 이전시킵니다. 이 과정에서 stateless 워크로드부터 이전하고, 5xx 에러, TCP reset, 지연 시간(Latency) 지표를 면밀히 모니터링하여 안정성을 검증합니다.

istio-cni는 Pod의 네트워크 네임스페이스에 iptables 규칙을 설정하여 트래픽을 ztunnel로 리디렉션하는 역할을 담당합니다. Ambient mode에서 istio-cni의 in-place 업그레이드는 기존 실행 중인 Pod의 네트워크 네임스페이스에 영향을 주지 않기 때문에 비교적 안전합니다. 새 Pod 생성 시 istio-cni가 준비되지 않은 짧은 타이밍에 발생할 수 있는 `FailedCreatePodSandBox` 오류는 일시적인 현상으로, Kubernetes 재시도 메커니즘을 통해 정상적으로 Pod이 생성됩니다. 따라서 DaemonSet rollout 완료 여부와 redirection 누락 여부를 확인하며 업그레이드를 진행할 수 있습니다.

Istio는 공식적으로 CNI 및 ztunnel 컴포넌트의 버전 호환성을 제공합니다. 일반적으로 v1.x istio-cni 및 ztunnel은 v1.x 및 v1.x+1 버전의 control plane과 호환됩니다. 이는 Control Plane을 먼저 업그레이드한 후 CNI 및 ztunnel을 순차적으로 업그레이드하는 일반적인 절차를 뒷받침합니다. 다만, 3-2편에서 언급된 것처럼 istio-cni나 ztunnel이 준비되기 전에 워크로드 Pod이 먼저 스케줄되는 Race Condition은 여전히 발생할 수 있으며, 이 경우 Pod 생성 재시도가 필요합니다.

ztunnel은 노드 단위 L4 데이터 플레인으로서, 업그레이드 시 기존 노드의 long-lived connection이 리셋될 가능성이 존재합니다. ztunnel은 graceful shutdown을 지원하지만, 기본값인 30초 내에 종료되지 않는 연결은 끊길 수 있습니다. 따라서 애플리케이션이나 클라이언트 측의 별도 재시도 로직 부재 시 요청 실패로 이어질 수 있습니다. 이러한 위험 때문에 in-place rolling update보다는 node drain 기반의 blue-green 배포가 더 안전한 대안으로 제시됩니다.