카나리아 기반 Mesh CA로 마이그레이션
Istio CA(Citadel)에서 Cloud Service Mesh 인증 기관(Mesh CA)으로 마이그레이션하려면 신뢰할 수 있는 루트를 마이그레이션해야 합니다. Cloud Service Mesh 1.10 이전에는 Google Kubernetes Engine(GKE)의 Istio에서 Mesh CA가 있는 Cloud Service Mesh로 마이그레이션하려는 경우 Cloud Service Mesh에서 여러 루트 인증서 로드가 지원되지 않았기 때문에 다운타임을 예약해야 했습니다. 따라서 마이그레이션하는 동안 새로 배포된 워크로드에는 새 루트 인증서가 사용되고, 다른 워크로드에는 이전 루트 인증서가 사용되었습니다. 서로 다른 루트 인증서로 서명된 인증서를 사용하는 워크로드는 서로 인증할 수 없습니다. 즉, 마이그레이션하는 동안 상호 TLS(mTLS) 트래픽이 중단됩니다. 컨트롤 플레인과 모든 네임스페이스의 모든 워크로드가 Mesh CA의 인증서와 함께 다시 배포되는 경우에만 전체 클러스터가 완전히 복구됩니다. 다른 클러스터의 워크로드에 요청을 전송하는 워크로드와 함께 여러 클러스터가 메시에 포함된 경우 이러한 클러스터의 모든 워크로드도 함께 업데이트해야 합니다.
다음 사용 사례에 대해 이 가이드의 단계를 따르세요.
- Istio on GKE에서 Mesh CA가 있는 Cloud Service Mesh 1.19.10-asm.9 클러스터 내 컨트롤 플레인으로 마이그레이션하기
- Istio CA가 있는 Cloud Service Mesh 1.15 or a 1.16 patch release 에서 Mesh CA가 있는 Cloud Service Mesh 1.19.10-asm.9 클러스터 내 컨트롤 플레인으로 업그레이드하기
제한사항
- 모든 GKE 클러스터는 동일한 Google Cloud 프로젝트에 있어야 합니다.
기본 요건
종속 도구 설치 및 클러스터 검증의 단계를 따라 다음을 수행합니다.필수 도구
마이그레이션 중에 Google에서 제공하는 도구인 migrate_ca를 실행하여 클러스터의 각 포드에 대해 다음 사항을 확인합니다.
- Istio CA 및 Mesh CA의 루트 인증서
- Istio CA 및 Mesh CA에서 발급된 워크로드 mTLS 인증서
- Istio CA 및 Mesh CA에서 구성된 신뢰 도메인
이 도구에는 다음과 같은 종속 항목이 있습니다.
awkgrepistioctl:asmcli install을 실행하면 설치 중인 Cloud Service Mesh 버전과 일치하는istioctl버전이 다운로드됩니다.jqkubectlopenssl
마이그레이션 개요
Mesh CA로 마이그레이션하기 위해 버전 기반 마이그레이션 프로세스('카나리아 업그레이드'라고도 부름)를 따릅니다. 버전 기반 마이그레이션에서는 기존 컨트롤 플레인과 함께 새로운 컨트롤 플레인 버전이 배포됩니다. 그런 후 워크로드를 새 버전으로 점진적으로 이동하여, 프로세스를 진행하면서 마이그레이션의 효과를 모니터링할 수 있습니다. 마이그레이션 프로세스를 진행하는 동안 Mesh CA를 사용하는 워크로드와 Istio CA를 사용하는 워크로드 간에 인증 및 승인이 완전히 작동합니다.
다음은 Mesh CA로의 마이그레이션에 대한 개요입니다.
Mesh CA 신뢰할 수 있는 루트를 배포합니다.
Mesh CA 신뢰할 수 있는 루트를 배포하는 옵션이 있는 Istio CA를 사용하여 새 컨트롤 플레인 버전을 설치합니다.
네임스페이스별로 워크로드를 새로운 컨트롤 플레인으로 마이그레이션하고 애플리케이션을 테스트합니다. 모든 워크로드가 새 컨트롤 플레인으로 성공적으로 마이그레이션되었으면 이전 컨트롤 플레인을 삭제합니다.
Mesh CA로 마이그레이션합니다. 이제 모든 사이드카 프록시가 이전 신뢰할 수 있는 루트 및 Mesh CA 신뢰할 수 있는 루트로 구성되었으므로 다운타임 없이 Mesh CA로 마이그레이션할 수 있습니다. 다시 한 번 버전 기반 마이그레이션 프로세스를 따릅니다.
Mesh CA가 사용 설정된 컨트롤 플레인 버전을 설치합니다.
네임스페이스별로 워크로드를 새로운 컨트롤 플레인 버전으로 마이그레이션하고 애플리케이션을 테스트합니다. 모든 워크로드가 새 컨트롤 플레인으로 성공적으로 마이그레이션되었으면 이전 컨트롤 플레인을 삭제합니다.
이전 CA와 연결된 클러스터에서 CA 보안 비밀을 삭제하고 새 컨트롤 플레인을 다시 시작합니다.
Mesh CA 신뢰할 수 있는 루트 배포
Mesh CA로 마이그레이션하려면 메시의 모든 GKE 클러스터에 Cloud Service Mesh 1.10 이상이 있어야 하며, 모든 클러스터는 Mesh CA의 신뢰할 수 있는 루트가 클러스터에 있는 모든 워크로드의 프록시에 배포되도록 트리거하는 컨트롤 플레인 옵션으로 구성되어 있어야 합니다. 프로세스가 완료되면 각 프록시는 이전의 신뢰할 수 있는 루트와 새로운 신뢰할 수 있는 루트로 구성됩니다. 이 체계를 사용하면 Mesh CA로 마이그레이션할 때 Mesh CA를 사용하는 워크로드는 이전 CA를 사용하는 워크로드로 인증할 수 있습니다.
새 컨트롤 플레인 버전 설치
Mesh CA 신뢰할 수 있는 루트를 배포하는 옵션을 사용하여 컨트롤 플레인 버전을 설치합니다.
종속 도구 설치 및 클러스터 검증의 단계에 따라 Google에서 제공하는 도구인
asmcli를 사용하여 새 제어 영역 버전을 설치할 수 있습니다.Cloud Service Mesh 1.11 이상을 설치하는
asmcli버전을 보유하고 있는지 확인하세요../asmcli --version
asmcli install를 실행합니다. 다음 명령어에서 자리표시자를 원하는 값으로 바꿉니다../asmcli install \ --fleet_id FLEET_PROJECT_ID \ --kubeconfig KUBECONFIG_FILE \ --enable_all \ --ca citadel \ --ca_cert CA_CERT_FILE_PATH \ --ca_key CA_KEY_FILE_PATH \ --root_cert ROOT_CERT_FILE_PATH \ --cert_chain CERT_CHAIN_FILE_PATH \ --option ca-migration-citadel \ --revision_name REVISION_1 \ --output_dir DIR_PATH
--fleet_id: Fleet 호스트 프로젝트의 프로젝트 ID입니다.--kubeconfig:kubeconfig파일의 경로입니다. 상대 경로 또는 전체 경로를 지정할 수 있습니다. 여기서 환경 변수$PWD는 작동하지 않습니다.--output_dir:asmcli가anthos-service-mesh패키지를 다운로드하고 설치 파일을 추출하며,istioctl, 샘플, 매니페스트가 포함되는 디렉터리를 지정하려면 이 옵션을 포함합니다. 그렇지 않으면asmcli가 파일을tmp디렉터리에 다운로드합니다. 상대 경로 또는 전체 경로를 지정할 수 있습니다. 여기서 환경 변수$PWD는 작동하지 않습니다.-
--enable_all도구를 사용하여 다음을 수행할 수 있습니다.- 필요한 IAM 권한을 부여합니다.
- 필요한 Google API를 사용 설정합니다.
- 메시를 식별하는 라벨을 클러스터에 설정합니다.
- 아직 등록되지 않은 경우 Fleet에 클러스터를 등록합니다.
-ca citadel: 다운타임을 피하려면 Istio CA를 지정합니다(citadel옵션은 Istio CA에 해당). 이 시점에서는 Mesh CA로 전환하지 마세요.--ca_cert: 중간 인증서--ca_key: 중간 인증서의 키--root_cert: 루트 인증서--cert_chain: 인증서 체인--option ca-migration-citadel: 워크로드를 재배포할 때 이 옵션은 새로운 신뢰할 수 있는 루트가 워크로드의 사이드카 프록시에 배포되도록 트리거합니다.REVISION_1: 권장. 버전 라벨은 컨트롤 플레인에 설정된 키-값 쌍입니다. 버전 라벨 키는 항상istio.io/rev입니다. 기본적으로 도구는 Cloud Service Mesh 버전을 기준으로 버전 라벨 값을 설정합니다(예:asm-11910-9). 이 옵션을 포함하고REVISION_1을 설치를 설명하는 이름(예:asm-11910-9-distribute-root)으로 바꾸는 것이 좋습니다. 이름은 DNS-1035 라벨이어야 하며 소문자 영숫자 문자 또는-가 포함되고 영숫자 문자로 시작하고 영숫자 문자(예:my-name또는abc-123)로 끝나야 합니다.
새 컨트롤 플레인으로 워크로드 마이그레이션
새 신뢰할 수 있는 루트의 배포를 완료하려면 버전 라벨 istio.io/rev=<var>REVISION_1</var>-distribute-root로 네임스페이스에 라벨을 지정하고 워크로드를 다시 시작해야 합니다. 워크로드를 다시 시작한 후 테스트할 때는 도구를 실행하여 사이드카 프록시가 Mesh CA의 이전 신뢰할 수 있는 루트와 새 루트로 구성되었는지 확인합니다.
kubectl의 현재 컨텍스트를 설정합니다. 다음 명령어에서 단일 영역 클러스터가 있으면--region을--zone으로 변경합니다.gcloud container clusters get-credentials CLUSTER_NAME \ --project=PROJECT_ID \ --region=CLUSTER_LOCATION유효성 검사 도구를 다운로드합니다.
curl https://raw.githubusercontent.com/GoogleCloudPlatform/anthos-service-mesh-packages/master/scripts/ca-migration/migrate_ca > migrate_ca
도구에서 실행 가능한 비트를 설정합니다.
chmod +x migrate_ca
migrate_ca도구는 버전에 따라 달라지는istioctl을 호출합니다.asmcli도구는--output_dir에 대해 지정한 디렉터리의istioctl에 대해 심볼릭 링크를 추가합니다. 디렉터리가 경로의 시작 부분에 있는지 확인합니다. 다음 명령어에서ISTIOCTL_PATH를 도구가 다운로드한istioctl이 포함된 디렉터리로 바꿉니다.export PATH=ISTIOCTL_PATH:$PATH which istioctl echo $PATH
istiod및istio-ingressgateway에 있는 버전 라벨을 가져옵니다.kubectl get pod -n istio-system -L istio.io/rev
출력은 다음과 비슷합니다.
NAME READY STATUS RESTARTS AGE REV istio-ingressgateway-5fd454f8ff-t7w9x 1/1 Running 0 36m default istio-ingressgateway-asm-195-2-distribute-root-c6ccfbdbd-z2s9p 1/1 Running 0 18m asm-195-2-distribute-root istio-ingressgateway-asm-195-2-distribute-root-c6ccfbdbd-zr2cs 1/1 Running 0 18m asm-195-2-distribute-root istiod-68bc495f77-shl2h 1/1 Running 0 36m default istiod-asm-195-2-distribute-root-6f764dbb7c-g9f8c 1/1 Running 0 18m asm-195-2-distribute-root istiod-asm-195-2-distribute-root-6f764dbb7c-z7z9s 1/1 Running 0 18m asm-195-2-distribute-root
출력의
REV열에서 새 버전의 버전 라벨 값을 메모하세요. 이 값은asmcli install를 실행할 때 지정한 버전 라벨과 일치합니다. 이 예시에서 값은asm-11910-9-distribute-root입니다.워크로드를 새 버전으로 이동한 후
istiod의 이전 버전을 삭제해야 합니다. 이전istiod버전의 버전 라벨 값을 기록합니다. 예시 출력에서는default버전을 사용하는 Istio에서의 마이그레이션을 보여줍니다.
네임스페이스에 버전 라벨을 추가하고
istio-injection라벨을 삭제합니다(있는 경우). 다음 명령어에서NAMESPACE를 라벨에 대한 네임스페이스로 바꿉니다.kubectl label namespace NAMESPACE istio.io/rev=REVISION_1 istio-injection- --overwrite
출력에
"istio-injection not found"가 표시되면 무시해도 됩니다. 이것은 이전에 네임스페이스에istio-injection라벨이 없음을 의미합니다. 네임스페이스에istio-injection및 버전 라벨 모두 포함된 경우 자동 삽입 동작이 정의되지 않으므로 Cloud Service Mesh 문서의 모든kubectl label명령어에서 명시적으로 하나만 설정되었는지 확인합니다.포드를 다시 시작하여 재삽입을 트리거합니다.
kubectl rollout restart deployment -n NAMESPACE
애플리케이션을 테스트하여 워크로드가 올바르게 작동하는지 확인합니다.
다른 네임스페이스에 워크로드가 있으면 단계를 반복하여 네임스페이스에 라벨을 지정하고 포드를 다시 시작합니다.
클러스터의 모든 워크로드에 대한 사이드카 프록시가 이전 및 새 루트 인증서를 모두 사용하여 구성되었는지 검증합니다.
./migrate_ca check-root-cert
예상 출력:
Namespace: foo httpbin-66cdbdb6c5-pmzps.foo trusts [CITADEL MESHCA] sleep-64d7d56698-6tmjm.foo trusts [CITADEL MESHCA]
게이트웨이를 마이그레이션해야 하는 경우 카나리아 업그레이드(고급)의 단계에 따라 새 게이트웨이 배포를 설치합니다. 다음 사항을 기억하세요.
REVISION_1을 버전 라벨로 사용합니다.- 이전 설치에서 게이트웨이와 동일한 네임스페이스에 게이트웨이 리소스를 배포하여 다운타임 없는 마이그레이션을 수행합니다. 이전 게이트웨이를 가리키는 서비스 리소스에 최신 배포도 포함되어 있는지 확인합니다.
- 다음 단계 후에 애플리케이션이 올바르게 작동하는지 확인할 때까지 이전 게이트웨이 배포를 삭제하지 마세요.
애플리케이션이 예상대로 만족스럽게 작동한다면 계속해서 남은 단계를 진행하여
istiod의 새 버전으로의 전환합니다. 애플리케이션에 문제가 있는 경우 롤백 단계를 따르세요.전환 완료
애플리케이션이 예상 대로 작동하여 만족스러우면 이전 컨트롤 플레인을 삭제하여 새 버전으로의 변환을 완료합니다.
anthos-service-meshGitHub 저장소의 파일이 있는 디렉터리로 변경합니다.새 컨트롤 플레인을 사용하도록 검증 웹훅을 구성합니다.
kubectl apply -f asm/istio/istiod-service.yaml
이전
istio-ingressgateway배포를 삭제합니다. 실행하는 명령어는 Istio에서 마이그레이션하는지 또는 이전 버전의 Cloud Service Mesh에서 업그레이드하는지 여부에 따라 다릅니다.마이그레이션
Istio에서 마이그레이션한 경우 이전
istio-ingressgateway에는 버전 라벨이 없습니다.kubectl delete deploy/istio-ingressgateway -n istio-system
업그레이드
이전 Cloud 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에서 마이그레이션하는지 또는 이전 버전의 Cloud Service Mesh에서 업그레이드하는지에 따라 다릅니다.마이그레이션
Istio에서 마이그레이션한 경우 이전
istio-ingressgateway에는 버전 라벨이 없습니다.kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod -n istio-system --ignore-not-found=true
업그레이드
이전 Cloud 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의 새 버전으로 애플리케이션을 테스트할 때 문제가 발생하면 다음 안내에 따라 이전 버전으로 롤백하세요.11단계의 일부로 설치된 새 게이트웨이 배포를 삭제합니다.
이전 버전의
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배포를 삭제합니다.kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=REVISION_1 -n istio-system --ignore-not-found=true
istiod의 새 버전을 삭제합니다.kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-REVISION_1 -n istio-system --ignore-not-found=true
새
IstioOperator구성을 삭제합니다.kubectl delete IstioOperator installed-state-asm-11910-9-distribute-root -n istio-system
예상 출력은 다음과 비슷합니다.
istiooperator.install.istio.io "installed-state-asm-11910-9-distribute-root" deleted
Mesh CA로 마이그레이션
이제 모든 워크로드의 사이드카 프록시가 Mesh CA의 이전 신뢰 루트와 새 신뢰 루트로 구성되었으므로, Mesh CA로 마이그레이션하는 단계는 신뢰할 수 있는 Mesh CA 신뢰할 수 있는 루트를 배포할 때 밟은 단계와 비슷합니다.
Mesh CA가 사용 설정된 새 컨트롤 플레인 설치
asmcli install를 사용하여 Mesh CA가 사용 설정된 새 컨트롤 플레인 버전을 설치합니다.
이전 설치를 맞춤설정한 경우
asmcli install을 실행할 때 동일한 오버레이 파일을 지정해야 합니다.asmcli install를 실행합니다. 다음 명령어에서 자리표시자를 원하는 값으로 바꿉니다../asmcli install \ --fleet_id FLEET_PROJECT_ID \ --kubeconfig KUBECONFIG_FILE \ --output_dir DIR_PATH \ --enable_all \ --ca mesh_ca \ --root_cert ROOT_CERT_FILE_PATH \ --cert_chain CERT_CHAIN_FILE_PATH --option ca-migration-meshca \ --revision_name REVISION_2 \ --output_dir DIR_PATH \ OVERLAYS
--fleet_id: Fleet 호스트 프로젝트의 프로젝트 ID입니다.--kubeconfig:kubeconfig파일의 경로입니다. 상대 경로 또는 전체 경로를 지정할 수 있습니다. 여기서 환경 변수$PWD는 작동하지 않습니다.--output_dirasmcli가anthos-service-mesh패키지를 다운로드하고 설치 파일을 추출하며,istioctl, 샘플, 매니페스트가 포함되는 디렉터리를 지정하려면 이 옵션을 포함합니다. 그렇지 않으면asmcli가 파일을tmp디렉터리에 다운로드합니다. 상대 경로 또는 전체 경로를 지정할 수 있습니다. 여기서 환경 변수$PWD는 작동하지 않습니다.-
--enable_all도구를 사용하여 다음을 수행할 수 있습니다.- 필요한 IAM 권한을 부여합니다.
- 필요한 Google API를 사용 설정합니다.
- 메시를 식별하는 라벨을 클러스터에 설정합니다.
- 아직 등록되지 않은 경우 Fleet에 클러스터를 등록합니다.
--ca mesh_ca: 이제 Mesh CA 신뢰할 수 있는 루트가 배포되었으므로 Mesh CA로 전환할 수 있습니다.REVISION_2권장REVISION_2를asm-11910-9-meshca-ca-migration과 같이 설치를 설명하는 이름으로 바꿉니다. 이름은 DNS-1035 라벨이어야 하며 소문자 영숫자 문자 또는-가 포함되고 영숫자 문자로 시작하고 영숫자 문자(예:my-name또는abc-123)로 끝나야 합니다.--option ca-migration-migration: 워크로드를 재배포할 때 이 옵션은 Mesh CA 신뢰할 수 있는 루트를 사용하도록 프록시를 구성합니다.
새 컨트롤 플레인으로 워크로드 마이그레이션
설치를 완료하려면 새 버전 라벨로 네임스페이스에 라벨을 지정하고 워크로드를 다시 시작해야 합니다.
istiod및istio-ingressgateway에 있는 버전 라벨을 가져옵니다.kubectl get pod -n istio-system -L istio.io/rev
출력은 다음과 비슷합니다.
NAME READY STATUS RESTARTS AGE REV istio-ingressgateway-asm-11910-9-distribute-root-65d884685d-6hrdk 1/1 Running 0 67m asm-11910-9-distribute-root istio-ingressgateway-asm-11910-9-distribute-root65d884685d-94wgz 1/1 Running 0 67m asm-11910-9-distribute-root istio-ingressgateway-asm-11910-9-meshca-ca-migration-8b5fc8767-gk6hb 1/1 Running 0 5s asm-11910-9-meshca-ca-migration istio-ingressgateway-asm-11910-9-meshca-ca-migration-8b5fc8767-hn4w2 1/1 Running 0 20s asm-11910-9-meshca-ca-migration istiod-asm-11910-9-distribute-root-67998f4b55-lrzpz 1/1 Running 0 68m asm-11910-9-distribute-root istiod-asm-11910-9-distribute-root-67998f4b55-r76kr 1/1 Running 0 68m asm-11910-9-distribute-root istiod-asm-11910-9-meshca-ca-migration-5cd96f88f6-n7tj9 1/1 Running 0 27s asm-11910-9-meshca-ca-migration istiod-asm-11910-9-meshca-ca-migration-5cd96f88f6-wm68b 1/1 Running 0 27s asm-11910-9-meshca-ca-migration
출력의
REV열에서 새 버전에 대한 버전 라벨 값을 확인합니다. 이 예시에서 값은asm-11910-9-meshca-ca-migration입니다.또한 이전
istiod버전의 버전 라벨 값을 기록해 두세요. 워크로드를 새 버전으로 이동하고 나면istiod의 이전 버전을 삭제할 때 필요합니다. 예시에서 이전 버전의 버전 라벨 값은asm-11910-9-distribute-root입니다.
네임스페이스에 새 버전 라벨을 추가합니다. 다음 명령어에서
NAMESPACE를 라벨의 네임스페이스로 바꾸세요.kubectl label namespace NAMESPACE istio.io/rev=REVISION_2 --overwrite
포드를 다시 시작하여 재삽입을 트리거합니다.
kubectl rollout restart deployment -n NAMESPACE
애플리케이션을 테스트하여 워크로드가 올바르게 작동하는지 확인합니다. 이전 네임스페이스의 워크로드와 새 네임스페이스의 워크로드 사이에 mTLS 통신이 작동하는지 확인합니다.
다른 네임스페이스에 워크로드가 있으면 단계를 반복하여 네임스페이스에 라벨을 지정하고 포드를 다시 시작합니다.
인플레이스(In-Place) 업그레이드에 설명된 단계에 따라 이전 섹션의 11단계에서 설치된 이전 게이트웨이 배포를 최신 버전
REVISION_2로 업그레이드합니다.애플리케이션이 예상대로 만족스럽게 작동한다면 계속해서 남은 단계를 진행하여 의 새 컨트롤 플레인으로 전환합니다. 애플리케이션에 문제가 있는 경우 롤백 단계를 따르세요.
전환 완료
애플리케이션이 예상 대로 작동하여 만족스러우면 이전 컨트롤 플레인을 삭제하여 새 버전으로의 변환을 완료합니다.
anthos-service-meshGitHub 저장소의 파일이 있는 디렉터리로 변경합니다.새 컨트롤 플레인을 사용하도록 검증 웹훅을 구성합니다.
kubectl apply -f asm/istio/istiod-service.yaml
이전
istio-ingressgateway배포를 삭제합니다. 다음 명령어에서OLD_REVISION을istio-ingressgateway의 이전 버전 라벨로 바꿉니다.kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=OLD_REVISION -n istio-system --ignore-not-found=true
이전
istiod버전을 삭제합니다. 다음 명령어에서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버전으로 애플리케이션을 테스트할 때 문제가 발생하면 다음 단계에 따라 이전 버전으로 롤백합니다.인플레이스(In-Place) 업그레이드의 단계에 따라 이전에 이 섹션의 6단계에서 업그레이드된 게이트웨이 배포를 이전 버전
REVISION_1로 다운그레이드합니다.네임스페이스의 라벨을 변경하여 이전
istiod버전으로 자동 삽입을 사용 설정합니다.kubectl label namespace NAMESPACE istio.io/rev=OLD_REVISION --overwrite
예상 출력:
namespace/NAMESPACE labeled
네임스페이스의 버전 라벨이 이전 버전
istiod의 버전 라벨과 일치하는지 확인합니다.kubectl get ns NAMESPACE --show-labels
프록시에 이전 버전이 지정되도록 재삽입을 트리거하는 포드를 다시 시작합니다.
kubectl rollout restart deployment -n NAMESPACE
새로운
istio-ingressgateway배포를 삭제합니다.kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=REVISION_2 -n istio-system --ignore-not-found=true
istiod의 새 버전을 삭제합니다. 다음 명령어의 버전 라벨이 본인의 버전과 일치하는지 확인합니다.kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-REVISION_2 -n istio-system --ignore-not-found=true
IstioOperator구성의 새 버전을 삭제합니다.kubectl delete IstioOperator installed-state-REVISION_2 -n istio-system
예상 출력은 다음과 비슷합니다.
istiooperator.install.istio.io "installed-state-REVISION_2" deleted
CA 보안 비밀을 삭제하고 새 컨트롤 플레인을 다시 시작
필요할 때를 위해 보안 비밀을 따로 기록해 둡니다.
kubectl get secret/cacerts -n istio-system -o yaml > save_file_1 kubectl get secret/istio-ca-secret -n istio-system -o yaml > save_file_2
이전 CA와 연결된 클러스터에서 CA 보안 비밀을 삭제합니다.
kubectl delete secret cacerts istio-ca-secret -n istio-system --ignore-not-found
새로 설치된 컨트롤 플레인을 다시 시작합니다. 이렇게 하면 메시에서 실행되는 모든 워크로드에서 이전 신뢰할 수 있는 루트가 삭제됩니다.
kubectl rollout restart deployment -n istio-system