Istio 3-3편: Ambient mode 안전하게 업그레이드하기

채널코퍼레이션 DevOps팀이 Istio Ambient mode의 버전 업그레이드 런북을 정리한 3-3편이다. Ambient mode는 sidecar가 없어 애플리케이션 Pod을 직접 재시작하지 않아도 되지만, 대신 node-local 컴포넌트인 istio-cni와 ztunnel을 더 신중하게 봐야 한다. istiod와 istio-cni는 in-place로, ztunnel은 node pool 단위 blue-green으로 옮기는 순서를 택했다.

핵심 포인트

ztunnel은 노드마다 하나씩 떠 그 노드의 Ambient workload 트래픽을 직접 처리하므로 교체 시 해당 노드의 long-lived connection이 reset될 수 있다.
ztunnel의 graceful shutdown 기본값은 30초 수준이고 그 안에 끝나지 않은 connection은 종료 순간 끊긴다. 클라이언트에 retry가 없으면 요청 실패로 이어진다.
Istio 커뮤니티도 in-place hitless upgrade나 한 노드에서 여러 ztunnel revision을 활성화하는 것은 범위 밖으로 두고 node drain 기반 절차를 문서화하는 방향으로 논의 중이다.
istiod 업그레이드는 control plane만 바꾸는 작업이 아니다. Gateway controller가 관리하는 Envoy 워크로드가 istiod revision과 맞물려 있어 gateway도 함께 rollout된다.
green ztunnel을 띄울 때는 DaemonSet만 추가하는 것이 아니라 istiod가 신뢰할 ztunnel service account 목록에 새 이름까지 넣어야 한다.

상세 정리

대상 컴포넌트 셋: istiod는 config 전파와 Gateway controller 역할, istio-cni는 Pod 감지와 iptables 설정 및 ztunnel proxy port 구성, ztunnel은 노드 단위 data plane이다.
Step 1 istiod: graceful shutdown이 있어 rollout이 곧바로 서비스 중단으로 이어지지는 않아야 하지만, gateway와 waypoint가 의도한 revision을 보고 있는지와 control plane 에러 로그가 늘지 않는지를 업그레이드 중에 확인한다.
istio-cni의 역할: 노드 안의 Pod를 감지하고 Pod network namespace 안에 redirection rule을 설정해 트래픽이 ztunnel을 거치게 만든다.
Step 2가 in-place로 가능한 이유: 이미 실행 중인 Pod은 network namespace가 생성될 때 redirection rule과 ztunnel 경로가 준비돼 있고, istio-cni Pod이 재시작돼도 기존 Pod의 namespace가 다시 만들어지지는 않으므로 data plane 교체가 아니다.
주의할 타이밍: istio-cni가 완전히 준비되지 않은 아주 짧은 순간에 새 Pod이 생성되면 sandbox 생성 단계에서 CNI 설정을 완료하지 못할 수 있다. 다만 Pod이 잘못된 네트워크 상태로 Running 되는 것이 아니라 sandbox 생성 자체가 실패하고 Kubernetes가 재시도한다.
그래서 istio-cni rollout 중에는 이미 running인 Pod과 새로 생성되는 Pod을 나눠 봐야 한다. 확인 대상은 DaemonSet rollout이 정상 완료되는지, 새로 생성된 Pod 중 redirection이 누락되거나 pending으로 남는 것이 없는지다.
호환성 규칙: v1.x istio-cni는 v1.x 및 v1.x+1 control plane과 호환되며 ztunnel도 마찬가지라, 일반적인 순서는 control plane을 먼저 올리고 그다음 CNI를 올리는 것이다.
3-2편에서 다룬 race condition은 여전히 관측될 수 있는데, 이때의 에러는 영구 장애라기보다 istio-cni가 준비될 때까지 Pod 생성이 재시도되는 현상으로 봤다.
Step 3의 문제 인식: ztunnel을 일반 DaemonSet처럼 rolling update하면 같은 노드에서 old와 new가 교체되는 순간이 생기고, graceful shutdown 시간을 길게 잡는 것도 권장되지 않는다. 그래서 ztunnel upgrade는 무조건 무중단이라고 보기 어렵다.
커뮤니티 논의 배경: 여러 release를 동시에 설치하기 어렵고 여러 DaemonSet을 만들 수 있어 보여도 istiod 설정값과 연결돼 있어 istiod의 revision canary처럼 다루기 어렵다는 문제가 공유돼 왔다.
blue-green 구성: 기존 ztunnel과 새 ztunnel을 서로 다른 node label에 매핑하고 버전별로 nodeSelector를 다르게 준다. 그러면 기존 노드에서는 기존 ztunnel이 계속 돌고 새 노드에서는 새 ztunnel만 뜬다.
신뢰 관계 설정: istiod Helm chart는 기본적으로 하나의 ztunnel 이름을 전제하므로, 두 개를 동시에 운영하려면 istiod가 신뢰할 ztunnel service account 목록에 두 이름을 모두 추가해야 한다. 빠지면 새 이름으로 뜬 ztunnel이 istiod와 신뢰 관계를 맺지 못할 수 있다.
node pool 준비: Karpenter를 쓴다면 NodePool template에 새 istio version label을 붙여, 기존 노드는 blue ztunnel을 신규 노드는 green ztunnel을 쓰게 만든다.
이전 순서: green이 준비되면 기존 blue node를 점진적으로 비우되 stateless workload부터 옮기는 것이 안전하다. Stateful workload나 long-running job은 PDB, local storage, connection 특성 때문에 오래 남아 blue ztunnel 제거 시점이 생각보다 늦어질 수 있다.
마무리 조건: blue ztunnel이 올라간 노드가 더 이상 없으면 그 DaemonSet을 제거하고, 모든 workload가 green node pool로 이동했으면 기존 NodeGroup을 정리한다.
결론: ztunnel이 노드 단위 data plane이므로 업그레이드의 안전한 단위도 결국 node이며, 기존 노드에 old를 유지하고 신규 노드에 new를 띄운 뒤 workload를 천천히 옮기는 방식이 가장 직관적이고 안전했다고 정리한다.