ICA — 이스티오 인증 어소시에이트 · 설치 맞춤과 업그레이드 두 방식 · 이론
IstioOperator 로 설치를 맞추고 revision 으로 업그레이드한다
한 줄 요약
Istio 설치는 IstioOperator 라는 하나의 문서로 표현되고, profile 은 그 문서의 기본값 묶음이며, MeshConfig 는 메시 전체에 적용되는 설정입니다. 업그레이드는 revision 을 나란히 세우는 canary 방식이 기본이고, in-place 는 더 위험해서 조건이 붙습니다.
왜 이게 필요했나
istioctl install 한 줄로 Istio 가 올라오면 다 된 것처럼 보입니다. 그런데 운영에서는 곧 "접근 로그를 켜야 한다", "이그레스 게이트웨이를 추가해야 한다", "외부 목적지를 기본 차단으로 바꿔야 한다" 는 요구가 옵니다. 이때 --set 플래그를 하나씩 붙이면 무엇을 바꿨는지 아무도 기억하지 못하게 됩니다. Istio 문서는 --set 과 -f 가 같은 일을 하지만 운영에서는 -f 로 파일을 넘기는 방식을 강하게 권한다고 적습니다. 설치 상태가 파일 하나에 남아야 업그레이드 때 같은 파일을 다시 쓸 수 있기 때문입니다.
업그레이드도 마찬가지입니다. 컨트롤 플레인을 그 자리에서 바꾸는 in-place 방식은 모든 사이드카가 한 번에 새 istiod 를 바라보게 되므로 문제가 생기면 메시 전체가 영향을 받습니다. 그래서 Istio 는 새 컨트롤 플레인을 옆에 하나 더 세우고 네임스페이스 단위로 옮겨 가는 canary 방식을 권장합니다. ICA 시험의 Install/Upgrade/Config 도메인(20%)은 바로 이 두 가지, 즉 무엇으로 설치를 맞추는가와 두 업그레이드 방식을 언제 고르는가를 묻습니다.
어떻게 동작하나
IstioOperator — 클러스터에 적용되지 않는 설정 문서
istioctl install -f 에 넘기는 파일은 install.istio.io/v1alpha1 의 IstioOperator 리소스입니다. 공식 참조 문서는 이 리소스가 "Kubernetes 오브젝트와 비슷한 형식이지만 클러스터에 적용되는 것이 아니라 istioctl 의 파일 입력" 이라고 설명합니다. 즉 kubectl apply 로 넣는 것이 아니라 istioctl 이 읽어 매니페스트를 만드는 재료입니다.
apiVersion: install.istio.io/v1alpha1kind: IstioOperatorspec: profile: default # 기본값 묶음. 비우면 default revision: 1-31-0 # canary 업그레이드용 식별자. '.' 은 쓸 수 없다 meshConfig: # 메시 전체 설정 accessLogFile: /dev/stdout outboundTrafficPolicy: mode: REGISTRY_ONLY components: # 어떤 구성요소를 켜고 끌지, k8s 리소스 설정 egressGateways: - name: istio-egressgateway enabled: true values: {} # Helm values 로 바로 넘기는 통로(검증됨)spec 의 주요 필드는 profile, hub/tag(이미지 위치), revision, meshConfig, components(base, pilot, cni, ztunnel, istiodRemote, ingressGateways, egressGateways), values 입니다. 문서는 values 가 Helm 템플릿으로 넘어가는 검증된 통로이며, IstioOperatorSpec 에 있는 항목은 values 대신 위쪽 필드로 적으라고 안내합니다. 옛 Helm values 경로를 --set 으로 쓰려면 values. 접두어를 붙입니다.
profile — 이름 붙은 Helm values 묶음
profile 은 Helm 차트에 내장된 이름 붙은 values 오버라이드 묶음입니다. 그래서 helm 과 istioctl 양쪽에서 같은 이름으로 씁니다. 배포 profile 은 다음과 같습니다.
| profile | 용도 | istioctl 이 함께 설치하는 구성요소 |
| --- | --- | --- |
| default | 운영과 멀티클러스터 primary 권장 | istiod, istio-ingressgateway |
| demo | 기능 시연용. 트레이싱·접근 로그를 높게 켜서 성능 시험에는 부적합 | istiod, ingress, egress 게이트웨이 |
| minimal | default 와 같되 컨트롤 플레인만 | istiod |
| ambient | ambient 모드 시작용 | istiod, CNI, ztunnel |
| remote / empty / preview | 외부 컨트롤 플레인용 / 아무것도 설치하지 않는 바탕 / 실험 기능 | — |
여기서 시험이 좋아하는 차이가 하나 있습니다. istioctl 의 profile 은 어떤 구성요소를 설치할지 목록까지 포함하지만, Helm 의 profile 은 값 묶음일 뿐이라 각 구성요소를 helm install 로 하나씩 올려야 합니다. 그리고 --set profile=default --set values.global.platform=gke 처럼 플랫폼 profile(gke, eks, openshift, k3s 등)을 배포 profile 과 함께 주는 것이 권장됩니다.
MeshConfig — 메시 전체에 적용되는 값
meshConfig 는 "메시 전체 설정" 입니다. accessLogFile 은 비어 있으면 접근 로그를 끄고 /dev/stdout 을 주면 켭니다. accessLogEncoding 은 TEXT 가 기본이고 JSON 으로 바꿀 수 있습니다. outboundTrafficPolicy 의 기본은 ALLOW_ANY 라 등록되지 않은 외부 목적지로도 나갑니다. enableTracing 은 스팬 생성을 켜되 프록시 설정에 수집기가 있어야 합니다. 한 가지 예외가 defaultConfig(ProxyConfig)입니다. 문서는 이 값이 사이드카 주입 시점에 한 번 적용되어 파드가 사는 동안 바뀌지 않으며, 나머지 MeshConfig 는 실행 중에도 동적으로 배포된다고 적습니다. 그래서 프록시 설정을 바꿨는데 반영이 안 되면 파드를 재시작해야 합니다.
istioctl 과 Helm 설치 경로의 차이
Helm 설치는 차트 세 개를 순서대로 올립니다. 클러스터 범위 CRD 를 담은 base, istiod 를 배포하는 istiod, 그리고 선택인 gateway 입니다. revision 설치를 할 때는 base 차트에 --set defaultRevision=<revision> 을 줘야 리소스 검증 웹훅이 동작합니다. Helm 으로 삭제해도 CRD 는 남는데, 이것은 의도된 설계입니다. CRD 를 지우면 VirtualService·DestinationRule 같은 사용자 리소스가 연쇄 삭제되기 때문입니다. istioctl 로 설치한 것을 Helm 으로 넘길 때는 --take-ownership 으로 기존 리소스를 인수할 수 있습니다. 문서는 Helm 가이드의 차트가 istioctl 이 쓰는 차트와 같되 gateway 차트만 다르다고 명시합니다.
canary 업그레이드 — revision 을 나란히 세운다
istioctl install --set revision=1-31-0 처럼 revision 을 주면 istiod Deployment·Service 와 사이드카 주입 웹훅이 revision 이름을 달고 하나 더 생깁니다. 기존 사이드카는 아무 영향을 받지 않습니다. 워크로드를 옮기려면 네임스페이스의 istio-injection=enabled 라벨을 지우고 istio.io/rev=<revision> 을 붙인 뒤 파드를 재시작합니다. istio-injection 라벨은 하위 호환을 위해 istio.io/rev 보다 우선하므로 반드시 지워야 합니다.
네임스페이스마다 라벨을 고쳐 다니는 대신 revision tag 를 씁니다. istioctl tag set prod-stable --revision 1-30-1 로 태그를 만들고 네임스페이스에는 istio.io/rev=prod-stable 을 붙여 두면, 나중에 istioctl tag set prod-stable --revision 1-31-0 --overwrite 한 번으로 그 태그를 쓰는 모든 네임스페이스가 새 revision 으로 옮겨집니다. default 태그는 특별해서 istio-injection=enabled 주입, 리소스 검증, 리더 락을 맡습니다. 검증이 끝나면 istioctl uninstall --revision 1-30-1 로 옛 컨트롤 플레인을 지웁니다. revision 방식은 마이너 두 단계 건너뛰기(1.15 → 1.17)를 지원합니다.
in-place 업그레이드 — 조건이 많다
istioctl upgrade 는 그 자리에서 컨트롤 플레인과 게이트웨이를 바꿉니다. 문서가 적은 조건은 이렇습니다. 설치된 버전이 새 버전보다 마이너 한 단계 이하로만 낮아야 하고, --revision 으로 설치한 것에는 쓸 수 없으며, 설치 때 쓴 -f 파일이나 --set 값을 그대로 넘기지 않으면 맞춤 설정이 기본값으로 되돌아갑니다. 끝난 뒤에는 kubectl rollout restart deployment 로 데이터 플레인을 직접 재시작해야 합니다. 중단을 줄이려면 istiod 를 두 개 이상 두고 PodDisruptionBudget 을 최소 가용 1 로 잡으라고 권합니다.
현장에서 만나는 모습
한 팀이 --set 다섯 개로 설치한 메시를 istioctl upgrade 로 올렸더니 접근 로그가 사라지고 outboundTrafficPolicy 가 ALLOW_ANY 로 돌아온 일이 있습니다. 업그레이드 명령에 같은 --set 을 넘기지 않아서였고, 원인을 찾는 데 하루가 걸렸습니다. IstioOperator 파일을 저장소에 두고 설치와 업그레이드 모두 -f 로 같은 파일을 넘겼다면 생기지 않았을 일입니다.
또 하나는 canary 를 되돌릴 때입니다. default profile 에서는 게이트웨이가 revision 별로 따로 뜨지 않고 새 revision 으로 in-place 업그레이드됩니다. 그래서 canary revision 을 지우면 게이트웨이가 옛 컨트롤 플레인을 가리키지 않습니다. 문서는 canary 를 지우기 전에 옛 istioctl 로 게이트웨이를 먼저 다시 설치하고 정상 동작을 확인하라고 적습니다. 순서를 바꾸면 인그레스가 끊깁니다.
다음 퀴즈에서 확인할 것
profile 별로 istioctl 이 설치하는 구성요소, defaultConfig 만 재시작이 필요한 이유, istio-injection 과 istio.io/rev 의 우선순위, revision tag 를 옮기는 명령, 그리고 in-place 업그레이드가 실패하거나 설정을 잃는 조건을 묻습니다. 참고: [Install with Istioctl](https://istio.io/latest/docs/setup/install/istioctl/), [Installation Configuration Profiles](https://istio.io/latest/docs/setup/additional-setup/config-profiles/), [Canary Upgrades](https://istio.io/latest/docs/setup/upgrade/canary/), [In-place Upgrades](https://istio.io/latest/docs/setup/upgrade/in-place/), [Install with Helm](https://istio.io/latest/docs/setup/install/helm/).