Helm으로 업그레이드하기

Helm으로 업그레이드하기 (Upgrade with Helm)

이 가이드를 따라 Helm을 사용해 앰비언트 모드 설치를 업그레이드하고 구성해 보세요. 이 가이드는 이전 버전의 Istio로 Helm을 통한 앰비언트 모드 설치를 이미 수행했다고 가정해요.

출처: Istio 문서

본문

앰비언트 모드 업그레이드 이해하기 (Understanding ambient mode upgrades)

모든 Istio 업그레이드는 컨트롤 플레인, 데이터 플레인, Istio CRD 업그레이드를 수반해요. 앰비언트 데이터 플레인은 두 컴포넌트, 즉 ztunnel과 게이트웨이(웨이포인트 포함)로 나뉘기 때문에, 업그레이드는 이 컴포넌트들에 대해 별도의 단계로 진행돼요. 컨트롤 플레인과 CRD 업그레이드는 여기서 간략히 다루지만, 기본적으로 사이드카 모드에서 이 컴포넌트들을 업그레이드하는 과정과 동일해요.

사이드카 모드와 마찬가지로 게이트웨이는 리비전 태그를 사용해 (웨이포인트를 포함한) 게이트웨이 업그레이드를 세밀하게 제어할 수 있고, 언제든 이전 버전의 Istio 컨트롤 플레인으로 롤백할 수 있는 간단한 제어를 제공해요. 다만 사이드카 모드와 달리, ztunnel은 DaemonSet(노드별 프록시)으로 실행되므로, ztunnel 업그레이드는 최소한 한 번에 전체 노드에 영향을 줘요. 이는 많은 경우 수용 가능하지만, 수명이 긴 TCP 연결이 있는 애플리케이션은 중단될 수 있어요. 이런 경우 해당 노드의 ztunnel을 업그레이드하기 전에 노드 cordoning과 draining을 권장해요. 간단함을 위해 이 문서는 ztunnel의 제자리(in-place) 업그레이드를 시연할 텐데, 이는 짧은 중단 시간을 수반할 수 있어요.

사전 요구사항 (Prerequisites)

업그레이드 준비 (Prepare for the upgrade)

Istio를 업그레이드하기 전에 새 버전의 istioctl을 다운로드하고, istioctl x precheck를 실행해 업그레이드가 환경과 호환되는지 확인하길 권장해요. 출력은 대략 다음과 같아야 해요:

$ istioctl x precheck
✔ No issues found when checking the cluster. Istio is safe to install or upgrade!
  To get started, check out <https://istio.io/latest/docs/setup/getting-started/>

이제 Helm 저장소를 업데이트하세요:

$ helm repo update istio

태그와 리비전 정리하기 (Organize your tags and revisions)

통제된 방식으로 앰비언트 모드 메시를 업그레이드하려면, 게이트웨이와 네임스페이스가 istio.io/rev 레이블을 사용해 워크로드의 트래픽을 관리할 게이트웨이 및 컨트롤 플레인 버전을 지정하는 리비전 태그를 가리키도록 권장해요. 운영 클러스터를 업그레이드를 정리하기 위해 여러 태그로 나누는 것을 권장해요. 주어진 태그의 모든 구성원은 동시에 업그레이드되므로, 가장 위험이 낮은 애플리케이션부터 업그레이드를 시작하는 것이 현명해요. 업그레이드를 위해 레이블로 리비전을 직접 참조하는 것은 권장하지 않아요. 이 과정은 많은 수의 프록시가 실수로 업그레이드되기 쉽고 세그먼트하기 어렵기 때문이에요. 클러스터에서 사용 중인 태그와 리비전을 보려면 업그레이드 태그 섹션을 참조하세요.

리비전 이름 고르기 (Choose a revision name)

리비전은 Istio 컨트롤 플레인의 고유 인스턴스를 식별하며, 단일 메시 안에서 여러 개의 서로 다른 컨트롤 플레인 버전을 동시에 실행할 수 있게 해줘요.

리비전은 불변(immutable)으로 유지하길 권장해요. 즉, 특정 리비전 이름으로 컨트롤 플레인이 설치되면 그 설치를 수정해서는 안 되고, 리비전 이름을 재사용해서도 안 돼요. 반면 태그는 리비전을 가리키는 변경 가능한 포인터예요. 이를 통해 클러스터 운영자는 워크로드 레이블을 조정할 필요 없이, 태그를 리비전에서 리비전으로 옮기기만 해도 데이터 플레인 업그레이드를 수행할 수 있어요. 모든 데이터 플레인은 istio.io/rev 레이블(리비전 또는 태그를 가리키는) 또는 istio.io/rev 레이블이 없을 때 기본 리비전이 지정하는 하나의 컨트롤 플레인에만 연결돼요. 데이터 플레인 업그레이드는 레이블 수정이나 태그 편집을 통해 그것이 가리키는 컨트롤 플레인을 바꾸는 것으로 구성돼요.

리비전은 불변으로 의도되므로, 설치하는 Istio 버전에 대응하는 리비전 이름을 선택하길 권장해요. 예: 1-22-1. 새 리비전 이름을 선택하는 것 외에도, 현재 리비전 이름을 적어두어야 해요. 이것은 다음을 실행해 찾을 수 있어요:

$ kubectl get mutatingwebhookconfigurations -l 'istio.io/rev,!istio.io/tag' -L istio\.io/rev
$ # Store your revision and new revision in variables:
$ export REVISION=istio-1-22-1
$ export OLD_REVISION=istio-1-21-2

컨트롤 플레인 업그레이드하기 (Upgrade the control plane)

Base 컴포넌트 (Base components)

클러스터 전역 CRD(Custom Resource Definitions)는 새 버전의 컨트롤 플레인 배포 전에 업그레이드되어야 해요:

$ helm upgrade istio-base istio/base -n istio-system

istiod 컨트롤 플레인 (istiod control plane)

Istiod 컨트롤 플레인은 메시 안에서 트래픽을 라우팅하는 프록시를 관리하고 구성해요. 다음 명령은 현재 컨트롤 플레인과 나란히 새 인스턴스를 설치하지만, 새 게이트웨이 프록시나 웨이포인트를 도입하지도, 기존 것들의 제어를 인수하지도 않아요.

istiod 설치를 커스터마이즈했다면, 이전 업그레이드나 설치의 values.yaml 파일을 재사용해 컨트롤 플레인을 일관되게 유지할 수 있어요.

$ helm upgrade istiod istio/istiod -n istio-system --wait
$ helm install istiod-"$REVISION" istio/istiod -n istio-system --set revision="$REVISION" --set profile=ambient --wait

CNI 노드 에이전트 (CNI node agent)

Istio CNI 노드 에이전트는 앰비언트 메시에 추가된 파드를 감지하고, 추가된 파드 내에 프록시 포트가 설정되어야 한다고 ztunnel에 알리며, 파드 네트워크 네임스페이스 안의 트래픽 리디렉션을 구성하는 역할을 해요. 데이터 플레인이나 컨트롤 플레인의 일부가 아니에요.

버전 1.x의 CNI는 버전 1.x+1 및 1.x의 컨트롤 플레인과 호환돼요. 즉, 버전 차이가 마이너 버전 하나 이내인 한, 컨트롤 플레인을 Istio CNI보다 먼저 업그레이드해야 해요.

$ helm upgrade istio-cni istio/cni -n istio-system --set profile=ambient --wait

데이터 플레인 업그레이드하기 (Upgrade the data plane)

ztunnel DaemonSet

ztunnel DaemonSet은 노드 프록시 컴포넌트예요. 버전 1.x의 ztunnel은 버전 1.x+1 및 1.x의 컨트롤 플레인과 호환돼요. 즉, 버전 차이가 마이너 버전 하나 이내인 한, 컨트롤 플레인을 ztunnel보다 먼저 업그레이드해야 해요. ztunnel 설치를 커스터마이즈했다면, 이전 업그레이드나 설치의 values.yaml 파일을 재사용해 데이터 플레인을 일관되게 유지할 수 있어요.

$ helm upgrade ztunnel istio/ztunnel -n istio-system --wait
$ helm upgrade ztunnel istio/ztunnel -n istio-system --set revision="$REVISION" --wait

수동으로 배포된 게이트웨이 차트 업그레이드 (선택사항)

수동으로 배포된 Gateway는 Helm으로 개별 업그레이드해야 해요:

$ helm upgrade istio-ingress istio/gateway -n istio-ingress

태그를 사용해 웨이포인트와 게이트웨이 업그레이드 (Upgrade waypoints and gateways using tags)

모범 사례를 따랐다면 모든 게이트웨이, 워크로드, 네임스페이스는 기본 리비전(사실상 default라는 태그)이나 값이 태그 이름인 istio.io/rev 레이블을 사용해요. 이제 태그를 하나씩 새 버전을 가리키도록 옮겨서 이 모두를 새 버전의 Istio 데이터 플레인으로 업그레이드할 수 있어요. 클러스터의 모든 태그를 나열하려면 다음을 실행하세요:

$ kubectl get mutatingwebhookconfigurations -l 'istio.io/tag' -L istio\.io/tag,istio\.io/rev

각 태그에 대해, $MYTAG를 태그 이름으로, $REVISION을 리비전 이름으로 교체해 다음 명령을 실행해 태그를 업그레이드할 수 있어요:

$ helm template istiod istio/istiod -s templates/revision-tags-mwc.yaml --set revisionTags="{$MYTAG}" --set revision="$REVISION" -n istio-system | kubectl apply -f -

이것은 그 태그를 참조하는 모든 오브젝트를 업그레이드해요. 다만 수동 게이트웨이 배포 모드를 사용하는 것(아래에서 다룸)과, 앰비언트 모드에서 사용되지 않는 사이드카는 제외돼요.

업그레이드된 데이터 플레인을 사용하는 애플리케이션의 상태를 다음 태그를 업그레이드하기 전에 면밀히 모니터링하길 권장해요. 문제를 감지하면 태그를 롤백해서 이전 리비전 이름을 가리키도록 재설정할 수 있어요:

$ helm template istiod istio/istiod -s templates/revision-tags-mwc.yaml --set revisionTags="{$MYTAG}" --set revision="$OLD_REVISION" -n istio-system | kubectl apply -f -

태그를 옮기면 그것을 참조하는 모든 웨이포인트가 한 번에 업그레이드돼요. 서비스의 실제 트래픽의 일부에서 새 웨이포인트 리비전을 먼저 검증하고 싶다면, 새 웨이포인트를 별도로 배포해서 트래픽을 점진적으로 이동시킨 후 승격할 수 있어요.

수동으로 배포된 게이트웨이 업그레이드 (선택사항)

수동으로 배포된 Gateway는 Helm으로 개별 업그레이드해야 해요:

$ helm upgrade istio-ingress istio/gateway -n istio-ingress

이전 컨트롤 플레인 제거하기 (Uninstall the previous control plane)

모든 데이터 플레인 컴포넌트가 새 리비전의 Istio 컨트롤 플레인을 사용하도록 업그레이드했고, 롤백할 필요가 없다고 확신한다면, 다음을 실행해 이전 리비전의 컨트롤 플레인을 제거할 수 있어요:

$ helm delete istiod-"$OLD_REVISION" -n istio-system

더 알아보기 (Learn more)