Cloud Service Mesh 인증 기관으로의 카나리아 기반 이전

Note: 이 가이드는 다운타임이 최소화되거나 발생하지 않는 카나리아 기반 접근 방식을 사용하여 Istio CA에서 Cloud Service Mesh 인증 기관으로 마이그레이션하는 방법에 대해 설명합니다. 다운타임을 최소화하고 컨트롤 플레인을 마이그레이션하지 않고 CA를 마이그레이션하려면 인플레이스 CA 마이그레이션을 참조하세요.

Istio CA(Citadel)에서 Cloud Service Mesh 인증 기관(Cloud Service Mesh CA)으로 마이그레이션하려면 신뢰할 수 있는 루트를 마이그레이션해야 합니다. Cloud Service Mesh 1.10 이전에는 Google Kubernetes Engine(GKE)의 Istio에서 Cloud Service Mesh CA가 있는 Cloud Service Mesh로 마이그레이션하려는 경우 Cloud Service Mesh에서 여러 루트 인증서 로드가 지원되지 않았기 때문에 다운타임을 예약해야 했습니다. 따라서 마이그레이션하는 동안 새로 배포된 워크로드에는 새 루트 인증서가 사용되고, 다른 워크로드에는 이전 루트 인증서가 사용되었습니다. 서로 다른 루트 인증서로 서명된 인증서를 사용하는 워크로드는 서로 인증할 수 없습니다. 즉, 마이그레이션하는 동안 상호 TLS(mTLS) 트래픽이 중단됩니다. 컨트롤 플레인과 모든 네임스페이스의 모든 워크로드가 Cloud Service Mesh 인증 기관의 인증서와 함께 다시 배포되는 경우에만 전체 클러스터가 완전히 복구됩니다. 다른 클러스터의 워크로드에 요청을 전송하는 워크로드와 함께 여러 클러스터가 메시에 포함된 경우 이러한 클러스터의 모든 워크로드도 함께 업데이트해야 합니다.

다음 사용 사례에 대해 이 가이드의 단계를 따르세요.

• Istio on GKE에서 Cloud Service Mesh 인증 기관이 있는 Cloud Service Mesh 1.19.10-asm.9 클러스터 내 컨트롤 플레인으로 마이그레이션하기
• Istio CA가 있는 Cloud Service Mesh 1.15 or a 1.16 patch release 에서 Cloud Service Mesh 인증 기관이 있는 Cloud Service Mesh 1.19.10-asm.9 클러스터 내 컨트롤 플레인으로 업그레이드하기

제한사항

• 모든 GKE 클러스터는 동일한 Google Cloud 프로젝트에 있어야 합니다.

기본 요건

종속 도구 설치 및 클러스터 검증의 단계를 따라 다음을 수행합니다.

• 필수 도구 설치
• asmcli 다운로드
• 클러스터에 관리자 권한 부여
• 프로젝트 및 클러스터 검증

필수 도구

마이그레이션 중에 Google에서 제공하는 도구인 migrate_ca를 실행하여 클러스터의 각 포드에 대해 다음 사항을 확인합니다.

• Istio CA 및 Cloud Service Mesh 인증 기관의 루트 인증서
• Istio CA 및 Cloud Service Mesh 인증 기관에서 발급된 워크로드 mTLS 인증서
• Istio CA 및 Cloud Service Mesh 인증 기관에서 구성된 신뢰 도메인

이 도구에는 다음과 같은 종속 항목이 있습니다.

• awk
• grep
• istioctl: asmcli install을 실행하면 설치 중인 Cloud Service Mesh 버전과 일치하는 istioctl 버전이 다운로드됩니다.
• jq
• kubectl
• openssl

마이그레이션 개요

Cloud Service Mesh 인증 기관으로 마이그레이션하려면 버전 기반 마이그레이션 프로세스('카나리아 업그레이드'라고도 함)를 따릅니다. 버전 기반 마이그레이션에서는 기존 컨트롤 플레인과 함께 새로운 컨트롤 플레인 버전이 배포됩니다. 그런 후 워크로드를 새 버전으로 점진적으로 이동하여, 프로세스를 진행하면서 마이그레이션의 효과를 모니터링할 수 있습니다. 마이그레이션 프로세스를 진행하는 동안 Cloud Service Mesh 인증 기관을 사용하는 워크로드와 Istio CA를 사용하는 워크로드 간에 인증 및 승인이 완전히 작동합니다.

다음은 Cloud Service Mesh 인증 기관으로의 마이그레이션에 대한 개요입니다.

1. Cloud Service Mesh 인증 기관 신뢰할 수 있는 루트를 배포합니다.

   1. Cloud Service Mesh 인증 기관 신뢰할 수 있는 루트를 배포하는 옵션이 있는 Istio CA를 사용하여 새 컨트롤 플레인 버전을 설치합니다.

   2. 네임스페이스별로 워크로드를 새로운 컨트롤 플레인으로 마이그레이션하고 애플리케이션을 테스트합니다. 모든 워크로드가 새 컨트롤 플레인으로 성공적으로 마이그레이션되었으면 이전 컨트롤 플레인을 삭제합니다.

2. Cloud Service Mesh 인증 기관으로 마이그레이션합니다. 이제 모든 사이드카 프록시가 이전의 신뢰할 수 있는 루트 및 Cloud Service Mesh 인증 기관 신뢰할 수 있는 루트로 구성되었으므로 다운타임 없이 Cloud Service Mesh 인증 기관으로 마이그레이션할 수 있습니다. 다시 한 번 버전 기반 마이그레이션 프로세스를 따릅니다.

   1. Cloud Service Mesh 인증 기관이 사용 설정된 컨트롤 플레인 버전을 설치합니다.

   2. 네임스페이스별로 워크로드를 새로운 컨트롤 플레인 버전으로 마이그레이션하고 애플리케이션을 테스트합니다. 모든 워크로드가 새 컨트롤 플레인으로 성공적으로 마이그레이션되었으면 이전 컨트롤 플레인을 삭제합니다.

   3. 이전 CA와 연결된 클러스터에서 CA 보안 비밀을 삭제하고 새 컨트롤 플레인을 다시 시작합니다.

Cloud Service Mesh 인증 기관 신뢰할 수 있는 루트 배포

Cloud Service Mesh 인증 기관으로 마이그레이션하려면 메시의 모든 GKE 클러스터에 Cloud Service Mesh 1.10 이상이 있어야 하며, 모든 클러스터는 Cloud Service Mesh 인증 기관의 신뢰할 수 있는 루트가 클러스터에 있는 모든 워크로드의 프록시에 배포되도록 트리거하는 컨트롤 플레인 옵션으로 구성되어 있어야 합니다. 프로세스가 완료되면 각 프록시는 이전의 신뢰할 수 있는 루트와 새로운 신뢰할 수 있는 루트로 구성됩니다. 이 체계를 사용하면 Cloud Service Mesh 인증 기관으로 마이그레이션할 때 Cloud Service Mesh 인증 기관을 사용하는 워크로드는 이전 CA를 사용하는 워크로드로 인증할 수 있습니다.

새 컨트롤 플레인 버전 설치

Cloud Service Mesh 인증 기관 신뢰할 수 있는 루트를 배포하는 옵션을 사용하여 컨트롤 플레인 버전을 설치합니다.

1. 종속 도구 설치 및 클러스터 검증의 단계에 따라 Google에서 제공하는 도구인 asmcli를 사용하여 새 컨트롤 플레인 버전을 설치할 수 있습니다.

2. Cloud Service Mesh 1.11 이상을 설치하는 asmcli 버전을 보유하고 있는지 확인하세요.

   ./asmcli --version
   

3. 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에 해당). 이 시점에서는 Cloud Service Mesh 인증 기관으로 전환하지 마세요.
• --ca_cert: 중간 인증서
• --ca_key: 중간 인증서의 키
• --root_cert: 루트 인증서
• --cert_chain: 인증서 체인
• --option ca-migration-citadel: 워크로드를 재배포할 때 이 옵션은 새로운 신뢰할 수 있는 루트가 워크로드의 사이드카 프록시에 배포되도록 트리거합니다.
• REVISION_1: (권장) [버전 라벨](/service-mesh/docs/revisions-overview)은 컨트롤 플레인에 설정된 키-값 쌍입니다. 버전 라벨 키는 항상 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로 네임스페이스에 라벨을 지정하고 워크로드를 다시 시작해야 합니다. 워크로드를 다시 시작한 후 테스트할 때는 도구를 실행하여 사이드카 프록시가 Cloud Service Mesh 인증 기관의 이전 및 새로운 신뢰할 수 있는 루트로 구성되었는지 확인합니다.

1. kubectl의 현재 컨텍스트를 설정합니다. 다음 명령어에서 단일 영역 클러스터가 있으면 --region을 --zone으로 변경합니다.

   gcloud container clusters get-credentials CLUSTER_NAME \
       --project=PROJECT_ID \
       --region=CLUSTER_LOCATION
   

2. 유효성 검사 도구를 다운로드합니다.

   curl https://raw.githubusercontent.com/GoogleCloudPlatform/anthos-service-mesh-packages/master/scripts/ca-migration/migrate_ca > migrate_ca
   

3. 도구에서 실행 가능한 비트를 설정합니다.

   chmod +x migrate_ca
   

4. migrate_ca 도구는 버전에 따라 달라지는 istioctl을 호출합니다. asmcli 도구는 --output_dir에 대해 지정한 디렉터리의 istioctl에 대해 심볼릭 링크를 추가합니다. 디렉터리가 경로의 시작 부분에 있는지 확인합니다. 다음 명령어에서 ISTIOCTL_PATH를 도구가 다운로드한 istioctl이 포함된 디렉터리로 바꿉니다.

   export PATH=ISTIOCTL_PATH:$PATH
   which istioctl
   echo $PATH
   

5. 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

   1. 출력의 REV 열에서 새 버전의 버전 라벨 값을 메모하세요. 이 값은 asmcli install를 실행할 때 지정한 버전 라벨과 일치합니다. 이 예시에서 값은 asm-11910-9-distribute-root입니다.

   2. 워크로드를 새 버전으로 이동한 후 istiod의 이전 버전을 삭제해야 합니다. 이전 istiod 버전의 버전 라벨 값을 기록합니다. 예시 출력에서는 default 버전을 사용하는 Istio에서의 마이그레이션을 보여줍니다.

6. 네임스페이스에 버전 라벨을 추가하고 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 명령어에서 명시적으로 하나만 설정되었는지 확인합니다.

7. 포드를 다시 시작하여 재삽입을 트리거합니다.

   kubectl rollout restart deployment -n NAMESPACE
   

8. 애플리케이션을 테스트하여 워크로드가 올바르게 작동하는지 확인합니다.

9. 다른 네임스페이스에 워크로드가 있으면 단계를 반복하여 네임스페이스에 라벨을 지정하고 포드를 다시 시작합니다.

10. 클러스터의 모든 워크로드에 대한 사이드카 프록시가 이전 및 새 루트 인증서를 모두 사용하여 구성되었는지 검증합니다.

    ./migrate_ca check-root-cert
    

    예상 출력:

    Namespace: foo
    httpbin-66cdbdb6c5-pmzps.foo trusts [CITADEL MESHCA]
    sleep-64d7d56698-6tmjm.foo trusts [CITADEL MESHCA]

11. 게이트웨이를 마이그레이션해야 하는 경우 카나리아 업그레이드(고급)의 단계에 따라 새 게이트웨이 배포를 설치합니다. 다음 사항을 기억하세요.

    • REVISION_1을 버전 라벨로 사용합니다.
    • 이전 설치에서 게이트웨이와 동일한 네임스페이스에 게이트웨이 리소스를 배포하여 다운타임 없는 마이그레이션을 수행합니다. 이전 게이트웨이를 가리키는 서비스 리소스에 최신 배포도 포함되어 있는지 확인합니다.
    • 다음 단계 후에 애플리케이션이 올바르게 작동하는지 확인할 때까지 이전 게이트웨이 배포를 삭제하지 마세요.

12. 애플리케이션이 예상대로 만족스럽게 작동한다면 계속해서 남은 단계를 진행하여 istiod의 새 버전으로의 전환합니다. 애플리케이션에 문제가 있는 경우 롤백 단계를 따르세요.

    전환 완료

    애플리케이션이 예상 대로 작동하여 만족스러우면 이전 컨트롤 플레인을 삭제하여 새 버전으로의 변환을 완료합니다.

    1. anthos-service-mesh GitHub 저장소의 파일이 있는 디렉터리로 변경합니다.

    2. 새 컨트롤 플레인을 사용하도록 검증 웹훅을 구성합니다.

       kubectl apply -f asm/istio/istiod-service.yaml
       

    3. 이전 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
       

    4. 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
       

    5. IstioOperator 구성의 이전 버전을 삭제합니다.

       kubectl delete IstioOperator installed-state-OLD_REVISION -n istio-system
       

       출력은 다음과 비슷합니다.

       istiooperator.install.istio.io "installed-state-OLD_REVISION" deleted

    롤백

    istiod의 새 버전으로 애플리케이션을 테스트할 때 문제가 발생하면 다음 안내에 따라 이전 버전으로 롤백하세요.

    1. 11단계의 일부로 설치된 새 게이트웨이 배포를 삭제합니다.

    2. 이전 버전의 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

    3. 네임스페이스의 버전 라벨이 이전 버전 istiod의 버전 라벨과 일치하는지 확인합니다.

       kubectl get ns NAMESPACE --show-labels
       

    4. 프록시에 이전 버전이 지정되도록 재삽입을 트리거하는 포드를 다시 시작합니다.

       kubectl rollout restart deployment -n NAMESPACE
       

    5. 새로운 istio-ingressgateway 배포를 삭제합니다.

       kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=REVISION_1 -n istio-system --ignore-not-found=true
       

    6. istiod의 새 버전을 삭제합니다.

       kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-REVISION_1 -n istio-system --ignore-not-found=true
       

    7. 새 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

Cloud Service Mesh 인증 기관으로 마이그레이션

이제 모든 워크로드의 사이드카 프록시가 Cloud Service Mesh 인증 기관의 이전 신뢰 루트와 새 신뢰 루트로 구성되었으므로 Cloud Service Mesh 인증 기관으로 마이그레이션하는 단계는 Cloud Service Mesh 인증 기관 신뢰 루트를 배포할 때 밟은 단계와 비슷합니다.

Cloud Service Mesh 인증 기관이 사용 설정된 새 컨트롤 플레인 설치

asmcli install를 사용하여 Mesh CA가 사용 설정된 새 컨트롤 플레인 버전을 설치합니다.

1. 이전 설치를 맞춤설정한 경우 asmcli install을 실행할 때 동일한 오버레이 파일을 지정해야 합니다.

2. 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_dir asmcli가 anthos-service-mesh 패키지를 다운로드하고 설치 파일을 추출하며, istioctl, 샘플, 매니페스트가 포함되는 디렉터리를 지정하려면 이 옵션을 포함합니다. 그렇지 않으면 asmcli가 파일을 tmp 디렉터리에 다운로드합니다. 상대 경로 또는 전체 경로를 지정할 수 있습니다. 여기서 환경 변수 $PWD는 작동하지 않습니다.
   • --enable_all 도구를 사용하여 다음을 수행할 수 있습니다.
     • 필요한 IAM 권한을 부여합니다.
     • 필요한 Google API를 사용 설정합니다.
     • 메시를 식별하는 라벨을 클러스터에 설정합니다.
     • 아직 등록되지 않은 경우 Fleet에 클러스터를 등록합니다.
   • --ca mesh_ca: 이제 Cloud Service Mesh 인증 기관 신뢰할 수 있는 루트가 배포되었으므로 Cloud Service Mesh 인증 기관으로 전환할 수 있습니다.
   • REVISION_2 권장. REVISION_2를 asm-11910-9-meshca-ca-migration과 같이 설치를 설명하는 이름으로 바꿉니다. 이름은 DNS-1035 라벨이어야 하며 소문자 영숫자 문자 또는 -가 포함되고 영숫자 문자로 시작하고 영숫자 문자(예: my-name 또는 abc-123)로 끝나야 합니다.
   • --option ca-migration-migration [워크로드를 재배포](/service-mesh/docs/unified-install/install-anthos-service-mesh#deploy_and_redeploy_workloads)할 때 이 옵션은 Cloud Service Mesh 인증 기관 신뢰할 수 있는 루트를 사용하도록 프록시를 구성합니다.

새 컨트롤 플레인으로 워크로드 마이그레이션

설치를 완료하려면 새 버전 라벨로 네임스페이스에 라벨을 지정하고 워크로드를 다시 시작해야 합니다.

1. 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

   1. 출력의 REV 열에서 새 버전에 대한 버전 라벨 값을 확인합니다. 이 예시에서 값은 asm-11910-9-meshca-ca-migration입니다.

   2. 또한 이전 istiod 버전의 버전 라벨 값을 기록해 두세요. 워크로드를 새 버전으로 이동하고 나면 istiod의 이전 버전을 삭제할 때 필요합니다. 예시에서 이전 버전의 버전 라벨 값은 asm-11910-9-distribute-root입니다.

2. 네임스페이스에 새 버전 라벨을 추가합니다. 다음 명령어에서 NAMESPACE를 라벨의 네임스페이스로 바꾸세요.

   kubectl label namespace NAMESPACE istio.io/rev=REVISION_2 --overwrite
   

3. 포드를 다시 시작하여 재삽입을 트리거합니다.

   kubectl rollout restart deployment -n NAMESPACE
   

4. 애플리케이션을 테스트하여 워크로드가 올바르게 작동하는지 확인합니다. 이전 네임스페이스의 워크로드와 새 네임스페이스의 워크로드 사이에 mTLS 통신이 작동하는지 확인합니다.

5. 다른 네임스페이스에 워크로드가 있으면 단계를 반복하여 네임스페이스에 라벨을 지정하고 포드를 다시 시작합니다.

6. 인플레이스(In-Place) 업그레이드에 설명된 단계에 따라 이전 섹션의 11단계에서 설치된 이전 게이트웨이 배포를 최신 버전 REVISION_2로 업그레이드합니다.

7. 애플리케이션이 예상대로 만족스럽게 작동한다면 계속해서 남은 단계를 진행하여 의 새 컨트롤 플레인으로 전환합니다. 애플리케이션에 문제가 있는 경우 롤백 단계를 따르세요.

   전환 완료

   애플리케이션이 예상 대로 작동하여 만족스러우면 이전 컨트롤 플레인을 삭제하여 새 버전으로의 변환을 완료합니다.

   1. anthos-service-mesh GitHub 저장소의 파일이 있는 디렉터리로 변경합니다.

   2. 새 컨트롤 플레인을 사용하도록 검증 웹훅을 구성합니다.

      kubectl apply -f asm/istio/istiod-service.yaml
      

   3. 이전 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
      

   4. 이전 istiod 버전을 삭제합니다. 다음 명령어에서 OLD_REVISION을 istiod의 이전 버전 라벨로 바꿉니다.

      kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-OLD_REVISION -n istio-system --ignore-not-found=true
      

   5. 이전 IstioOperator 구성을 삭제합니다.

      kubectl delete IstioOperator installed-state-OLD_REVISION -n istio-system
      

      출력은 다음과 비슷합니다.

      istiooperator.install.istio.io "installed-state-OLD_REVISION" deleted

   롤백

   새 istiod 버전으로 애플리케이션을 테스트할 때 문제가 발생하면 다음 단계에 따라 이전 버전으로 롤백합니다.

   1. 인플레이스(In-Place) 업그레이드의 단계에 따라 이전에 이 섹션의 6단계에서 업그레이드된 게이트웨이 배포를 이전 버전 REVISION_1로 다운그레이드합니다.

   2. 네임스페이스의 라벨을 변경하여 이전 istiod 버전으로 자동 삽입을 사용 설정합니다.

      kubectl label namespace NAMESPACE istio.io/rev=OLD_REVISION --overwrite
      

      예상 출력:

      namespace/NAMESPACE labeled

   3. 네임스페이스의 버전 라벨이 이전 버전 istiod의 버전 라벨과 일치하는지 확인합니다.

      kubectl get ns NAMESPACE --show-labels
      

   4. 프록시에 이전 버전이 지정되도록 재삽입을 트리거하는 포드를 다시 시작합니다.

      kubectl rollout restart deployment -n NAMESPACE
      

   5. 새로운 istio-ingressgateway 배포를 삭제합니다.

      kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=REVISION_2 -n istio-system --ignore-not-found=true
      

   6. istiod의 새 버전을 삭제합니다. 다음 명령어의 버전 라벨이 본인의 버전과 일치하는지 확인합니다.

      kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-REVISION_2 -n istio-system --ignore-not-found=true
      

   7. IstioOperator 구성의 새 버전을 삭제합니다.

      kubectl delete IstioOperator installed-state-REVISION_2 -n istio-system
      

      예상 출력은 다음과 비슷합니다.

      istiooperator.install.istio.io "installed-state-REVISION_2" deleted

CA 보안 비밀을 삭제하고 새 컨트롤 플레인을 다시 시작

1. 필요할 때를 위해 보안 비밀을 따로 기록해 둡니다.

   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
   

2. 이전 CA와 연결된 클러스터에서 CA 보안 비밀을 삭제합니다.

   kubectl delete secret cacerts istio-ca-secret -n istio-system --ignore-not-found
   

3. 새로 설치된 컨트롤 플레인을 다시 시작합니다. 이렇게 하면 메시에서 실행되는 모든 워크로드에서 이전 신뢰할 수 있는 루트가 삭제됩니다.

   kubectl rollout restart deployment -n istio-system