Anthos Service Mesh 업그레이드

이 페이지에서는 다음 방법을 설명합니다.

• asmcli를 실행하여 Anthos Service Mesh에서 Anthos Service Mesh 1.12.9으로 업그레이드합니다.

• 원하는 경우 인그레스 게이트웨이를 배포합니다.

• 워크로드를 새 제어 영역으로 마이그레이션하기 위해 카나리아 업그레이드를 수행합니다.

업그레이드할 수 있는 Anthos Service Mesh 버전은 플랫폼에 따라 다릅니다.

GKE

다음 버전에서 Google Kubernetes Engine의 Anthos Service Mesh 1.12.9-asm.3으로 직접 업그레이드할 수 있습니다.

1.10+

온프레미스

다음 버전에서 VMware용 GKE 및 베어메탈용 Google Distributed Cloud Virtual의 Anthos Service Mesh 1.12.9-asm.3으로 직접 업그레이드할 수 있습니다.

1.10+

AWS 기반 GKE

다음 버전에서 AWS 기반 GKE의 Anthos Service Mesh 1.12.9-asm.3으로 직접 업그레이드할 수 있습니다.

1.10+

Amazon EKS

EKS에 Anthos Service Mesh 1.7이 설치되어 있으면 새 클러스터에 Anthos Service Mesh 1.12을 설치해야 합니다. Anthos Service Mesh 1.7에서 Anthos Service Mesh 1.12으로의 업그레이드는 지원되지 않습니다.

Microsoft AKS

AKS에 Anthos Service Mesh 1.7이 설치되어 있으면 새 클러스터에 Anthos Service Mesh 1.12을 설치해야 합니다. Anthos Service Mesh 1.7에서 Anthos Service Mesh 1.12으로의 업그레이드는 지원되지 않습니다.

시작하기 전에

시작하기 전에 다음 작업을 수행합니다.

• 기본 요건 검토
• 업그레이드 계획의 정보 검토
• 필수 도구 설치.
• asmcli를 다운로드합니다.
• 클러스터에 관리자 권한 부여
• 프로젝트 및 클러스터 검증

제어 영역 맞춤설정

이전 설치를 맞춤설정한 경우 새 Anthos Service Mesh 버전으로 업그레이드하거나 Istio에서 마이그레이션할 때 동일한 맞춤설정이 필요합니다. --set values 플래그를 istioctl install에 추가하여 설치를 맞춤설정한 경우 오버레이 파일이라고 부르는 IstioOperator YAML 파일에 이러한 설정을 추가해야 합니다. 스크립트를 실행할 때 해당 파일 이름으로 --custom_overlay 옵션을 사용해서 오버레이 파일을 지정합니다. 스크립트가 오버레이 파일을 istioctl install로 전달합니다.

주의: 오버레이 파일을 생략해도 설치가 성공합니다. 하지만 제어 영역 및 인그레스 게이트웨이가 다시 배포될 때 생략된 값이 기본값으로 재설정되기 때문에 서비스 메시에 의도한 것과 다른 구성이 포함됩니다.

인증 기관

업그레이드 동안 인증 기관(CA)을 변경하면 다운타임이 발생합니다. 업그레이드 동안에는 모든 워크로드가 새로운 CA와 함께 새 제어 영역을 사용하도록 전환될 때까지 mTLS 트래픽이 중단됩니다.

Anthos Service Mesh 업그레이드

아래에서는 Anthos Service Mesh를 업그레이드하는 방법을 설명합니다.

1. GKE에서 Anthos Service Mesh 인증 기관(Mesh CA)을 사용하는 멀티 클러스터 메시를 업그레이드하는 경우 업그레이드 중에 다운타임 없는 클러스터 간 부하 분산을 위해 asmcli create-mesh를 실행하여 Fleet 워크로드 아이덴티티를 신뢰하도록 멀티 클러스터 메시를 구성합니다.

2. asmcli install을 실행하여 단일 클러스터에 Anthos Service Mesh를 설치합니다. 명령줄 예시는 다음 섹션을 참조하세요. 이 예시에는 필수 인수와 유용할 수 있는 선택적인 인수가 모두 포함되어 있습니다. 샘플 게이트웨이 및 istioctl과 같은 도구를 쉽게 찾을 수 있도록 항상 output_dir 인수를 지정하는 것이 좋습니다. 예시 목록은 오른쪽 탐색 막대를 참조하세요.

3. 선택적으로 인그레스 게이트웨이를 설치하거나 업그레이드합니다. 기본적으로 asmcli는 istio-ingressgateway를 설치하지 않습니다. 제어 영역과 게이트웨이를 개별적으로 배포하고 관리하는 것이 좋습니다. 클러스터 내 제어 영역과 함께 기본 istio-ingressgateway를 설치해야 하는 경우에는 --option legacy-default-ingressgateway 인수를 포함합니다.

4. Anthos Service Mesh 설정을 완료하려면 자동 사이드카 주입을 사용 설정하고 워크로드를 배포 또는 재배포해야 합니다.

Fleet 워크로드 아이덴티티를 신뢰하도록 멀티 클러스터 메시 구성

GKE에서 Mesh CA를 인증 기관으로 사용하는 멀티 클러스터 메시를 업그레이드하는 경우 각 클러스터를 업그레이드하기 전에 asmcli create-mesh를 실행해야 합니다. 이 명령어는 업그레이드 후 Fleet 워크로드 아이덴티티 풀 FLEET_PROJECT_ID.svc.id.goog를 트러스트 도메인으로 사용하도록 Mesh CA를 구성합니다. asmcli create-mesh 명령어:

• 모든 클러스터를 동일한 Fleet에 등록합니다.
• Fleet 워크로드 아이덴티티를 신뢰하도록 메시를 구성합니다.
• 원격 보안 비밀을 만듭니다.

각 클러스터에 대한 URI 또는 kubeconfig 파일 경로를 지정할 수 있습니다.

클러스터 URI

다음 명령어에서 FLEET_PROJECT_ID를 Fleet 호스트 프로젝트의 프로젝트 ID로 바꾸고 클러스터 URI를 각 클러스터의 클러스터 이름, 영역 또는 리전, 프로젝트 ID로 바꿉니다.

./asmcli create-mesh \
    FLEET_PROJECT_ID \
    PROJECT_ID_1/CLUSTER_LOCATION_1/CLUSTER_NAME_1 \
    PROJECT_ID_2/CLUSTER_LOCATION_2/CLUSTER_NAME_2 # \
    # Add a line for each cluster in the mesh

kubeconfig 파일

다음 명령어에서 FLEET_PROJECT_ID를 Fleet 호스트 프로젝트의 프로젝트 ID로, PATH_TO_KUBECONFIG를 각 kubeconfig 파일 경로로 바꿉니다.

./asmcli create-mesh \
    FLEET_PROJECT_ID \
    PATH_TO_KUBECONFIG_1 \
    PATH_TO_KUBECONFIG_2 # \
    # Add a line for each cluster in the mesh

기본 기능 및 Mesh CA로 업그레이드

이 섹션에서는 asmcli를 실행하여 플랫폼에 지원되는 기본 기능을 포함한 Anthos Service Mesh를 업그레이드하고 Anthos Service Mesh 인증 기관(Mesh CA)을 인증 기관으로 사용 설정하는 방법을 보여줍니다.

플랫폼 참고 사항: Mesh CA는 AWS용 GKE, Amazon EKS 또는 Microsoft AKS에서 지원되지 않습니다. 이러한 플랫폼에서 asmcli install을 실행하고 --ca mesh_ca를 지정하면 설치가 실패합니다.

GKE

다음 명령어를 실행하여 기본 기능 및 Mesh CA를 사용하는 제어 영역을 업그레이드합니다. 제공된 자리표시자에 값을 입력합니다.

./asmcli install \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --fleet_id FLEET_PROJECT_ID \
  --output_dir DIR_PATH \
  --enable_all \
  --ca mesh_ca

• --project_id, --cluster_name, --cluster_location: 클러스터가 있는 프로젝트 ID, 클러스터 이름, 클러스터 영역 또는 리전을 지정합니다.
• --fleet_id: Fleet 호스트 프로젝트의 프로젝트 ID입니다. 이 옵션을 포함하지 않으면 asmcli에서 클러스터를 등록할 때 클러스터가 생성된 프로젝트를 사용합니다.
• --output_dir asmcli가 anthos-service-mesh 패키지를 다운로드하고 설치 파일을 추출하며, istioctl, 샘플, 매니페스트가 포함되는 디렉터리를 지정하려면 이 옵션을 포함합니다. 그렇지 않으면 asmcli가 파일을 tmp 디렉터리에 다운로드합니다. 상대 경로 또는 전체 경로를 지정할 수 있습니다. 여기서는 환경 변수 $PWD가 작동하지 않습니다.
참고: 이 --output_dir 디렉터리를 기록해 둡니다. 게이트웨이를 배포할 때 이 디렉터리를 참조해야 합니다.
• --enable_all: 스크립트의 다음 작업을 허용합니다.
  • 필요한 IAM 권한을 부여합니다.
  • 필요한 Google API를 사용 설정합니다.
  • 메시를 식별하는 라벨을 클러스터에 설정합니다.
  • 아직 등록되지 않은 경우 Fleet에 클러스터를 등록합니다.
• --ca mesh_ca: Mesh CA를 인증 기관으로 사용합니다. 업그레이드 중에 인증 기관을 변경하면 다운타임이 발생합니다. asmcli는 Fleet 워크로드 아이덴티티를 사용하도록 Mesh CA를 구성합니다.

온프레미스

VMware용 GKE 또는 베어메탈용 Google Distributed Cloud Virtual에서 다음 명령어를 실행하여 기본 기능과 Mesh CA를 사용하는 제어 영역을 업그레이드합니다. 제공된 자리표시자에 값을 입력합니다.

1. 현재 컨텍스트를 사용자 클러스터로 전환합니다.

   kubectl config use-context CLUSTER_NAME
   

2. asmcli install을 실행합니다.

   ./asmcli install \
     --fleet_id FLEET_PROJECT_ID \
     --kubeconfig KUBECONFIG_FILE \
     --output_dir DIR_PATH \
     --platform multicloud \
     --enable_all \
     --ca mesh_ca
   

   • --fleet_id: Fleet 호스트 프로젝트의 프로젝트 ID입니다.
   • --kubeconfig kubeconfig 파일의 전체 경로입니다. 여기서 환경 변수 $PWD는 작동하지 않습니다.
   • --output_dir asmcli가 anthos-service-mesh 패키지를 다운로드하고 설치 파일을 추출하며, istioctl, 샘플, 매니페스트가 포함되는 디렉터리를 지정하려면 이 옵션을 포함합니다. 그렇지 않으면 asmcli가 파일을 tmp 디렉터리에 다운로드합니다. 상대 경로 또는 전체 경로를 지정할 수 있습니다. 여기서는 환경 변수 $PWD가 작동하지 않습니다. 또한 `~` 를 사용하는 상대 kubeconfig 파일 위치는 작동하지 않습니다.
   • --platform multicloud: 온프레미스가 플랫폼임을 지정합니다.
   • --enable_all: 스크립트의 다음 작업을 허용합니다.
     • 필요한 IAM 권한을 부여합니다.
     • 필요한 Google API를 사용 설정합니다.
     • 메시를 식별하는 라벨을 클러스터에 설정합니다.
     • 아직 등록되지 않은 경우 Fleet에 클러스터를 등록합니다.
   • --ca mesh_ca: Mesh CA를 인증 기관으로 사용합니다. 업그레이드 동안 인증 기관을 변경하면 다운타임이 발생합니다. asmcli는 Fleet 워크로드 아이덴티티를 사용하도록 Mesh CA를 구성합니다.

CA 서비스로 기본 기능 업그레이드

이 섹션에서는 asmcli를 실행하여 플랫폼에서 기본 지원되는 기능으로 Anthos Service Mesh를 업그레이드하고 Certificate Authority Service를 사용 설정하는 방법을 보여줍니다.

GKE

다음 명령어를 실행하여 기본 기능과 Certificate Authority Service가 있는 제어 영역을 설치합니다. 제공된 자리표시자에 값을 입력합니다.

./asmcli install \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --fleet_id FLEET_PROJECT_ID \
  --output_dir DIR_PATH \
  --enable_all \
  --ca gcp_cas \
  --ca_pool projects/PROJECT_NAME/locations/ca_region/caPools/CA_POOL

• --project_id, --cluster_name, --cluster_location: 클러스터가 있는 프로젝트 ID, 클러스터 이름, 클러스터 영역 또는 리전을 지정합니다.
• --fleet_id: Fleet 호스트 프로젝트의 프로젝트 ID입니다. 이 옵션을 포함하지 않으면 asmcli에서 클러스터를 등록할 때 클러스터가 생성된 프로젝트를 사용합니다.
• --output_dir asmcli가 anthos-service-mesh 패키지를 다운로드하고 설치 파일을 추출하며, istioctl, 샘플, 매니페스트가 포함되는 디렉터리를 지정하려면 이 옵션을 포함합니다. 그렇지 않으면 asmcli가 파일을 tmp 디렉터리에 다운로드합니다. 상대 경로 또는 전체 경로를 지정할 수 있습니다. 여기서는 환경 변수 $PWD가 작동하지 않습니다.
참고: 이 --output_dir 디렉터리를 기록해 둡니다. 게이트웨이를 배포할 때 이 디렉터리를 참조해야 합니다.
• --enable_all: 스크립트의 다음 작업을 허용합니다.
  • 필요한 IAM 권한을 부여합니다.
  • 필요한 Google API를 사용 설정합니다.
  • 메시를 식별하는 라벨을 클러스터에 설정합니다.
  • 아직 등록되지 않은 경우 Fleet에 클러스터를 등록합니다.
• --ca gcp_cas Certificate Authority Service를 인증 기관으로 사용합니다. 업그레이드 중에 인증 기관을 변경하면 다운타임이 발생합니다. asmcli는 Fleet 워크로드 아이덴티티를 사용하도록 Certificate Authority Service를 구성합니다.
• --ca_pool Certificate Authority Service CA 풀의 전체 식별자입니다.

온프레미스

VMware용 GKE 또는 베어메탈용 Google Distributed Cloud Virtual에서 다음 명령어를 실행하여 기본 기능과 Certificate Authority Service를 사용하는 제어 영역을 업그레이드합니다. 제공된 자리표시자에 값을 입력합니다.

1. 현재 컨텍스트를 사용자 클러스터로 전환합니다.

   kubectl config use-context CLUSTER_NAME
   

2. asmcli install을 실행합니다.

   ./asmcli install \
    --kubeconfig KUBECONFIG_FILE \
    --fleet_id FLEET_PROJECT_ID \
    --output_dir DIR_PATH \
    --enable_all \
    --ca gcp_cas \
    --platform multicloud \
    --ca_pool projects/PROJECT_NAME/locations/ca_region/caPools/CA_POOL
   

   • --fleet_id: Fleet 호스트 프로젝트의 프로젝트 ID입니다.
   • --kubeconfig kubeconfig 파일의 전체 경로입니다. 여기서 환경 변수 $PWD는 작동하지 않습니다.
   • --output_dir asmcli가 anthos-service-mesh 패키지를 다운로드하고 설치 파일을 추출하며, istioctl, 샘플, 매니페스트가 포함되는 디렉터리를 지정하려면 이 옵션을 포함합니다. 그렇지 않으면 asmcli가 파일을 tmp 디렉터리에 다운로드합니다. 상대 경로 또는 전체 경로를 지정할 수 있습니다. 여기서는 환경 변수 $PWD가 작동하지 않습니다. 또한 `~` 를 사용하는 상대 kubeconfig 파일 위치는 작동하지 않습니다.
   • --platform multicloud: 온프레미스가 플랫폼임을 지정합니다.
   • --enable_all: 스크립트의 다음 작업을 허용합니다.
     • 필요한 IAM 권한을 부여합니다.
     • 필요한 Google API를 사용 설정합니다.
     • 메시를 식별하는 라벨을 클러스터에 설정합니다.
     • 아직 등록되지 않은 경우 Fleet에 클러스터를 등록합니다.
   • --ca gcp_cas Certificate Authority Service를 인증 기관으로 사용합니다. 업그레이드 중에 인증 기관을 변경하면 다운타임이 발생합니다. asmcli는 Fleet 워크로드 아이덴티티를 사용하도록 Certificate Authority Service를 구성합니다.
   • --ca_pool Certificate Authority Service CA 풀의 전체 식별자입니다.

Istio CA로 기본 기능 업그레이드

이 섹션에서는 asmcli를 실행하여 플랫폼에서 지원되는 기본 기능으로 Anthos Service Mesh를 업그레이드하고 Istio CA를 사용 설정하는 방법을 보여줍니다.

GKE

다음 명령어를 실행하여 기본 기능 및 Istio CA를 사용하는 제어 영역을 업그레이드합니다. 제공된 자리표시자에 값을 입력합니다.

./asmcli install \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --fleet_id FLEET_PROJECT_ID \
  --output_dir DIR_PATH \
  --enable_all \
  --ca citadel

• --project_id, --cluster_name, --cluster_location: 클러스터가 있는 프로젝트 ID, 클러스터 이름, 클러스터 영역 또는 리전을 지정합니다.
• --fleet_id: Fleet 호스트 프로젝트의 프로젝트 ID입니다. 이 옵션을 포함하지 않으면 asmcli에서 클러스터를 등록할 때 클러스터가 생성된 프로젝트를 사용합니다.
• --output_dir asmcli가 anthos-service-mesh 패키지를 다운로드하고 설치 파일을 추출하며, istioctl, 샘플, 매니페스트가 포함되는 디렉터리를 지정하려면 이 옵션을 포함합니다. 그렇지 않으면 asmcli가 파일을 tmp 디렉터리에 다운로드합니다. 상대 경로 또는 전체 경로를 지정할 수 있습니다. 여기서는 환경 변수 $PWD가 작동하지 않습니다.
참고: 이 --output_dir 디렉터리를 기록해 둡니다. 게이트웨이를 배포할 때 이 디렉터리를 참조해야 합니다.
• --enable_all: 스크립트의 다음 작업을 허용합니다.
  • 필요한 IAM 권한을 부여합니다.
  • 필요한 Google API를 사용 설정합니다.
  • 메시를 식별하는 라벨을 클러스터에 설정합니다.
  • 아직 등록되지 않은 경우 Fleet에 클러스터를 등록합니다.
• -ca citadel Istio CA를 사용합니다. 업그레이드 동안 인증 기관을 변경하면 다운타임이 발생합니다.

온프레미스

VMware용 GKE 또는 베어메탈용 Google Distributed Cloud Virtual에서 다음 명령어를 실행하여 기본 기능과 Istio CA를 사용하는 제어 영역을 업그레이드합니다. 제공된 자리표시자에 값을 입력합니다.

1. 현재 컨텍스트를 사용자 클러스터로 전환합니다.

   kubectl config use-context CLUSTER_NAME
   

2. asmcli install을 실행합니다.

   ./asmcli install \
     --fleet_id FLEET_PROJECT_ID \
     --kubeconfig KUBECONFIG_FILE \
     --output_dir DIR_PATH \
     --platform multicloud \
     --enable_all \
     --ca citadel \
     --ca_cert FILE_PATH \
     --ca_key FILE_PATH \
     --root_cert FILE_PATH \
     --cert_chain FILE_PATH
   

   • --fleet_id: Fleet 호스트 프로젝트의 프로젝트 ID입니다.
   • --kubeconfig kubeconfig 파일의 전체 경로입니다. 여기서 환경 변수 $PWD는 작동하지 않습니다.
   • --output_dir asmcli가 anthos-service-mesh 패키지를 다운로드하고 설치 파일을 추출하며, istioctl, 샘플, 매니페스트가 포함되는 디렉터리를 지정하려면 이 옵션을 포함합니다. 그렇지 않으면 asmcli가 파일을 tmp 디렉터리에 다운로드합니다. 상대 경로 또는 전체 경로를 지정할 수 있습니다. 여기서는 환경 변수 $PWD가 작동하지 않습니다. 또한 `~` 를 사용하는 상대 kubeconfig 파일 위치는 작동하지 않습니다.
   • --platform multicloud: 온프레미스가 플랫폼임을 지정합니다.
   • --enable_all: 스크립트의 다음 작업을 허용합니다.
     • 필요한 IAM 권한을 부여합니다.
     • 필요한 Google API를 사용 설정합니다.
     • 메시를 식별하는 라벨을 클러스터에 설정합니다.
     • 아직 등록되지 않은 경우 Fleet에 클러스터를 등록합니다.
   • -ca citadel: Istio CA를 인증 기관으로 사용
   • --ca_cert: 중간 인증서
   • --ca_key: 중간 인증서의 키
   • --root_cert: 루트 인증서
   • --cert_chain: 인증서 체인

AWS

GKE on AWS에서 다음 명령어를 실행하여 기본 기능과 Istio CA를 사용하는 제어 영역을 업그레이드합니다. 제공된 자리표시자에 값을 입력합니다. 공개 서브넷 또는 비공개 서브넷에 대해 인그레스를 사용 설정하는 방법을 선택할 수 있습니다.

공개

1. 현재 컨텍스트를 사용자 클러스터로 전환합니다.

   kubectl config use-context CLUSTER_NAME
   

2. asmcli install을 실행합니다.

   ./asmcli install \
     --fleet_id FLEET_PROJECT_ID \
     --kubeconfig KUBECONFIG_FILE \
     --output_dir DIR_PATH \
     --platform multicloud \
     --enable_all \
     --ca citadel \
     --ca_cert FILE_PATH \
     --ca_key FILE_PATH \
     --root_cert FILE_PATH \
     --cert_chain FILE_PATH
   

   • --fleet_id: Fleet 호스트 프로젝트의 프로젝트 ID입니다.
   • --kubeconfig kubeconfig 파일의 전체 경로입니다. 여기서 환경 변수 $PWD는 작동하지 않습니다.
   • --output_dir asmcli가 anthos-service-mesh 패키지를 다운로드하고 설치 파일을 추출하며, istioctl, 샘플, 매니페스트가 포함되는 디렉터리를 지정하려면 이 옵션을 포함합니다. 그렇지 않으면 asmcli가 파일을 tmp 디렉터리에 다운로드합니다. 상대 경로 또는 전체 경로를 지정할 수 있습니다. 여기서는 환경 변수 $PWD가 작동하지 않습니다. 또한 `~` 를 사용하는 상대 kubeconfig 파일 위치는 작동하지 않습니다.
   • --platform multicloud: 온프레미스가 플랫폼임을 지정합니다.
   • --enable_all: 스크립트의 다음 작업을 허용합니다.
     • 필요한 IAM 권한을 부여합니다.
     • 필요한 Google API를 사용 설정합니다.
     • 메시를 식별하는 라벨을 클러스터에 설정합니다.
     • 아직 등록되지 않은 경우 Fleet에 클러스터를 등록합니다.
   • -ca citadel: Istio CA를 인증 기관으로 사용
   • --ca_cert: 중간 인증서
   • --ca_key: 중간 인증서의 키
   • --root_cert: 루트 인증서
   • --cert_chain: 인증서 체인

비공개

1. 현재 컨텍스트를 사용자 클러스터로 전환합니다.

   kubectl config use-context CLUSTER_NAME
   

2. 다음 YAML을 istio-operator-internal-lb.yaml 파일에 저장합니다.

   apiVersion: install.istio.io/v1alpha1
   kind: IstioOperator
   spec:
     components:
       ingressGateways:
       - enabled: true
         k8s:
           serviceAnnotations:
             service.beta.kubernetes.io/aws-load-balancer-internal: "true"
         name: istio-ingressgateway
   

3. asmcli install을 실행합니다.

   ./asmcli install \
     --fleet_id FLEET_PROJECT_ID \
     --kubeconfig KUBECONFIG_FILE \
     --output_dir DIR_PATH \
     --platform multicloud \
     --enable_all \
     --ca citadel \
     --ca_cert FILE_PATH \
     --ca_key FILE_PATH \
     --root_cert FILE_PATH \
     --cert_chain FILE_PATH
     --custom_overlay istio-operator-internal-lb.yaml
   

   • --fleet_id: Fleet 호스트 프로젝트의 프로젝트 ID입니다.
   • --kubeconfig kubeconfig 파일의 전체 경로입니다. 여기서 환경 변수 $PWD는 작동하지 않습니다.
   • --output_dir asmcli가 anthos-service-mesh 패키지를 다운로드하고 설치 파일을 추출하며, istioctl, 샘플, 매니페스트가 포함되는 디렉터리를 지정하려면 이 옵션을 포함합니다. 그렇지 않으면 asmcli가 파일을 tmp 디렉터리에 다운로드합니다. 상대 경로 또는 전체 경로를 지정할 수 있습니다. 여기서는 환경 변수 $PWD가 작동하지 않습니다. 또한 `~` 를 사용하는 상대 kubeconfig 파일 위치는 작동하지 않습니다.
   • --platform multicloud: 온프레미스가 플랫폼임을 지정합니다.
   • --enable_all: 스크립트의 다음 작업을 허용합니다.
     • 필요한 IAM 권한을 부여합니다.
     • 필요한 Google API를 사용 설정합니다.
     • 메시를 식별하는 라벨을 클러스터에 설정합니다.
     • 아직 등록되지 않은 경우 Fleet에 클러스터를 등록합니다.
   • -ca citadel: Istio CA를 인증 기관으로 사용
   • --ca_cert: 중간 인증서
   • --ca_key: 중간 인증서의 키
   • --root_cert: 루트 인증서
   • --cert_chain: 인증서 체인

Amazon EKS

Amazon EKS에서 다음 명령어를 실행하여 기본 기능 및 Istio CA를 사용하는 제어 영역을 업그레이드합니다. 제공된 자리표시자에 값을 입력합니다.

플랫폼 관련 참고: EKS에 Anthos Service Mesh 1.7이 설치되어 있으면 새 클러스터에 Anthos Service Mesh 1.12을 설치해야 합니다. Anthos Service Mesh 1.7에서 Anthos Service Mesh 1.12으로의 업그레이드는 지원되지 않습니다.

1. 현재 컨텍스트를 사용자 클러스터로 전환합니다.

   kubectl config use-context CLUSTER_NAME
   

2. asmcli install을 실행합니다.

   ./asmcli install \
     --fleet_id FLEET_PROJECT_ID \
     --kubeconfig KUBECONFIG_FILE \
     --output_dir DIR_PATH \
     --platform multicloud \
     --enable_all \
     --ca citadel \
     --ca_cert FILE_PATH \
     --ca_key FILE_PATH \
     --root_cert FILE_PATH \
     --cert_chain FILE_PATH
   

   • --fleet_id: Fleet 호스트 프로젝트의 프로젝트 ID입니다.
   • --kubeconfig kubeconfig 파일의 전체 경로입니다. 여기서 환경 변수 $PWD는 작동하지 않습니다.
   • --output_dir asmcli가 anthos-service-mesh 패키지를 다운로드하고 설치 파일을 추출하며, istioctl, 샘플, 매니페스트가 포함되는 디렉터리를 지정하려면 이 옵션을 포함합니다. 그렇지 않으면 asmcli가 파일을 tmp 디렉터리에 다운로드합니다. 상대 경로 또는 전체 경로를 지정할 수 있습니다. 여기서는 환경 변수 $PWD가 작동하지 않습니다. 또한 `~` 를 사용하는 상대 kubeconfig 파일 위치는 작동하지 않습니다.
   • --platform multicloud: 온프레미스가 플랫폼임을 지정합니다.
   • --enable_all: 스크립트의 다음 작업을 허용합니다.
     • 필요한 IAM 권한을 부여합니다.
     • 필요한 Google API를 사용 설정합니다.
     • 메시를 식별하는 라벨을 클러스터에 설정합니다.
     • 아직 등록되지 않은 경우 Fleet에 클러스터를 등록합니다.
   • -ca citadel: Istio CA를 인증 기관으로 사용
   • --ca_cert: 중간 인증서
   • --ca_key: 중간 인증서의 키
   • --root_cert: 루트 인증서
   • --cert_chain: 인증서 체인

Microsoft AKS

Amazon EKS에서 다음 명령어를 실행하여 기본 기능 및 Istio CA를 사용하는 제어 영역을 업그레이드합니다. 제공된 자리표시자에 값을 입력합니다.

참고: AKS에 Anthos Service Mesh 1.7이 설치되어 있으면 새 클러스터에 Anthos Service Mesh 1.12을 설치해야 합니다. Anthos Service Mesh 1.7에서 Anthos Service Mesh 1.12으로의 업그레이드는 지원되지 않습니다.

1. 현재 컨텍스트를 사용자 클러스터로 전환합니다.

   kubectl config use-context CLUSTER_NAME
   

2. asmcli install을 실행합니다.

   HUB_REGISTRATION_EXTRA_FLAGS=--has-private-issuer ./asmcli install \
     --fleet_id FLEET_PROJECT_ID \
     --kubeconfig KUBECONFIG_FILE \
     --output_dir DIR_PATH \
     --platform multicloud \
     --enable_all \
     --ca citadel \
     --ca_cert FILE_PATH \
     --ca_key FILE_PATH \
     --root_cert FILE_PATH \
     --cert_chain FILE_PATH
   

   • --fleet_id: Fleet 호스트 프로젝트의 프로젝트 ID입니다.
   • --kubeconfig kubeconfig 파일의 전체 경로입니다. 여기서 환경 변수 $PWD는 작동하지 않습니다.
   • --output_dir asmcli가 anthos-service-mesh 패키지를 다운로드하고 설치 파일을 추출하며, istioctl, 샘플, 매니페스트가 포함되는 디렉터리를 지정하려면 이 옵션을 포함합니다. 그렇지 않으면 asmcli가 파일을 tmp 디렉터리에 다운로드합니다. 상대 경로 또는 전체 경로를 지정할 수 있습니다. 여기서는 환경 변수 $PWD가 작동하지 않습니다. 또한 `~` 를 사용하는 상대 kubeconfig 파일 위치는 작동하지 않습니다.
   • --platform multicloud: 온프레미스가 플랫폼임을 지정합니다.
   • --enable_all: 스크립트의 다음 작업을 허용합니다.
     • 필요한 IAM 권한을 부여합니다.
     • 필요한 Google API를 사용 설정합니다.
     • 메시를 식별하는 라벨을 클러스터에 설정합니다.
     • 아직 등록되지 않은 경우 Fleet에 클러스터를 등록합니다.
   • -ca citadel: Istio CA를 인증 기관으로 사용
   • --ca_cert: 중간 인증서
   • --ca_key: 중간 인증서의 키
   • --root_cert: 루트 인증서
   • --cert_chain: 인증서 체인

선택적 기능을 사용하여 업그레이드

오버레이 파일은 IstioOperator 커스텀 리소스(CR)를 포함하는 YAML 파일로 제어 영역을 구성하기 위해 asmcli에 전달합니다. 기본 제어 영역 구성을 재정의하고 YAML 파일을 asmcli에 전달하여 선택적 기능을 사용 설정할 수 있습니다. 오버레이를 더 많이 추가할 수 있으며, 각 오버레이 파일은 이전 레이어의 구성을 재정의합니다.

GKE

다음 명령어를 실행하여 선택적 기능으로 제어 영역을 설치합니다. 파일을 여러 개 추가하려면 --custom_overlay 및 파일 이름을 지정합니다(예: --custom_overlayoverlay_file1.yaml --custom_overlay overlay_file2.yaml --custom_overlay overlay_file3.yaml). 제공된 자리표시자에 값을 입력합니다.

./asmcli install \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --fleet_id FLEET_PROJECT_ID \
  --output_dir DIR_PATH \
  --enable_all \
  --ca mesh_ca \
  --custom_overlay OVERLAY_FILE

• --project_id, --cluster_name, --cluster_location: 클러스터가 있는 프로젝트 ID, 클러스터 이름, 클러스터 영역 또는 리전을 지정합니다.
• --fleet_id: Fleet 호스트 프로젝트의 프로젝트 ID입니다. 이 옵션을 포함하지 않으면 asmcli에서 클러스터를 등록할 때 클러스터가 생성된 프로젝트를 사용합니다.
• --output_dir asmcli가 anthos-service-mesh 패키지를 다운로드하고 설치 파일을 추출하며, istioctl, 샘플, 매니페스트가 포함되는 디렉터리를 지정하려면 이 옵션을 포함합니다. 그렇지 않으면 asmcli가 파일을 tmp 디렉터리에 다운로드합니다. 상대 경로 또는 전체 경로를 지정할 수 있습니다. 여기서는 환경 변수 $PWD가 작동하지 않습니다.
참고: 이 --output_dir 디렉터리를 기록해 둡니다. 게이트웨이를 배포할 때 이 디렉터리를 참조해야 합니다.
• --enable_all: 스크립트의 다음 작업을 허용합니다.
  • 필요한 IAM 권한을 부여합니다.
  • 필요한 Google API를 사용 설정합니다.
  • 메시를 식별하는 라벨을 클러스터에 설정합니다.
  • 아직 등록되지 않은 경우 Fleet에 클러스터를 등록합니다.
• --ca mesh_ca: Mesh CA를 인증 기관으로 사용합니다. 업그레이드 중에 인증 기관을 변경하면 다운타임이 발생합니다. asmcli는 Fleet 워크로드 아이덴티티를 사용하도록 Mesh CA를 구성합니다.
• --custom_overlay: 오버레이 파일의 이름을 지정합니다.

Google Cloud 외부

VMware용 GKE, 베어메탈용 Google Distributed Cloud Virtual, GKE on AWS, Amazon EKS 또는 Microsoft AKS에서 다음 명령어를 실행합니다. 제공된 자리표시자에 값을 입력합니다.

플랫폼 관련 참고: EKS에 Anthos Service Mesh 1.7이 설치되어 있으면 새 클러스터에 Anthos Service Mesh 1.12을 설치해야 합니다. Anthos Service Mesh 1.7에서 Anthos Service Mesh 1.12으로의 업그레이드는 지원되지 않습니다.

1. 현재 컨텍스트를 사용자 클러스터로 전환합니다.

   kubectl config use-context CLUSTER_NAME
   

2. asmcli install을 실행합니다.

   ./asmcli install \
     --fleet_id FLEET_PROJECT_ID \
     --kubeconfig KUBECONFIG_FILE \
     --output_dir DIR_PATH \
     --platform multicloud \
     --enable_all \
     --ca mesh_ca \
     --custom_overlay OVERLAY_FILE
   

   • --fleet_id: Fleet 호스트 프로젝트의 프로젝트 ID입니다.
   • --kubeconfig kubeconfig 파일의 전체 경로입니다. 여기서 환경 변수 $PWD는 작동하지 않습니다.
   • --output_dir asmcli가 anthos-service-mesh 패키지를 다운로드하고 설치 파일을 추출하며, istioctl, 샘플, 매니페스트가 포함되는 디렉터리를 지정하려면 이 옵션을 포함합니다. 그렇지 않으면 asmcli가 파일을 tmp 디렉터리에 다운로드합니다. 상대 경로 또는 전체 경로를 지정할 수 있습니다. 여기서는 환경 변수 $PWD가 작동하지 않습니다. 또한 `~` 를 사용하는 상대 kubeconfig 파일 위치는 작동하지 않습니다.
   • --platform multicloud: 온프레미스가 플랫폼임을 지정합니다.
   • --enable_all: 스크립트의 다음 작업을 허용합니다.
     • 필요한 IAM 권한을 부여합니다.
     • 필요한 Google API를 사용 설정합니다.
     • 메시를 식별하는 라벨을 클러스터에 설정합니다.
     • 아직 등록되지 않은 경우 Fleet에 클러스터를 등록합니다.
   • --ca mesh_ca: Mesh CA를 인증 기관으로 사용합니다. 업그레이드 중에 인증 기관을 변경하면 다운타임이 발생합니다. asmcli는 Fleet 워크로드 아이덴티티를 사용하도록 Mesh CA를 구성합니다.
   • --custom_overlay: 오버레이 파일의 이름을 지정합니다.

게이트웨이 업그레이드

게이트웨이가 배포되어 있는 경우에도 업그레이드해야 합니다. 간단한 업그레이드의 경우 게이트웨이 설치 및 업그레이드 가이드의 인플레이스(In-Place) 업그레이드 섹션을 따릅니다.

경고: asmcli가 아닌 다른 방법으로 Anthos Service Mesh를 설치한 경우, 설치된 기본 인그레스 게이트웨이는 --option legacy-default-ingressgateway 인수를 전달하지 않으면 삭제됩니다.

새 제어 영역으로 전환

1. istiod에 있는 버전 라벨을 가져옵니다.

   kubectl get pod -n istio-system -L istio.io/rev
   

   명령어 출력은 다음과 비슷합니다.

   NAME                                                 READY   STATUS    RESTARTS   AGE   REV
   istiod-asm-1129-3-67998f4b55-lrzpz           1/1     Running   0          68m   asm-1118-4
   istiod-asm-1129-3-67998f4b55-r76kr           1/1     Running   0          68m   asm-1118-4
   istiod-1128-2-1-5cd96f88f6-n7tj9    1/1     Running   0          27s   asm-1129-3
   istiod-1128-2-1-5cd96f88f6-wm68b    1/1     Running   0          27s   asm-1129-3

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

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

2. 애플리케이션 네임스페이스에 버전 라벨을 추가하고 istio-injection 라벨(있는 경우)을 삭제합니다. 다음 명령어에서 REVISION을 istiod의 새 버전과 일치하는 값으로 변경합니다.

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

   출력에 "istio-injection not found"가 표시되면 무시해도 됩니다. 이것은 이전에 네임스페이스에 istio-injection 라벨이 없음을 의미합니다. 네임스페이스에 istio-injection 및 버전 라벨이 모두 포함된 경우 자동 삽입이 실패하기 때문에 Anthos Service Mesh 문서에서 모든 kubectl label 명령어에는 istio-injection 라벨 삭제가 포함됩니다.

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

   kubectl rollout restart deployment -n NAMESPACE

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

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

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

   전환 완료

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

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

   2. 새 제어 영역을 사용하도록 검증 웹훅을 구성합니다.

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

   3. 기본 태그 이동:

      <OUTPUT_DIR>/istioctl tag set default --revision <NEW REVISION NAME>
      

   4. istiod의 이전 버전을 삭제합니다. 사용하는 명령어는 Istio에서 마이그레이션하는지 또는 이전 버전의 Anthos Service Mesh에서 업그레이드하는지에 따라 다릅니다.

      마이그레이션

      Istio에서 마이그레이션한 경우 이전 istio-ingressgateway에는 버전 라벨이 없습니다.

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

   업그레이드

   1. 이전 Anthos Service Mesh 버전에서 업그레이드한 경우 다음 명령어에서 OLD_REVISION이 이전 버전의 istiod에 대한 버전 라벨과 일치하는지 확인합니다.

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

   2. 이전 버전의 validatingwebhookconfiguration 리소스를 삭제합니다.

      kubectl delete validatingwebhookconfiguration istio-validator-OLD_REVISION-istio-system -n istio-system --ignore-not-found
      

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

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

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

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

   롤백

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

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

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

      kubectl get ns NAMESPACE --show-labels
      

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

      kubectl rollout restart deployment -n NAMESPACE
      

   4. istiod의 새 버전을 삭제합니다. 다음 명령어의 REVISION 값이 올바른지 확인합니다.

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

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

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

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

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

   6. --disable_canonical_service 플래그가 포함되지 않았으면 asmcli는 표준 서비스 컨트롤러를 사용 설정합니다. 사용 설정 상태로 두는 것이 좋지만 사용 중지해야 하는 경우 표준 서비스 컨트롤러 사용 설정 및 중지를 참조하세요.

   7. 게이트웨이가 배포되었으면 이전 버전의 istiod와 일치하도록 네임스페이스 또는 배포에서 버전 라벨을 변경합니다. 게이트웨이 설치 및 업그레이드 가이드에서 인플레이스 업그레이드 섹션에 설명된 동일한 프로세스를 따릅니다.

워크로드 배포 및 재배포

자동 사이드카 프록시 삽입(자동 삽입)을 사용 설정해야 설치(또는 업그레이드)가 완료됩니다. OSS Istio에서 마이그레이션 및 업그레이드는 버전 기반 업그레이드 프로세스(Istio 문서의 '카나리아 업그레이드')를 따릅니다. 버전 기반 업그레이드에서는 새 버전의 제어 영역이 기존 제어 영역과 함께 설치됩니다. 그런 후 일부 워크로드를 새 버전으로 이동하여, 모든 트래픽을 새 버전으로 마이그레이션 하기 전 워크로드 일부에서 업그레이드 효과를 모니터링합니다.

이 스크립트는 버전 라벨을 istio.io/rev=asm-1129-3 형식으로 istiod에 설정합니다. 자동 삽입을 사용 설정하려면 일치하는 버전 라벨을 네임스페이스에 추가합니다. 버전 라벨은 사이드카 인젝터 웹훅에서 삽입된 사이드카를 특정 istiod 버전과 연결하는 데 사용됩니다. 라벨을 추가한 후 사이드카를 삽입할 네임스페이스에서 pod를 다시 시작합니다.

1. istiod 및 istio-ingressgateway에 있는 버전 라벨을 가져옵니다.

   kubectl get pod -n istio-system -L istio.io/rev
   

   명령어 출력은 다음과 비슷합니다.

   NAME                                                READY   STATUS    RESTARTS   AGE   REV
   istio-ingressgateway-65d884685d-6hrdk               1/1     Running   0          67m
   istio-ingressgateway-65d884685d-94wgz               1/1     Running   0          67m
   istio-ingressgateway-asm-182-2-8b5fc8767-gk6hb      1/1     Running   0          5s    asm-1129-3
   istio-ingressgateway-asm-182-2-8b5fc8767-hn4w2      1/1     Running   0          20s   asm-1129-3
   istiod-asm-1129-3-67998f4b55-lrzpz          1/1     Running   0          68m   asm-1118-4
   istiod-asm-1129-3-67998f4b55-r76kr          1/1     Running   0          68m   asm-1118-4
   istiod-asm-1128-2-5cd96f88f6-n7tj9 1/1     Running   0          27s   asm-1129-3
   istiod-asm-1128-2-5cd96f88f6-wm68b 1/1     Running   0          27s   asm-1129-3

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

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

2. 네임스페이스에 버전 라벨을 추가하고 istio-injection 라벨을 삭제합니다(있는 경우). 다음 명령어에서 REVISION을 istiod의 새 버전과 일치하는 값으로 변경합니다.

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

   출력에 "istio-injection not found"가 표시되면 무시해도 됩니다. 이것은 이전에 네임스페이스에 istio-injection 라벨이 없음을 의미합니다. 네임스페이스에 istio-injection 및 버전 라벨이 모두 포함된 경우 자동 삽입이 실패하기 때문에 Anthos Service Mesh 문서에서 모든 kubectl label 명령어에는 istio-injection 라벨 삭제가 포함됩니다.

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

   kubectl rollout restart deployment -n NAMESPACE

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

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

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

   전환 완료

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

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

   2. 새 제어 영역을 사용하도록 검증 웹훅을 구성합니다.

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

   3. 기본 태그 이동.

      <OUTPUT_DIR>/istioctl tag set default --revision <NEW REVISION NAME>
      

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

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

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

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

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

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

   롤백

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

   1. istio-ingressgateway의 이전 버전으로 다시 전환합니다. 다음 명령어에서 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 배포를 삭제합니다. 다음 명령어의 REVISION 값이 올바른지 확인합니다.

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

   6. istiod의 새 버전을 삭제합니다. 다음 명령어의 REVISION 값이 올바른지 확인합니다.

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

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

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

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

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

   8. --disable_canonical_service 플래그가 포함되지 않았으면 스크립트는 표준 서비스 컨트롤러를 사용 설정합니다. 사용 설정 상태로 두는 것이 좋지만 사용 중지해야 하는 경우 표준 서비스 컨트롤러 사용 설정 및 중지를 참조하세요.