Helm on homelab89

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 1.30.0 — 기존 설치 teardown + Helm 클린 재설치

Mon, 01 Jun 2026 00:00:00 +0000

ABSTRACT

홈랩 클러스터의 깨진 Istio 1.30.0 설치를 전부 제거하고 순수 Helm chart(base → istiod → ingress/egress)로 클린 재설치한 런북. 흐름 0단계(설치·구조)의 실제 실행 기록 — 본 아카이브 전체가 이 설치 위에서 동작한다. 하나의 그림: Istio Helm 설치는 의존 스택이다 — base(CRD) → istiod(control plane) → gateways(data plane), 각 release가 앞 layer를 전제로 한다. 그리고 Helm은 자기가 만든 선언적 리소스만 소유하고, istiod가 런타임에 동적으로 만드는 리소스(CA cert, leader-election cm)는 소유 밖이다. 이 의존 방향 + ownership 경계 두 축이 install 순서·teardown 역순·CRD 잔여물·configmap 수동삭제를 전부 설명한다.