control plane과 data plane의 설치·수명주기를 분리하면 istiod 업그레이드가 data plane에 투명해진다

Sun, 07 Jun 2026 00:00:00 +0000

이 문서가 다루는 것

“Istio를 업그레이드한다"가 왜 “mesh 전체를 한 번에 흔드는 일"이 아니라 “proxy를 하나씩 새 control plane으로 옮기는 일"이 될 수 있는지를 다룬다. 결론부터: istiod(control plane)와 Envoy(data plane)는 xDS라는 느슨한 gRPC 계약으로만 묶인 별개 컴포넌트라서, 새 istiod를 옆에 나란히 띄우고(revision canary) workload를 한 namespace씩 옮길 수 있고, 그래서 control plane 교체가 data plane에 투명해진다. 설치 단위(base/istiod/gateway 3 Helm chart)·revision 메커니즘·canary 흐름을 “왜 이렇게 설계됐나"의 원리로 풀고, 운영 detail(canary 명령·합격 기준)은 운영 플레이북 §06에 위임한다.

Istio 대규모 운영 플레이북 — multi-cluster·config scope·upgrade·LLMOps (출처: ChatGPT "Istio 운영 노하우" 대화 + Istio 1.30 공식 문서)

Sun, 07 Jun 2026 00:00:00 +0000

이 문서가 다루는 것

한 그림으로: Istio 운영은 “Istio를 Envoy 설정 컴파일러(K8s 상태 + CRD → istiod → xDS → 모든 proxy)로 보고, 모든 장애를 YAML → istiod → xDS → Envoy config → response flag로 내려가며 추적하는 것"이다. 기능을 켜는 단계가 아니라 운영하는 단계에서는 성패가 config 전파량(scope)·upgrade blast radius·trust boundary·retry/timeout 정책에서 갈린다. 이 문서는 그 한 멘탈모델을 세운 뒤(§01~§02), 모든 장애를 같은 방향으로 추적하는 도구(§03)와, 규모가 커지면 그 도구만으로는 안 되는 4개 운영 주제(§04 multi-cluster·§05 scope·§06 upgrade·§07 GitOps·§08 LLMOps)를 같은 멘탈모델 위에서 펼치고, 마지막에 학습 루트(§09)로 닫는다.

Upgrade on homelab89

control plane과 data plane의 설치·수명주기를 분리하면 istiod 업그레이드가 data plane에 투명해진다

Istio 대규모 운영 플레이북 — multi-cluster·config scope·upgrade·LLMOps (출처: ChatGPT "Istio 운영 노하우" 대화 + Istio 1.30 공식 문서)