업그레이드 준비
이전 설치를 맞춤설정한 경우 새 Anthos Service Mesh 버전으로 업그레이드하거나 Istio에서 마이그레이션할 때 동일한 맞춤설정이 필요합니다. --set values
플래그를 istioctl install
에 추가하여 설치를 맞춤설정한 경우 오버레이 파일이라고 부르는 IstioOperator
YAML 파일에 이러한 설정을 추가해야 합니다. 스크립트를 실행할 때 해당 파일 이름으로 --custom_overlay
옵션을 사용해서 오버레이 파일을 지정합니다. 스크립트가 오버레이 파일을 istioctl install
로 전달합니다.
스크립트는 버전 업그레이드 프로세스(Istio 문서에서 '카나리아' 업그레이드라고 부름)를 따릅니다. 버전 기반 업그레이드에서는 스크립트가 기존 제어 영역과 함께 제어 영역의 새 버전을 설치합니다. 새 버전을 설치할 때 스크립트에는 새 제어 영역을 식별하는 revision
라벨이 포함됩니다.
그런 후 새 Anthos Service Mesh 버전 및 구성이 사용되도록 워크로드에 동일한 revision
라벨을 설정하고 프록시를 다시 삽입하도록 연속 재시작을 수행하여 새 버전으로 마이그레이션합니다. 이 방식을 사용하면 일부 워크로드에서 업그레이드의 효과를 모니터링할 수 있습니다. 애플리케이션을 테스트한 후 모든 트래픽을 새 버전으로 마이그레이션할 수 있습니다. 이 방식은 새 제어 영역 구성요소가 이전 버전을 대체하는 인플레이스(In-Place) 업그레이드를 수행하는 것보다 훨씬 안전합니다.
환경 설정
Anthos Service Mesh를 설치할 머신에 다음 도구가 필요합니다. Anthos Service Mesh는 관리자 클러스터가 아닌 사용자 클러스터에만 설치할 수 있습니다.
curl
명령줄 도구- Google Cloud CLI
Google Cloud CLI를 설치한 후 다음을 수행합니다.
Google Cloud CLI로 인증합니다.
gcloud auth login
구성요소를 업데이트합니다.
gcloud components update
kubectl
을 설치합니다.gcloud components install kubectl
필요한
kpt
버전을 설치합니다.curl -L https://github.com/GoogleContainerTools/kpt/releases/download/v0.39.2/kpt_linux_amd64 > kpt_0_39_2 chmod +x kpt_0_39_2 alias kpt="$(readlink -f kpt_0_39_2)"
컨텍스트를 사용자 클러스터로 전환합니다.
kubectl config use-context CLUSTER_NAME
클러스터 관리자 권한을 사용자 계정(Google Cloud 로그인 이메일 주소)에 부여합니다. Anthos Service Mesh에 필요한 역할 기반 액세스 제어(RBAC) 규칙을 만들려면 이러한 권한이 필요합니다.
kubectl create clusterrolebinding cluster-admin-binding \ --clusterrole=cluster-admin \ --user=USER_ACCOUNT
설치 파일 다운로드
Linux
Anthos Service Mesh 설치 파일을 현재 작업 디렉터리에 다운로드합니다.
curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.9.8-asm.6-linux-amd64.tar.gz
서명 파일을 다운로드하고
openssl
을 사용하여 서명을 확인합니다.curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.9.8-asm.6-linux-amd64.tar.gz.1.sig openssl dgst -verify /dev/stdin -signature istio-1.9.8-asm.6-linux-amd64.tar.gz.1.sig istio-1.9.8-asm.6-linux-amd64.tar.gz <<'EOF' -----BEGIN PUBLIC KEY----- MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw== -----END PUBLIC KEY----- EOF
예상되는 출력은
Verified OK
입니다.원하는 파일 시스템 위치에 파일 콘텐츠 압축을 풉니다. 예를 들어 콘텐츠를 현재 작업 디렉터리에 추출하려면 다음을 사용하세요.
tar xzf istio-1.9.8-asm.6-linux-amd64.tar.gz
이 명령어는 다음을 포함하는 현재 작업 디렉터리에
istio-1.9.8-asm.6
이라는 설치 디렉터리를 만듭니다.- 샘플 애플리케이션은
samples
디렉터리에 있습니다. - Anthos Service Mesh를 설치하는 데 사용하는
istioctl
명령줄 도구는bin
디렉터리에 있습니다. - Anthos Service Mesh 구성 프로필은
manifests/profiles
디렉터리에 있습니다.
- 샘플 애플리케이션은
Anthos Service Mesh 설치 루트 디렉터리에 있는지 확인합니다.
cd istio-1.9.8-asm.6
MacOS
Anthos Service Mesh 설치 파일을 현재 작업 디렉터리에 다운로드합니다.
curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.9.8-asm.6-osx.tar.gz
서명 파일을 다운로드하고
openssl
을 사용하여 서명을 확인합니다.curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.9.8-asm.6-osx.tar.gz.1.sig openssl dgst -sha256 -verify /dev/stdin -signature istio-1.9.8-asm.6-osx.tar.gz.1.sig istio-1.9.8-asm.6-osx.tar.gz <<'EOF' -----BEGIN PUBLIC KEY----- MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw== -----END PUBLIC KEY----- EOF
예상되는 출력은
Verified OK
입니다.원하는 파일 시스템 위치에 파일 콘텐츠 압축을 풉니다. 예를 들어 콘텐츠를 현재 작업 디렉터리에 추출하려면 다음을 사용하세요.
tar xzf istio-1.9.8-asm.6-osx.tar.gz
이 명령어는 다음을 포함하는 현재 작업 디렉터리에
istio-1.9.8-asm.6
이라는 설치 디렉터리를 만듭니다.- 샘플 애플리케이션은
samples
디렉터리에 있습니다. - Anthos Service Mesh를 설치하는 데 사용하는
istioctl
명령줄 도구는bin
디렉터리에 있습니다. - Anthos Service Mesh 구성 프로필은
manifests/profiles
디렉터리에 있습니다.
- 샘플 애플리케이션은
Anthos Service Mesh 설치 루트 디렉터리에 있는지 확인합니다.
cd istio-1.9.8-asm.6
Windows
Anthos Service Mesh 설치 파일을 현재 작업 디렉터리에 다운로드합니다.
curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.9.8-asm.6-win.zip
서명 파일을 다운로드하고
openssl
을 사용하여 서명을 확인합니다.curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.9.8-asm.6-win.zip.1.sig openssl dgst -verify - -signature istio-1.9.8-asm.6-win.zip.1.sig istio-1.9.8-asm.6-win.zip <<'EOF' -----BEGIN PUBLIC KEY----- MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw== -----END PUBLIC KEY----- EOF
예상되는 출력은
Verified OK
입니다.원하는 파일 시스템 위치에 파일 콘텐츠 압축을 풉니다. 예를 들어 콘텐츠를 현재 작업 디렉터리에 추출하려면 다음을 사용하세요.
tar xzf istio-1.9.8-asm.6-win.zip
이 명령어는 다음을 포함하는 현재 작업 디렉터리에
istio-1.9.8-asm.6
이라는 설치 디렉터리를 만듭니다.- 샘플 애플리케이션은
samples
디렉터리에 있습니다. - Anthos Service Mesh를 설치하는 데 사용하는
istioctl
명령줄 도구는bin
디렉터리에 있습니다. - Anthos Service Mesh 구성 프로필은
manifests/profiles
디렉터리에 있습니다.
- 샘플 애플리케이션은
Anthos Service Mesh 설치 루트 디렉터리에 있는지 확인합니다.
cd istio-1.9.8-asm.6
리소스 구성 파일 준비
istioctl install
명령어를 실행할 때는 명령줄에 revisioned-custom-ingressgateway.yaml
파일을 포함합니다. 이 파일을 사용하면 업그레이드 후 새 버전의 istio-ingressgateway
로 전환할 시기를 제어할 수 있습니다. 이 파일을 다운로드하고 구성하려면 다음 단계를 따르세요.
anthos-service-mesh
패키지를 다운로드할 디렉터리로 변경합니다.패키지를 다운로드합니다.
kpt pkg get \ https://github.com/GoogleCloudPlatform/anthos-service-mesh-packages.git/asm@release-1.9-asm asm
설치하려는 Anthos Service Mesh 버전으로 태그를 설정합니다.
kpt cfg set asm anthos.servicemesh.tag 1.9.8-asm.6
유효성 검증 웹훅이 버전 라벨을 사용하도록 설정합니다.
kpt cfg set asm anthos.servicemesh.rev asm-198-6
Anthos Service Mesh를 설치할 때
istiod
에 버전 라벨을 설정합니다. 유효성 검증 웹훅에 동일한 버전을 설정해야 합니다.
Anthos Service Mesh 업그레이드
새 버전의 Anthos Service Mesh를 설치하려면 버전 기반 업그레이드 프로세스('카나리아 업그레이드'라고도 함)를 따르는 것이 좋습니다. 버전 기반 업그레이드의 경우 기존 제어 영역 옆에 제어 영역의 새 버전을 설치합니다. 새 버전을 설치할 때 새 제어 영역의 버전을 식별하는 revision
라벨을 포함합니다. 각 버전은 자체 배포 및 서비스로 구현된 전체 Anthos Service Mesh 제어 영역입니다.
그런 다음 워크로드의 동일한 revision
라벨이 새 제어 영역을 가리키도록 설정하고 순차적 재시작을 수행하여 새 Anthos Service Mesh 버전으로 프록시를 다시 삽입합니다. 이 방식을 사용하면 일부 워크로드에서 업그레이드의 효과를 모니터링할 수 있습니다. 애플리케이션을 테스트한 후 모든 트래픽을 새 버전으로 마이그레이션할 수 있습니다. 이 방식은 새로운 제어 영역이 이전 버전의 제어 영역을 대체하는 인플레이스(In-Place) 업그레이드보다 훨씬 안전합니다.
제어 영역 업데이트
필요한 경우
istio-1.9.8-asm.6
디렉터리로 변경합니다.istioctl
클라이언트는 버전에 따라 다릅니다.istio-1.9.8-asm.6/bin
디렉터리의 버전을 사용해야 합니다.다음 명령어를 실행하여 새 제어 영역을 배포합니다. 지원되는 선택 기능을 사용 설정하려면 다음 명령줄에
-f
와 YAML 파일 이름을 포함합니다. 자세한 내용은 선택 기능 사용 설정을 참조하세요.bin/istioctl install \ --set profile=asm-multicloud \ -f asm/istio/options/revisioned-istio-ingressgateway.yaml \ --set revision=asm-198-6
--set revision
인수는 istio.io/rev
라벨을 istiod
에 추가합니다. 명령어를 실행하면 두 개의 제어 영역 배포와 서비스가 나란히 실행됩니다.
kubectl get pods -n istio-system
워크로드 배포 및 재배포
istiod
및istio-ingressgateway
에 있는 버전 라벨을 가져옵니다.kubectl get pod -n istio-system -L istio.io/rev
명령어 출력은 다음과 비슷합니다.
NAME READY STATUS RESTARTS AGE REV istio-ingressgateway-65d884685d-6hrdk 1/1 Running 0 67m istio-ingressgateway-65d884685d-94wgz 1/1 Running 0 67m istio-ingressgateway-asm-182-2-8b5fc8767-gk6hb 1/1 Running 0 5s asm-198-6 istio-ingressgateway-asm-182-2-8b5fc8767-hn4w2 1/1 Running 0 20s asm-198-6 istiod-asm-176-1-67998f4b55-lrzpz 1/1 Running 0 68m asm-186-8 istiod-asm-176-1-67998f4b55-r76kr 1/1 Running 0 68m asm-186-8 istiod-asm-182-2-5cd96f88f6-n7tj9 1/1 Running 0 27s asm-198-6 istiod-asm-182-2-5cd96f88f6-wm68b 1/1 Running 0 27s asm-198-6
istio-ingressgateway
에 이전 버전과 새 버전이 모두 있는지 확인합니다.업그레이드 시
revisioned-istio-ingressgateway
옵션이 포함되어 있다면istio-ingressgateway
의 카나리아 업그레이드가 완료된 것입니다. 이 경우 출력에 이전 버전과 새 버전의istio-ingressgateway
가 모두 표시됩니다.업그레이드 시
revisioned-istio-ingressgateway
를 포함하지 않은 경우라면istio-ingressgateway
의 인플레이스 업그레이드가 완료된 것입니다. 이 경우 출력에는 새 버전만 표시됩니다.
출력의
REV
열에서 새 버전에 대한 버전 라벨 값을 확인합니다. 이 예시에서 값은asm-198-6
입니다.또한 이전
istiod
버전의 버전 라벨 값을 기록해 두세요. 워크로드를 새 버전으로 이동하고 나면istiod
의 이전 버전을 삭제할 때 필요합니다. 예시 출력에서 이전 버전의 버전 라벨 값은asm-186-8
입니다.
이전 버전과 새 버전의
istio-ingressgateway
가 모두 있는 경우istio-ingressgateway
를 새 버전으로 전환합니다. 다음 명령어에서REVISION
을 새 버전의 버전 라벨과 일치하는 값으로 변경합니다.kubectl patch service -n istio-system istio-ingressgateway --type='json' -p='[{"op": "replace", "path": "/spec/selector/service.istio.io~1canonical-revision", "value": "REVISION"}]'
예상 출력:
service/istio-ingressgateway patched
네임스페이스에 버전 라벨을 추가하고
istio-injection
라벨을 삭제합니다(있는 경우). 다음 명령어에서REVISION
을istiod
의 새 버전과 일치하는 값으로 변경합니다.kubectl label namespace NAMESPACE istio.io/rev=REVISION istio-injection- --overwrite
출력에
"istio-injection not found"
가 표시되면 무시해도 됩니다. 이것은 이전에 네임스페이스에istio-injection
라벨이 없음을 의미합니다. 네임스페이스에istio-injection
및 버전 라벨이 모두 포함된 경우 자동 삽입이 실패하기 때문에 Anthos Service Mesh 문서에서 모든kubectl label
명령어에는istio-injection
라벨 삭제가 포함됩니다.pod를 다시 시작하여 재삽입을 트리거합니다.
kubectl rollout restart deployment -n NAMESPACE
pod가 새 버전의
istiod
를 가리키도록 구성되었는지 확인합니다.kubectl get pods -n NAMESPACE -l istio.io/rev=REVISION
애플리케이션을 테스트하여 워크로드가 올바르게 작동하는지 확인합니다.
다른 네임스페이스에 워크로드가 있으면 단계를 반복하여 네임스페이스에 라벨을 지정하고 pod를 다시 시작합니다.
애플리케이션이 예상대로 만족스럽게 작동한다면 계속해서 남은 단계를 진행하여
istiod
의 새 버전으로의 전환합니다. 애플리케이션에 문제가 있는 경우 롤백 단계를 따르세요.다음 명령어를 다시 실행하여
istio-ingressgateway
의 이전 버전과 새 버전 모두 있는지 또는 새 버전만 있는지 확인하십시오. 이에 따라istio-ingressgateway
의 새 버전으로 전환하거나 이전 버전으로 롤백하는 방법을 결정합니다.kubectl get pod -n istio-system -L istio.io/rev
전환 완료
애플리케이션이 예상 대로 작동하여 만족스러우면 이전 제어 영역을 삭제하여 새 버전으로의 변환을 완료합니다.
anthos-service-mesh
GitHub 저장소의 파일이 있는 디렉터리로 변경합니다.새 제어 영역을 사용하도록 검증 웹훅을 구성합니다.
kubectl apply -f asm/istio/istiod-service.yaml
이전 버전 및 새 버전의
istio-ingressgateway
가 모두 있다면 이전istio-ingressgateway
배포를 삭제합니다. 실행하는 명령어는 Istio에서 마이그레이션할지 아니면 이전 버전의 Anthos Service Mesh에서 업그레이드할지에 따라 달라집니다.마이그레이션
Istio에서 마이그레이션한 경우 이전
istio-ingressgateway
에는 버전 라벨이 없습니다.kubectl delete deploy/istio-ingressgateway -n istio-system
업그레이드
이전 Anthos Service Mesh 버전에서 업그레이드한 경우 다음 명령어에서
OLD_REVISION
을 이전 버전의istio-ingressgateway
에 대한 버전 라벨로 바꿉니다.kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=OLD_REVISION -n istio-system --ignore-not-found=true
istiod
의 이전 버전을 삭제합니다. 사용하는 명령어는 Istio에서 마이그레이션하는지 또는 이전 버전의 Anthos Service Mesh에서 업그레이드하는지에 따라 다릅니다.마이그레이션
Istio에서 마이그레이션한 경우 이전
istiod
에는 버전 라벨이 없습니다.kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod -n istio-system --ignore-not-found=true
업그레이드
이전 Anthos Service Mesh 버전에서 업그레이드한 경우 다음 명령어에서
OLD_REVISION
이 이전 버전의istiod
에 대한 버전 라벨과 일치하는지 확인합니다.kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-OLD_REVISION -n istio-system --ignore-not-found=true
IstioOperator
구성의 이전 버전을 삭제합니다.kubectl delete IstioOperator installed-state-OLD_REVISION -n istio-system
출력은 다음과 비슷합니다.
istiooperator.install.istio.io "installed-state-OLD_REVISION" deleted
롤백
istiod
의 새 버전으로 애플리케이션을 테스트할 때 문제가 발생하면 다음 안내에 따라 이전 버전으로 롤백하세요.istio-ingressgateway
의 이전 버전으로 다시 전환합니다. 사용하는 명령어는 이전 버전과 새 버전의istio-ingressgateway
를 모두 가지고 있는지 아니면 새 버전만 가지고 있는지에 따라 달라집니다.이전 버전과 새 버전의
istio-ingressgateway
가 모두 있는 경우kubectl patch service
명령어를 실행하고OLD_REVISION
을 이전 버전으로 바꿉니다.kubectl patch service -n istio-system istio-ingressgateway --type='json' -p='[{"op": "replace", "path": "/spec/selector/service.istio.io~1canonical-revision", "value": "OLD_REVISION"}]'
새 버전의
istio-ingressgateway
만 있는 경우kubectl rollout undo
명령어를 실행합니다.kubectl -n istio-system rollout undo deploy istio-ingressgateway
이전 버전의
istiod
에 자동 주입을 사용 설정하려면 네임스페이스의 라벨을 다시 지정합니다. 이전 버전에 버전 라벨을 사용했는지,istio-injection=enabled
를 사용했는지에 따라 다른 명령어를 사용합니다.자동 삽입을 위해 버전 라벨을 사용한 경우:
kubectl label namespace NAMESPACE istio.io/rev=OLD_REVISION --overwrite
istio-injection=enabled
를 사용한 경우:kubectl label namespace NAMESPACE istio.io/rev- istio-injection=enabled --overwrite
예상 출력:
namespace/NAMESPACE labeled
네임스페이스의 버전 라벨이 이전 버전
istiod
의 버전 라벨과 일치하는지 확인합니다.kubectl get ns NAMESPACE --show-labels
프록시에 이전 버전이 지정되도록 재삽입을 트리거하는 포드를 다시 시작합니다.
kubectl rollout restart deployment -n NAMESPACE
이전 버전과 새 버전의
istio-ingressgateway
가 모두 있으면 새istio-ingressgateway
배포를 삭제합니다. 다음 명령어의REVISION
값이 올바른지 확인합니다.kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=REVISION -n istio-system --ignore-not-found=true
istiod
의 새 버전을 삭제합니다. 다음 명령어의REVISION
값이 올바른지 확인합니다.kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-REVISION -n istio-system --ignore-not-found=true
IstioOperator
구성의 새 버전을 삭제합니다.kubectl delete IstioOperator installed-state-REVISION -n istio-system
예상 출력은 다음과 비슷합니다.
istiooperator.install.istio.io "installed-state-REVISION" deleted
--disable_canonical_service
플래그가 포함되지 않았으면 스크립트는 표준 서비스 컨트롤러를 사용 설정합니다. 사용 설정 상태로 두는 것이 좋지만 사용 중지해야 하는 경우 표준 서비스 컨트롤러 사용 설정 및 중지를 참조하세요.