Anthos Service Mesh 1.11은 지원 종료되어 더 이상 지원되지 않습니다. 이전 버전에서 업그레이드를 참조하세요.

최신 문서를 보거나 사용 가능한 다른 버전을 선택합니다.

사용 가능한 버전

Mesh CA로 마이그레이션

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.11.8-asm.4 클러스터 내 제어 영역으로 마이그레이션하기
Istio CA가 있는 Anthos Service Mesh 1.9 or a 1.10 patch release에서 Mesh CA가 있는 Anthos Service Mesh 1.11.8-asm.4 클러스터 내 제어 영역으로 업그레이드하기

제한사항

Mesh CA는 GKE에서만 지원됩니다.
모든 GKE 클러스터는 동일한 Google Cloud 프로젝트에 있어야 합니다.

기본 요건

시작하기의 단계에 따라 다음 작업을 수행하세요.

필수 도구

마이그레이션 중에 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 신뢰할 수 있는 루트를 배포합니다.
1. Mesh CA 신뢰할 수 있는 루트를 배포하는 옵션이 있는 Istio CA를 사용하여 새 제어 영역 버전을 설치합니다.
2. 네임스페이스별로 워크로드를 새로운 제어 영역으로 마이그레이션하고 애플리케이션을 테스트합니다. 모든 워크로드가 새 제어 영역으로 성공적으로 마이그레이션되었으면 이전 제어 영역을 삭제합니다.
Mesh CA로 마이그레이션합니다. 이제 모든 사이드카 프록시가 이전 신뢰할 수 있는 루트 및 Mesh CA 신뢰할 수 있는 루트로 구성되었으므로 다운타임 없이 Mesh CA로 마이그레이션할 수 있습니다. 다시 한 번 버전 기반 마이그레이션 프로세스를 따릅니다.
1. Mesh CA가 사용 설정된 제어 영역 버전을 설치합니다.
2. 네임스페이스별로 워크로드를 새로운 제어 영역 버전으로 마이그레이션하고 애플리케이션을 테스트합니다. 모든 워크로드가 새 제어 영역으로 성공적으로 마이그레이션되었으면 이전 제어 영역을 삭제합니다.
3. 이전 CA와 연결된 클러스터에서 CA 보안 비밀을 삭제하고 새 제어 영역을 다시 시작합니다.

Mesh CA 신뢰할 수 있는 루트 배포

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

새 제어 영역 버전 설치

Mesh CA 신뢰할 수 있는 루트를 배포하는 옵션을 사용하여 제어 영역 버전을 설치합니다.

시작하기의 단계를 수행하여 Google에서 제공하는 asmcli 도구로 새 제어 영역 버전을 설치합니다.
Anthos 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입니다. 기본적으로 도구는 Anthos Service Mesh 버전을 기준으로 버전 라벨 값을 설정합니다(예: asm-1118-4). 이 옵션을 포함하고 REVISION_1을 설치를 설명하는 이름(예: asm-1118-4-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-1118-4-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 및 버전 라벨이 모두 포함된 경우 자동 삽입이 실패하기 때문에 Anthos Service Mesh 문서에서 모든 kubectl label 명령어에는 istio-injection 라벨 삭제가 포함됩니다.
포드를 다시 시작하여 재삽입을 트리거합니다.
```
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의 새 버전으로의 전환합니다. 애플리케이션에 문제가 있는 경우 롤백 단계를 따르세요.
전환 완료
애플리케이션이 예상 대로 작동하여 만족스러우면 이전 제어 영역을 삭제하여 새 버전으로의 변환을 완료합니다.
1. anthos-service-mesh GitHub 저장소의 파일이 있는 디렉터리로 변경합니다.
2. 새 제어 영역을 사용하도록 검증 웹훅을 구성합니다.
  kubectl apply -f asm/istio/istiod-service.yaml
3. 이전 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
4. 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
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-1118-4-distribute-root -n istio-system
  예상 출력은 다음과 비슷합니다.
  istiooperator.install.istio.io "installed-state-asm-1118-4-distribute-root" deleted