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 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 신뢰할 수 있는 루트를 배포합니다.
1. Mesh 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 신뢰할 수 있는 루트를 배포하는 옵션을 사용하여 제어 영역 버전을 설치합니다.

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-1118-4). 이 옵션을 포함하고 REVISION_1을 설치를 설명하는 이름(예: asm-1118-4-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-1118-4-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.11/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-1118-4-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 라벨 삭제가 포함됩니다.
포드를 다시 시작하여 재삽입을 트리거합니다.
```
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]
```
애플리케이션이 예상대로 만족스럽게 작동한다면 계속해서 남은 단계를 진행하여 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. 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"}]'
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