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

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

사용 가능한 버전

GKE에서 Anthos Service Mesh 업그레이드

이 가이드에서는 GKE 기반 Anthos Service Mesh를 버전 1.5.4+ or 1.6.4+에서 버전 1.6.14로 업그레이드하는 방법을 설명합니다. Anthos Service Mesh 1.4.5+에서 업그레이드하려면 먼저 Anthos Service Mesh 1.5로 업그레이드해야 합니다. Anthos Service Mesh 1.4에서 1.6으로의 직접 업그레이드는 지원되지 않습니다.

업그레이드할 때 워크로드의 작은 부분으로 새 버전을 테스트하기 때문에 새 버전과 이전 버전의 컨트롤 영역이 모두 실행되는 이중 제어 영역 업그레이드(카나리아 업그레이드라고도 함)를 수행하는 것이 좋습니다. 이러한 접근 방식은 새 버전의 제어 영역이 이전 버전을 대체하는 인플레이스(In-Place) 업그레이드보다 안전합니다. istio-ingressgateway는 인플레이스(In-Place)로 업그레이드되므로 클러스터의 중단을 계획해야 합니다.

Anthos Service Mesh 제어 영역 구성요소를 다시 배포하려면 5~10분 정도 걸립니다. 또한 현재 Anthos Service Mesh 버전으로 업데이트되도록 모든 워크로드에 새로운 사이드카 프록시를 삽입해야 합니다. 사이드카 프록시를 업데이트하는 데 걸리는 시간은 포드 수, 노드 수, 배포 확장 설정, 포드 중단 예산, 기타 구성 설정과 같은 다양한 요소에 따라 달라집니다. 사이드카 프록시를 업데이트하는 데 걸리는 대략적인 시간은 분당 포드 100개입니다.

업그레이드 준비

이 섹션에서는 Anthos Service Mesh 업그레이드를 준비하기 위해 실행하는 단계를 설명합니다.

지원되는 기능과 이 가이드를 검토하여 기능과 업그레이드 프로세스를 익히세요.
이전 버전의 Anthos Service Mesh를 설치할 때 선택적 기능을 사용 설정한 경우 업그레이드 시 동일한 기능을 사용 설정해야 합니다. --set values 플래그를 추가하거나 istioctl install 명령어를 실행할 때 YAML 파일로 -f 플래그를 지정하여 선택적 기능을 사용 설정할 수 있습니다.

주의: YAML 파일로 --set values 플래그 또는 -f 플래그 생략하면 성공적으로 설치됩니다. 하지만 생략된 값은 Anthos Service Mesh가 다시 배포될 때 기본값으로 재설정되기 때문에 의도한 구성과 다릅니다. istioctl install을 실행하여 1.6.14로 업그레이드할 때 동일한 플래그를 사용해야 합니다.
비공개 클러스터에 Anthos Service Mesh를 설치하는 경우 자동 사이드카 삽입과 함께 사용되는 웹훅을 가져오려면 방화벽에서 포트 15017을 열어야 제대로 작동합니다. 자세한 내용은 비공개 클러스터에서 포트 열기를 참조하세요.
Anthos Service Mesh 1.5에서 업그레이드하는 경우 롤백해야 할 경우를 대비하여 다음 단계를 수행합니다.
1. asm-1-5 디렉터리를 만듭니다.
2. asm-1-5 디렉터리로 1.5 설치 파일을 다운로드합니다.
3. 파일 콘텐츠 압축을 asm-1-5 디렉터리로 풉니다.
4. Anthos Service Mesh 1.5 설치 루트 디렉터리에 있는지 확인합니다.
5. 1.5 kpt 패키지를 다운로드하고 1.5 istio-operator.yaml을 구성합니다.

환경 설정

Google Kubernetes Engine에 설치하는 경우 Google Cloud 리소스에 대한 브라우저 내 명령줄 인터페이스인 Cloud Shell 또는 Linux나 macOS를 실행하는 자체 컴퓨터를 사용하여 설치 가이드를 따를 수 있습니다.

옵션 A: Cloud Shell 사용

Cloud Shell은 Debian 기반 Linux 운영체제를 실행하는 g1-small Compute Engine 가상 머신(VM)을 프로비저닝합니다. Cloud Shell 사용의 장점은 다음과 같습니다.

Cloud Shell에는 필요한 gcloud, kubectl, helm 명령줄 도구가 포함되어 있습니다.
Cloud Shell $HOME 디렉터리에는 5GB의 영구 저장공간이 있습니다.
다음과 같은 텍스트 편집기를 선택할 수 있습니다.
- Cloud Shell 창 상단에 있는 ''를 클릭하여 액세스할 수 있는 코드 편집기
- Cloud Shell의 명령줄에서 액세스할 수 있는 Eacs, Vim 또는 Nano

Cloud Shell을 사용하려면 다음 안내를 따르세요.

Google Cloud 콘솔로 이동합니다.
Google Cloud 프로젝트를 선택합니다.
Google Cloud 콘솔 창 상단에 있는 Cloud Shell 활성화 버튼을 클릭합니다.

Google Cloud 콘솔 하단의 새 프레임에서 Cloud Shell 세션이 열리고 명령줄 프롬프트가 표시됩니다.

구성요소를 업데이트합니다.

gcloud components update

이 명령어는 다음과 유사한 출력으로 응답합니다.

ERROR: (gcloud.components.update)
You cannot perform this action because the gcloud CLI component manager
is disabled for this installation. You can run the following command
to achieve the same result for this installation:

sudo apt-get update && sudo apt-get --only-upgrade install ...

long 명령어를 복사하고 붙여넣어 구성요소를 업데이트합니다.
kpt가 찾을 수 있도록 Git이 경로에 있는지 확인하세요.

옵션 B: 로컬에서 명령줄 도구 사용

로컬 머신에서 gcloud CLI를 설치하고 초기화합니다.

gcloud CLI가 이미 설치되어 있는 경우:

gcloud CLI로 인증합니다.
```
gcloud auth login
```
구성요소를 업데이트합니다.
```
gcloud components update
```
kubectl을 설치합니다.
```
gcloud components install kubectl
```
kpt를 설치합니다.
```
gcloud components install kpt
```
kpt가 찾을 수 있도록 Git이 경로에 있는지 확인하세요.

환경 변수 설정

클러스터가 생성된 프로젝트의 프로젝트 ID와 Fleet 호스트 프로젝트의 프로젝트 번호를 가져옵니다.
gcloud
다음 명령어를 실행합니다.
```
gcloud projects list
```
콘솔
1. Google Cloud 콘솔의 대시보드 페이지로 이동합니다.
  
  대시보드 페이지로 이동
2. 페이지 상단에서 선택 드롭다운 목록을 클릭합니다. 선택 창이 나타나면 프로젝트를 선택합니다.
  
  프로젝트 ID가 프로젝트 대시보드 프로젝트 정보 카드에 표시됩니다.
클러스터가 생성된 프로젝트의 프로젝트 ID에 대한 환경 변수를 만듭니다.
```
export PROJECT_ID=YOUR_PROJECT_ID
```
Fleet 호스트 프로젝트의 프로젝트 번호에 대한 환경 변수를 만듭니다.
```
export FLEET_PROJECT_NUMBER=YOUR_FLEET_PROJECT_NUMBER
```
중요: 이 가이드의 명령어 중 다수는 이러한 환경 변수에 따라 달라집니다. 셸 환경에서 연결 해제했다가 나중에 다시 연결하는 경우 변수를 다시 설정해야 합니다.
다음의 환경 변수를 만듭니다.
- 클러스터 이름을 설정합니다.
```
export CLUSTER_NAME=YOUR_CLUSTER_NAME
```
- CLUSTER_LOCATION을 클러스터 영역 또는 클러스터 리전으로 설정합니다.
```
export CLUSTER_LOCATION=YOUR_ZONE_OR_REGION
```

(선택사항) 클러스터의 메시 ID 변경

서비스 메시에 다른 프로젝트에 있는 여러 클러스터가 포함되어 있거나 포함될 경우 모든 클러스터에 Fleet 호스트 프로젝트의 프로젝트 번호를 기반으로 하는 동일한 메시 ID가 있어야 합니다. 클러스터에 설정된 메시 ID는 Anthos Service Mesh가 사용하도록 구성한 메시 ID와 일치해야 합니다.

클러스터가 하나만 있거나 서비스 메시에 동일한 프로젝트에 있는 여러 클러스터가 포함되어 있거나 포함할 경우 다음 단계를 건너뛰고 사용자 인증 정보 및 권한 설정을 진행하세요.

클러스터에서 새 메시 ID 라벨을 설정하려면 다음 안내를 따르세요.

메시 ID의 환경 변수를 만듭니다.

export MESH_ID="proj-${FLEET_PROJECT_NUMBER}"

클러스터에 보존하려는 기존 라벨이 있으면 mesh_id 라벨을 추가할 때 이러한 라벨을 포함해야 합니다.
1. 클러스터에 기존 라벨이 있는지 확인하려면 다음 안내를 따르세요.
```
gcloud container clusters describe ${CLUSTER_NAME} \
  --project ${PROJECT_ID}
```
  출력에서 resourceLabels 필드를 찾습니다. 각 라벨은 resourceLabels 필드 아래에 있는 별도의 줄에 저장됩니다. 예를 들면 다음과 같습니다.
```
resourceLabels:
  csm: ''
  env: dev
  release: stable
```
  기존 mesh_id는 보존할 필요가 없습니다. 새 mesh_id 라벨로 덮어씁니다.
  
  편의를 위해 환경 변수에 라벨을 추가할 수 있습니다. 다음에서 YOUR_EXISTING_LABELS를 쉼표로 구분된 클러스터의 기존 라벨 목록을 KEY=VALUE(예: env=dev,release=stable)로 바꿉니다.
```
export EXISTING_LABELS="YOUR_EXISTING_LABELS"
```
2. mesh_id 라벨을 설정합니다.
  - 클러스터에 보존하려는 기존 라벨이 있으면 mesh_id와 기존 라벨을 사용하여 클러스터를 업데이트합니다.
```
gcloud container clusters update ${CLUSTER_NAME} \
  --project ${PROJECT_ID}
  --update-labels=mesh_id=${MESH_ID},${EXISTING_LABELS}
```
  - 클러스터에 기존 라벨이 없는 경우 새로운 mesh_id 라벨로만 클러스터를 업데이트합니다.
```
gcloud container clusters update ${CLUSTER_NAME} \
  --project=${PROJECT_ID} \
  --update-labels=mesh_id=${MESH_ID}
```

사용자 인증 정보 및 권한 설정

클러스터와 상호작용하기 위해 사용자 인증 정보를 가져옵니다.

gcloud container clusters get-credentials ${CLUSTER_NAME} \
    --project=${PROJECT_ID}

클러스터 관리자 권한을 현재 사용자에게 부여합니다. Anthos Service Mesh에 필요한 역할 기반 액세스 제어(RBAC) 규칙을 만들려면 이러한 권한이 필요합니다.
```
kubectl create clusterrolebinding cluster-admin-binding \
  --clusterrole=cluster-admin \
  --user="$(gcloud config get-value core/account)"
```

"cluster-admin-binding" already exists 오류가 표시되면 안전하게 무시하고 기존 cluster-admin-binding을 계속 진행할 수 있습니다.

설치 파일 다운로드

Linux

Anthos Service Mesh 설치 파일을 현재 작업 디렉터리에 다운로드합니다.

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.6.14-asm.2-linux-amd64.tar.gz

서명 파일을 다운로드하고 openssl을 사용하여 서명을 확인합니다.

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.6.14-asm.2-linux-amd64.tar.gz.1.sig
openssl dgst -verify /dev/stdin -signature istio-1.6.14-asm.2-linux-amd64.tar.gz.1.sig istio-1.6.14-asm.2-linux-amd64.tar.gz <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF

예상되는 출력은 Verified OK입니다.

원하는 파일 시스템 위치에 파일 콘텐츠 압축을 풉니다. 예를 들어 콘텐츠를 현재 작업 디렉터리에 추출하려면 다음을 사용하세요.

tar xzf istio-1.6.14-asm.2-linux-amd64.tar.gz

이 명령어는 다음을 포함하는 현재 작업 디렉터리에 istio-1.6.14-asm.2이라는 설치 디렉터리를 만듭니다.

샘플 애플리케이션은 samples 디렉터리에 있습니다.
Anthos Service Mesh를 설치하는 데 사용하는 istioctl 명령줄 도구는 bin 디렉터리에 있습니다.
Anthos Service Mesh 구성 프로필은 manifests/profiles 디렉터리에 있습니다.

MacOS

Anthos Service Mesh 설치 파일을 현재 작업 디렉터리에 다운로드합니다.

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.6.14-asm.2-osx.tar.gz

서명 파일을 다운로드하고 openssl을 사용하여 서명을 확인합니다.

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.6.14-asm.2-osx.tar.gz.1.sig
openssl dgst -sha256 -verify /dev/stdin -signature istio-1.6.14-asm.2-osx.tar.gz.1.sig istio-1.6.14-asm.2-osx.tar.gz <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF

예상되는 출력은 Verified OK입니다.

원하는 파일 시스템 위치에 파일 콘텐츠 압축을 풉니다. 예를 들어 콘텐츠를 현재 작업 디렉터리에 추출하려면 다음을 사용하세요.

tar xzf istio-1.6.14-asm.2-osx.tar.gz

이 명령어는 다음을 포함하는 현재 작업 디렉터리에 istio-1.6.14-asm.2이라는 설치 디렉터리를 만듭니다.

샘플 애플리케이션은 samples 디렉터리에 있습니다.
Anthos Service Mesh를 설치하는 데 사용하는 istioctl 명령줄 도구는 bin 디렉터리에 있습니다.
Anthos Service Mesh 구성 프로필은 manifests/profiles 디렉터리에 있습니다.

Windows

Anthos Service Mesh 설치 파일을 현재 작업 디렉터리에 다운로드합니다.

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.6.14-asm.2-win.zip

서명 파일을 다운로드하고 openssl을 사용하여 서명을 확인합니다.

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.6.14-asm.2-win.zip.1.sig
openssl dgst -verify - -signature istio-1.6.14-asm.2-win.zip.1.sig istio-1.6.14-asm.2-win.zip <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF

예상되는 출력은 Verified OK입니다.

원하는 파일 시스템 위치에 파일 콘텐츠 압축을 풉니다. 예를 들어 콘텐츠를 현재 작업 디렉터리에 추출하려면 다음을 사용하세요.

tar xzf istio-1.6.14-asm.2-win.zip

이 명령어는 다음을 포함하는 현재 작업 디렉터리에 istio-1.6.14-asm.2이라는 설치 디렉터리를 만듭니다.

샘플 애플리케이션은 samples 디렉터리에 있습니다.
Anthos Service Mesh를 설치하는 데 사용하는 istioctl 명령줄 도구는 bin 디렉터리에 있습니다.
Anthos Service Mesh 구성 프로필은 manifests/profiles 디렉터리에 있습니다.

Anthos Service Mesh 설치 루트 디렉터리에 있는지 확인합니다.
```
cd istio-1.6.14-asm.2
```
편의를 위해 /bin 디렉터리의 도구를 PATH에 추가합니다.
```
export PATH=$PWD/bin:$PATH
```

리소스 구성 파일 준비

istioctl install 명령어를 실행할 때 명령줄에서 -f istio-operator.yaml을 지정합니다. 이 파일에는 Anthos Service Mesh에 필요한 프로젝트 및 클러스터에 대한 정보가 포함되어 있습니다. 프로젝트와 클러스터 정보를 설정할 수 있도록 istio-operator.yaml 및 기타 리소스 구성 파일이 포함된 패키지를 다운로드해야 합니다.

시작하려면 사용할 인증 기관(CA)에 따라 다운로드할 패키지를 선택합니다.

asm: 이 패키지에서는 새로운 설치에 권장되는 Mesh CA를 사용 설정합니다.
asm-citadel: Citadel을 CA로 사용 설정할 수 있습니다(선택 사항). 이 패키지를 선택하기 전에 자세한 내용은 인증 기관 선택을 참조하세요.

리소스 구성 파일을 준비하려면 다음 안내를 따르세요.

Anthos Service Mesh 패키지 리소스 구성 파일을 위한 새 디렉터리를 만듭니다. 클러스터 이름을 디렉터리 이름으로 사용하는 것이 좋습니다.
Anthos Service Mesh 패키지를 다운로드할 디렉터리로 변경합니다.

CA를 기준으로 사용할 패키지를 다운로드합니다.

Mesh CA

Mesh CA를 사용 설정하는 asm 패키지를 다운로드합니다.

kpt pkg get \
https://github.com/GoogleCloudPlatform/anthos-service-mesh-packages.git/asm@release-1.6-asm asm

Citadel

Citadel을 CA로 사용 설정하는 asm-citadel 패키지를 다운로드합니다.

kpt pkg get \
https://github.com/GoogleCloudPlatform/anthos-service-mesh-packages.git/asm-citadel@release-1.6-asm asm

클러스터가 생성된 프로젝트의 프로젝트 ID를 설정합니다.
```
kpt cfg set asm gcloud.core.project ${PROJECT_ID}
```

Fleet 호스트 프로젝트의 프로젝트 번호를 설정합니다.

kpt cfg set asm gcloud.project.environProjectNumber ${FLEET_PROJECT_NUMBER}

클러스터 이름을 설정합니다.

kpt cfg set asm gcloud.container.cluster ${CLUSTER_NAME}

기본 영역 또는 리전을 설정합니다.

kpt cfg set asm gcloud.compute.location ${CLUSTER_LOCATION}

사용할 구성 프로필을 설정합니다.
- 모든 클러스터가 동일한 프로젝트에 있으면 asm-gcp 프로필을 설정합니다.
```
kpt cfg set asm anthos.servicemesh.profile asm-gcp
```
- 서비스 메시에 다른 프로젝트에 있는 클러스터가 여러 개 포함되어 있거나 포함될 경우 asm-gcp-multiproject 프로필(베타)을 설정합니다.
```
kpt cfg set asm anthos.servicemesh.profile asm-gcp-multiproject
```
asm-gcp-multiproject 프로필을 설정하고 Mesh CA를 사용 설정하는 asm 패키지를 다운로드한 경우 멀티 클러스터/멀티 프로젝트 서비스 메시를 구성하는 다른 프로젝트에 신뢰할 수 있는 도메인 별칭을 구성해야 합니다. 그 이외의 경우 이 단계를 건너뛰세요.
1. 멀티 클러스터/멀티 프로젝트 메시에 포함될 모든 클러스터의 프로젝트 ID를 가져옵니다.
2. 클러스터의 프로젝트 ID마다 신뢰할 수 있는 도메인 별칭을 설정합니다. 예를 들어 프로젝트 3개에 클러스터가 있으면 다음 명령어를 실행하고 PROJECT_ID_1, PROJECT_ID_2, PROJECT_ID_3을 각 클러스터의 프로젝트 ID로 바꿉니다.
```
kpt cfg set asm anthos.servicemesh.trustDomainAliases PROJECT_ID_1.svc.id.goog PROJECT_ID_2.svc.id.goog PROJECT_ID_3.svc.id.goog
```
  다른 프로젝트에서 클러스터를 구성할 때 동일한 명령어를 사용할 수 있습니다.
  
  신뢰할 수 있는 도메인 별칭을 사용하면 Mesh CA가 다른 프로젝트의 클러스터에 있는 워크로드를 인증할 수 있습니다. 신뢰할 수 있는 도메인 별칭 설정 외에도 Anthos Service Mesh를 설치한 후에는 교차 클러스터 부하 분산을 사용 설정해야 합니다.
kpt setter의 값을 출력합니다.
```
  kpt cfg list-setters asm
```
명령어의 출력에서 다음 setter의 값이 올바른지 확인합니다.
- gcloud.compute.location
- gcloud.container.cluster
- gcloud.core.project
- gcloud.project.environProjectNumber

Anthos Service Mesh 업그레이드

새 버전의 Anthos Service Mesh를 설치하려면 이중 제어 영역 업그레이드 프로세스(Istio 문서에서는 카나리아 업그레이드라고 함)를 따르는 것이 좋습니다. 이중 제어 영역 업그레이드를 사용하는 경우 기존 제어 영역과 함께 새 버전의 제어 영역을 설치합니다. 새 버전을 설치할 때 새 제어 영역의 버전을 식별하는 revision 라벨을 포함합니다. 각 버전은 자체 배포 및 서비스로 구현된 전체 Anthos Service Mesh 제어 영역입니다.

그런 다음 워크로드의 동일한 revision 라벨이 새 제어 영역을 가리키도록 설정하고 순차적 재시작을 수행하여 새 Anthos Service Mesh 버전으로 프록시를 다시 삽입합니다. 이 방식을 사용하면 일부 워크로드에서 업그레이드의 효과를 모니터링할 수 있습니다. 애플리케이션을 테스트한 후 모든 트래픽을 새 버전으로 마이그레이션할 수 있습니다. 이 방식은 새로운 제어 영역이 이전 버전의 제어 영역을 대체하는 인플레이스(In-Place) 업그레이드보다 훨씬 안전합니다.

제어 영역 업데이트

다음 명령어를 실행하여 istio-operator.yaml 파일에 설정한 구성 프로필을 사용하는 새 제어 영역을 배포합니다. 지원되는 선택적인 기능을 사용 설정하려면 다음 명령줄에 -f와 YAML 파일 이름을 포함합니다. 자세한 내용은 선택 기능 사용 설정을 참조하세요.

  istioctl install \
    -f asm/cluster/istio-operator.yaml \
    --set revision=asm-1614-2

--set revision 인수는 istiod에 istio.io/rev 라벨을 추가합니다. 명령어를 실행하면 두 개의 제어 영역 배포와 서비스가 나란히 실행됩니다.

kubectl get pods -n istio-system

출력 예시:

NAME                                        READY   STATUS    RESTARTS   AGE
istio-ingressgateway-c56675fcd-86zdn        1/1     Running   0          2m9s
istio-ingressgateway-c56675fcd-vn4nv        1/1     Running   0          2m21s
istiod-asm-1614-2-6d5cfd4b89-xztlr           1/1     Running   0          3m44s
istiod-fb7f746f4-wcntn                      1/1     Running   0          50m

워크로드 재배포

새 버전을 설치해도 기존 사이드카 프록시에는 영향을 미치지 않습니다. 기존 사이드카 프록시를 업그레이드하려면 새 제어 영역을 가리키도록 구성해야 합니다. 사이드카 삽입 중에는 네임 스페이스 라벨 istio.io/rev를 기반으로 제어됩니다.

새로운 Anthos Service Mesh 버전으로 삽입되도록 워크로드를 업데이트합니다.
```
kubectl label namespace NAMESPACE istio-injection- istio.io/rev=asm-1614-2 --overwrite
```
istio-injection 라벨은 istio.io/rev 라벨보다 우선하므로 삭제해야 합니다.
포드를 다시 시작하여 다시 삽입을 트리거합니다.
```
kubectl rollout restart deployment -n NAMESPACE
```
포드가 istiod-asm-1614-2 제어 영역을 가리키도록 구성되어 있는지 확인합니다.
```
kubectl get pods -n NAMESPACE -l istio.io/rev=asm-1614-2
```
애플리케이션을 테스트하여 워크로드가 올바르게 작동하는지 확인합니다.
다른 네임스페이스에 워크로드가 있으면 각 네임스페이스에 이전 단계를 반복합니다.
애플리케이션이 예상대로 작동한다고 판단되면 업그레이드 완료로 건너뜁니다. 그렇지 않으면 다음 단계를 수행하여 이전 버전으로 롤백합니다.
1. 제어 영역의 이전 버전으로 삽입되도록 워크로드를 업데이트합니다.
```
 kubectl label namespace NAMESPACE istio.io/rev- istio-injection=enabled --overwrite
```
2. 프록시에 이전 버전이 지정되도록 다시 삽입을 트리거하는 포드를 다시 시작합니다.
```
 kubectl rollout restart deployment -n NAMESPACE
```
3. 제어 영역 구성요소 롤백
  이전 1.6으로 롤백
  1. istio-ingressgateway의 이전 버전을 다시 배포합니다.
    
    kubectl -n istio-system rollout undo deploy istio-ingressgateway
  2. 새 제어 영역을 삭제합니다.
    
    kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-asm-1614-2 -n istio-system --ignore-not-found=true
  1.5로 롤백
  1. 1.5 Anthos Service Mesh 설치 파일을 다운로드한 디렉터리로 변경합니다.
  2. 이전 버전의 Anthos Service Mesh를 다시 설치합니다. 다음 명령어에서 선택적 기능을 사용 설정한 경우 YAML 파일 이름이 포함된 해당 --set values 플래그나 -f 플래그를 포함해야 합니다.
    
    bin/istioctl install \ -f asm/cluster/istio-operator.yaml

업그레이드 완료

애플리케이션이 예상대로 작동한다고 판단되면 다음 단계를 수행하여 업그레이드를 완료합니다.

이전 제어 영역을 삭제합니다.

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

다음 명령어를 실행하여 표준 서비스 컨트롤러를 배포합니다.
```
kubectl apply -f asm/canonical-service/controller.yaml
```
이 명령어는 표준 서비스 컨트롤러를 클러스터에 배포합니다. 표준 서비스 컨트롤러는 동일한 논리 서비스에 속하는 워크로드를 그룹화하며, Google Cloud 콘솔의 서비스 대시보드에서 추가 기능을 잠금 해제해야 합니다. 자세한 내용은 표준 서비스 컨트롤러 사용 설정 및 중지를 참조하세요.

다음 단계

Anthos Service Mesh에 클러스터 추가

GKE에서 Anthos Service Mesh 업그레이드

업그레이드 준비

환경 설정

옵션 A: Cloud Shell 사용

옵션 B: 로컬에서 명령줄 도구 사용

환경 변수 설정

gcloud

콘솔

(선택사항) 클러스터의 메시 ID 변경

사용자 인증 정보 및 권한 설정

설치 파일 다운로드

Linux

MacOS

Windows

리소스 구성 파일 준비

Mesh CA

Citadel

Anthos Service Mesh 업그레이드

제어 영역 업데이트

워크로드 재배포

이전 1.6으로 롤백

1.5로 롤백

업그레이드 완료

다음 단계