Istio CA(Citadel)에서 Anthos Service Mesh 인증 기관(Mesh CA)으로 마이그레이션하려면 신뢰할 수 있는 루트를 마이그레이션해야 합니다. Anthos Service Mesh 1.10 이전에는 Google Kubernetes Engine(GKE)의 Istio에서 Mesh CA가 있는 Anthos Service Mesh로 마이그레이션하려는 경우 Anthos Service Mesh에서 여러 루트 인증서 로드가 지원되지 않았기 때문에 다운타임을 예약해야 했습니다. 따라서 마이그레이션하는 동안 새로 배포된 워크로드에는 새 루트 인증서가 사용되고, 다른 워크로드에는 이전 루트 인증서가 사용되었습니다. 서로 다른 루트 인증서로 서명된 인증서를 사용하는 워크로드는 서로 인증할 수 없습니다. 즉, 마이그레이션하는 동안 상호 TLS(mTLS) 트래픽이 중단됩니다. 제어 영역과 모든 네임스페이스의 모든 워크로드가 Mesh CA의 인증서와 함께 다시 배포되는 경우에만 전체 클러스터가 완전히 복구됩니다. 다른 클러스터의 워크로드에 요청을 전송하는 워크로드와 함께 여러 클러스터가 메시에 포함된 경우 이러한 클러스터의 모든 워크로드도 함께 업데이트해야 합니다.
이 페이지에서는 최소한의 다운타임으로 또는 다운타임 없이 Istio CA에서 Mesh CA로 마이그레이션하는 방법을 설명합니다. 다음 사용 사례에 대해 이 가이드의 단계를 따르세요.
- GKE의 Istio 에서 Mesh CA가 있는 Anthos Service Mesh 1.10.6-asm.2 클러스터 내 제어 영역으로 마이그레이션하기
- Istio CA가 있는 Anthos Service Mesh 1.9 or a 1.10 patch release에서 Mesh CA가 있는 Anthos Service Mesh 1.10.6-asm.2 클러스터 내 제어 영역으로 업그레이드하기
제한사항
- Mesh CA는 GKE에서만 지원됩니다.
- 모든 GKE 클러스터는 동일한 Google Cloud 프로젝트에 있어야 합니다.
기본 요건
이 가이드에서는 다음 항목이 있다고 가정합니다.
- Google Cloud 프로젝트
- Cloud Billing 계정
install_asm
스크립트 실행에 필요한 도구- Istio CA를 사용하는 멀티 클러스터 메시의 경우 각 클러스터에 동일한 루트 인증서를 설정해야 함
필수 도구
마이그레이션 중에 Google에서 제공하는 스크립트인 migrate_ca
를 실행하여 클러스터의 각 포드에 대해 다음 사항을 확인합니다.
- Istio CA 및 Mesh CA의 루트 인증서
- Istio CA 및 Mesh CA에서 발급된 워크로드 mTLS 인증서
- Istio CA 및 Mesh CA에서 구성된 신뢰 도메인
이 스크립트의 종속 항목은 다음과 같습니다.
awk
grep
istioctl
install_asm
스크립트를 실행하면 설치 중인 Anthos Service Mesh 버전과 일치하는istioctl
버전을 다운로드합니다.jq
kubectl
openssl
마이그레이션 개요
Mesh CA로 마이그레이션하기 위해 버전 기반 마이그레이션 프로세스('카나리아 업그레이드'라고도 부름)를 따릅니다. 버전 기반 마이그레이션에서는 기존 제어 영역과 함께 새로운 제어 영역 버전이 배포됩니다. 그런 후 워크로드를 새 버전으로 점진적으로 이동하여, 프로세스를 진행하면서 마이그레이션의 효과를 모니터링할 수 있습니다. 마이그레이션 프로세스를 진행하는 동안 Mesh CA를 사용하는 워크로드와 Istio CA를 사용하는 워크로드 간에 인증 및 승인이 완전히 작동합니다.
다음은 Mesh CA로의 마이그레이션에 대한 개요입니다.
Mesh CA 신뢰할 수 있는 루트를 배포합니다.
Mesh CA 신뢰할 수 있는 루트를 배포하는 옵션을 사용하여 새 제어 영역 버전을 설치합니다.
네임스페이스별로 워크로드를 새로운 제어 영역으로 마이그레이션하고 애플리케이션을 테스트합니다. 모든 워크로드가 새 제어 영역으로 성공적으로 마이그레이션되었으면 이전 제어 영역을 삭제합니다.
Mesh CA로 마이그레이션합니다. 이제 모든 사이드카 프록시가 이전 신뢰할 수 있는 루트 및 Mesh CA 신뢰할 수 있는 루트로 구성되었으므로 다운타임 없이 Mesh CA로 마이그레이션할 수 있습니다. 다시 한 번 버전 기반 마이그레이션 프로세스를 따릅니다.
Mesh CA가 사용 설정된 제어 영역 버전을 설치합니다.
네임스페이스별로 워크로드를 새로운 제어 영역 버전으로 마이그레이션하고 애플리케이션을 테스트합니다. 모든 워크로드가 새 제어 영역으로 성공적으로 마이그레이션되었으면 이전 제어 영역을 삭제합니다.
이전 CA와 연결된 클러스터에서 CA 보안 비밀을 삭제하고 새 제어 영역을 다시 시작합니다.
Mesh CA 신뢰할 수 있는 루트 배포
Mesh CA로 마이그레이션하려면 메시의 모든 GKE 클러스터에 Anthos Service Mesh 1.10 이상이 있어야 하며, 모든 클러스터는 Mesh CA의 신뢰할 수 있는 루트가 클러스터에 있는 모든 워크로드의 프록시에 배포되도록 트리거하는 제어 영역 옵션으로 구성되어 있어야 합니다. 프로세스가 완료되면 각 프록시는 이전의 신뢰할 수 있는 루트와 새로운 신뢰할 수 있는 루트로 구성됩니다. 이 체계를 사용하면 Mesh CA로 마이그레이션할 때 Mesh CA를 사용하는 워크로드는 이전 CA를 사용하는 워크로드로 인증할 수 있습니다.
새 제어 영역 버전 설치
Mesh CA 신뢰할 수 있는 루트를 배포하는 옵션을 사용하여 제어 영역 버전을 설치합니다.
GKE에 Anthos Service Mesh 설치의 단계별 안내에 따라 Google 제공 스크립트
install_asm
를 사용하여 새 제어 영역 버전을 설치합니다.Anthos Service Mesh 1.10 이상을 설치하는
install_asm
버전을 보유하고 있는지 확인하세요../install_asm --version
install_asm
를 실행합니다. 다음 명령어에서 자리표시자를 원하는 값으로 바꿉니다.PROJECT_ID
: 필수. 클러스터가 생성된 프로젝트의 프로젝트 ID입니다.CLUSTER_NAME
: 필수. 클러스터의 이름입니다.CLUSTER_LOCATION
: 필수. 클러스터가 있는 영역 또는 리전입니다.REVISION_1
: 권장. 버전 라벨은 제어 영역에 설정된 키-값 쌍입니다. 버전 라벨 키는 항상istio.io/rev
입니다. 기본적으로 스크립트는 Anthos Service Mesh 버전을 기준으로 버전 라벨 값을 설정합니다(예:asm-1106-2
). 이 옵션을 포함하고REVISION_1
을 설치를 설명하는 이름(예:asm-1106-2-distribute-root
)으로 바꾸는 것이 좋습니다. 이름은 DNS-1035 라벨이어야 하고 소문자, 영숫자 문자 또는-
로 구성되어야 하며 영문자로 시작하고 영숫자 문자(예:my-name'
또는abc-123
)로 끝나야 합니다. 검증에 사용되는 정규식은'[a-z]([-a-z0-9]*[a-z0-9])?')
입니다.DIR_PATH
: 필수. 스크립트가anthos-service-mesh
패키지와istioctl
, 샘플, 메니페스트가 포함된 Anthos Service Mesh 설치 파일을 다운로드하는 디렉터리의 상대 경로입니다.OVERLAYS
: 선택사항. 원하는 선택 기능을 사용 설정하려면 각 기능에 해당하는 오버레이 파일 이름과 함께--custom_overlay
를 포함하세요. 선택 기능을 사용 설정하지 않는 경우 이 줄과 앞줄의 백슬래시를 삭제합니다../install_asm \ --project_id PROJECT_ID \ --cluster_name CLUSTER_NAME \ --cluster_location CLUSTER_LOCATION \ --mode install \ --ca citadel \ --enable_all \ --option ca-migration-citadel \ --revision_name REVISION_1 \ --output_dir DIR_PATH \ OVERLAYS
다음 명령줄 인수가 필요합니다.
--ca citadel
: 다운타임을 피하려면 Istio CA를 지정합니다(citadel
옵션은 Istio CA에 해당). 이 시점에서는 Mesh CA로 전환하지 마세요.--option ca-migration-citadel
: 워크로드를 재배포할 때 이 옵션은 새로운 신뢰할 수 있는 루트가 워크로드의 사이드카 프록시에 배포되도록 트리거합니다.
새 제어 영역으로 워크로드 마이그레이션
새 신뢰할 수 있는 루트의 배포를 완료하려면 버전 라벨 istio.io/rev=asm-1106-2-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/release-1.10-asm/scripts/ca-migration/migrate_ca > migrate_ca
스크립트에서 실행 가능한 비트를 설정합니다.
chmod +x migrate_ca
migrate_ca
스크립트는 버전에 따라 달라지는istioctl
을 호출합니다.install_asm
스크립트는--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
열에서 새 버전의 버전 라벨 값을 메모하세요. 이 값은install_asm
를 실행할 때 지정한 버전 라벨과 일치합니다. 이 예시에서 값은asm-1106-2-distribute-root
입니다.워크로드를 새 버전으로 이동한 후
istiod
의 이전 버전을 삭제해야 합니다. 이전istiod
버전의 버전 라벨 값을 기록합니다. 예시 출력에서는default
버전을 사용하는 Istio에서의 마이그레이션을 보여줍니다.
istio-ingressgateway
를 새 버전으로 전환합니다. 다음 명령어에서REVISION_1
이 새 버전의 버전 라벨의 값과 일치하는지 확인합니다.kubectl patch service -n istio-system istio-ingressgateway --type='json' -p='[{"op": "replace", "path": "/spec/selector/service.istio.io~1canonical-revision", "value": "REVISION_1"}]'
예상 출력:
service/istio-ingressgateway patched
네임스페이스에 버전 라벨을 추가하고
istio-injection
라벨을 삭제합니다(있는 경우). 다음 명령어에서NAMESPACE
를 라벨에 대한 네임스페이스로 바꿉니다.kubectl label namespace NAMESPACE istio.io/rev=REVISION_1 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_1
애플리케이션을 테스트하여 워크로드가 올바르게 작동하는지 확인합니다.
다른 네임스페이스에 워크로드가 있으면 단계를 반복하여 네임스페이스에 라벨을 지정하고 포드를 다시 시작합니다.
클러스터의 모든 워크로드에 대한 사이드카 프록시가 이전 및 새 루트 인증서를 모두 사용하여 구성되었는지 검증합니다.
./migrate_ca check-root-cert
예상 출력:
Namespace: foo httpbin-66cdbdb6c5-pmzps.foo trusts [CITADEL MESHCA] sleep-64d7d56698-6tmjm.foo trusts [CITADEL MESHCA]
애플리케이션이 예상대로 만족스럽게 작동한다면 계속해서 남은 단계를 진행하여
istiod
의 새 버전으로의 전환합니다. 애플리케이션에 문제가 있는 경우 롤백 단계를 따르세요.전환 완료
애플리케이션이 예상 대로 작동하여 만족스러우면 이전 제어 영역을 삭제하여 새 버전으로의 변환을 완료합니다.
anthos-service-mesh
GitHub 저장소의 파일이 있는 디렉터리로 변경합니다.새 제어 영역을 사용하도록 검증 웹훅을 구성합니다.
kubectl apply -f asm/istio/istiod-service.yaml
이전
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에서 마이그레이션한 경우 이전
istio-ingressgateway
에는 버전 라벨이 없습니다.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-ingressgatewqy
의 이전 버전으로 다시 전환합니다. 다음 명령어에서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"}]'
이전 버전의
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-1106-2-distribute-root -n istio-system
예상 출력은 다음과 비슷합니다.
istiooperator.install.istio.io "installed-state-asm-1106-2-distribute-root" deleted
Mesh CA로 마이그레이션
이제 모든 워크로드의 사이드카 프록시가 Mesh CA의 이전 신뢰 루트와 새 신뢰 루트로 구성되었으므로, Mesh CA로 마이그레이션하는 단계는 신뢰할 수 있는 Mesh CA 신뢰할 수 있는 루트를 배포할 때 밟은 단계와 비슷합니다.
Mesh CA가 사용 설정된 새 제어 영역 설치
install_asm
을 사용하여 Mesh CA가 사용 설정된 새 제어 영역 버전을 설치합니다.
이전 설치를 맞춤설정한 경우
install_asm
을 실행할 때 동일한 오버레이 파일을 지정해야 합니다.install_asm
를 실행합니다. 다음 명령어에서 자리표시자를 원하는 값으로 바꿉니다.PROJECT_ID
: 필수. 클러스터가 생성된 프로젝트의 프로젝트 ID입니다.CLUSTER_NAME
: 필수. 클러스터의 이름입니다.CLUSTER_LOCATION
: 필수. 클러스터가 있는 영역 또는 리전입니다.REVISION_2
: 권장.REVISION_2
를asm-1106-2-meshca-ca-migration
과 같이 설치를 설명하는 이름으로 바꿉니다. 이름은 DNS-1035 라벨이어야 하고 소문자, 영숫자 문자 또는-
로 구성되어야 하며 영문자로 시작하고 영숫자 문자(예:my-name'
또는abc-123
)로 끝나야 합니다. 검증에 사용되는 정규식은'[a-z]([-a-z0-9]*[a-z0-9])?')
입니다.DIR_PATH
: 필수. 스크립트가anthos-service-mesh
패키지와istioctl
, 샘플, 메니페스트가 포함된 Anthos Service Mesh 설치 파일을 다운로드하는 디렉터리의 상대 경로입니다.OVERLAYS
: 선택사항. 원하는 선택 기능을 사용 설정하려면 각 기능에 해당하는 오버레이 파일 이름과 함께--custom_overlay
를 포함하세요. 선택 기능을 사용 설정하지 않는 경우 이 줄과 앞줄의 백슬래시를 삭제합니다.
./install_asm \ --project_id PROJECT_ID \ --cluster_name CLUSTER_NAME \ --cluster_location CLUSTER_LOCATION \ --mode install \ --ca mesh_ca \ --enable_all \ --option ca-migration-meshca \ --revision_name REVISION_2 \ --output_dir DIR_PATH \ OVERLAYS
다음 명령줄 인수가 필요합니다.
--ca mesh_ca
: 이제 Mesh CA 신뢰할 수 있는 루트가 배포되었으므로 Mesh CA로 전환할 수 있습니다.--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-1106-2-distribute-root-65d884685d-6hrdk 1/1 Running 0 67m asm-1106-2-distribute-root istio-ingressgateway-asm-1106-2-distribute-root65d884685d-94wgz 1/1 Running 0 67m asm-1106-2-distribute-root istio-ingressgateway-asm-1106-2-meshca-ca-migration-8b5fc8767-gk6hb 1/1 Running 0 5s asm-1106-2-meshca-ca-migration istio-ingressgateway-asm-1106-2-meshca-ca-migration-8b5fc8767-hn4w2 1/1 Running 0 20s asm-1106-2-meshca-ca-migration istiod-asm-1106-2-distribute-root-67998f4b55-lrzpz 1/1 Running 0 68m asm-1106-2-distribute-root istiod-asm-1106-2-distribute-root-67998f4b55-r76kr 1/1 Running 0 68m asm-1106-2-distribute-root istiod-asm-1106-2-meshca-ca-migration-5cd96f88f6-n7tj9 1/1 Running 0 27s asm-1106-2-meshca-ca-migration istiod-asm-1106-2-meshca-ca-migration-5cd96f88f6-wm68b 1/1 Running 0 27s asm-1106-2-meshca-ca-migration
출력의
REV
열에서 새 버전에 대한 버전 라벨 값을 확인합니다. 이 예시에서 값은asm-1106-2-meshca-ca-migration
입니다.또한 이전
istiod
버전의 버전 라벨 값을 기록해 두세요. 워크로드를 새 버전으로 이동하고 나면istiod
의 이전 버전을 삭제할 때 필요합니다. 예시에서 이전 버전의 버전 라벨 값은asm-1106-2-distribute-root
입니다.
istio-ingressgateway
를 새 버전으로 전환합니다. 다음 명령어에서REVISION_2
을 새 버전의 버전 라벨과 일치하는 값으로 변경합니다.kubectl patch service -n istio-system istio-ingressgateway --type='json' -p='[{"op": "replace", "path": "/spec/selector/service.istio.io~1canonical-revision", "value": "REVISION_2"}]'
예상 출력:
service/istio-ingressgateway patched
네임스페이스에 새 버전 라벨을 추가합니다. 다음 명령어에서
NAMESPACE
를 라벨의 네임스페이스로 바꾸세요.kubectl label namespace NAMESPACE istio.io/rev=REVISION_2 --overwrite
pod를 다시 시작하여 재삽입을 트리거합니다.
kubectl rollout restart deployment -n NAMESPACE
pod가 새 버전의
istiod
를 가리키도록 구성되었는지 확인합니다.kubectl get pods -n NAMESPACE -l istio.io/rev=REVISION_2
애플리케이션을 테스트하여 워크로드가 올바르게 작동하는지 확인합니다. 이전 네임스페이스의 워크로드와 새 네임스페이스의 워크로드 사이에 mTLS 통신이 작동하는지 확인합니다.
다른 네임스페이스에 워크로드가 있으면 단계를 반복하여 네임스페이스에 라벨을 지정하고 포드를 다시 시작합니다.
애플리케이션이 예상대로 만족스럽게 작동한다면 계속해서 남은 단계를 진행하여 의 새 제어 영역으로 전환합니다. 애플리케이션에 문제가 있는 경우 롤백 단계를 따르세요.
전환 완료
애플리케이션이 예상 대로 작동하여 만족스러우면 이전 제어 영역을 삭제하여 새 버전으로의 변환을 완료합니다.
anthos-service-mesh
GitHub 저장소의 파일이 있는 디렉터리로 변경합니다.새 제어 영역을 사용하도록 검증 웹훅을 구성합니다.
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
버전으로 애플리케이션을 테스트할 때 문제가 발생하면 다음 단계에 따라 이전 버전으로 롤백합니다.이전
istio-ingressgatewqy
로 다시 전환합니다. 다음 명령어에서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"}]'
네임스페이스의 라벨을 변경하여 이전
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