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

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

사용 가능한 버전

멀티 프로젝트 메시에서 GKE의 Anthos Service Mesh 업그레이드

이 가이드는 다른 Google Cloud 프로젝트에 있는 여러 클러스터를 포함하는 메시의 Google Kubernetes Engine(GKE) 클러스터에서 1.8 or a 1.9 patch release를 Anthos Service Mesh 1.9.8으로 업그레이드하는 방법을 설명합니다.

시작하기 전에

Anthos Service Mesh를 설치하기 전에 다음을 확인합니다.

환경을 설정하여 필요한 도구를 설치합니다.

업그레이드 준비

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

스크립트는 버전 업그레이드 프로세스(Istio 문서에서 '카나리아' 업그레이드라고 부름)를 따릅니다. 버전 기반 업그레이드에서는 스크립트가 기존 제어 영역과 함께 제어 영역의 새 버전을 설치합니다. 새 버전을 설치할 때 스크립트에는 새 제어 영역을 식별하는 revision 라벨이 포함됩니다.

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

환경 변수 설정

클러스터가 생성된 프로젝트의 프로젝트 ID와 Environ 호스트 프로젝트의 프로젝트 번호를 가져옵니다.
gcloud
다음 명령어를 실행합니다.
```
gcloud projects list
```
콘솔
1. Google Cloud 콘솔의 대시보드 페이지로 이동합니다.
  
  대시보드 페이지로 이동
2. 페이지 상단에서 선택 드롭다운 목록을 클릭합니다. 선택 창이 나타나면 프로젝트를 선택합니다.
  
  프로젝트 ID가 프로젝트 대시보드 프로젝트 정보 카드에 표시됩니다.
클러스터가 생성된 프로젝트의 프로젝트 ID에 대한 환경 변수를 만듭니다.
```
export PROJECT_ID=YOUR_PROJECT_ID
```
Environ 호스트 프로젝트의 프로젝트 번호에 대한 환경 변수를 만듭니다.
```
export ENVIRON_PROJECT_NUMBER=YOUR_ENVIRON_PROJECT_NUMBER
```
다음의 환경 변수를 만듭니다.
- 클러스터 이름을 설정합니다.
```
export CLUSTER_NAME=YOUR_CLUSTER_NAME
```
- CLUSTER_LOCATION을 클러스터 영역 또는 클러스터 리전으로 설정합니다.
```
export CLUSTER_LOCATION=YOUR_ZONE_OR_REGION
```
Google Cloud CLI의 기본 영역 또는 리전을 설정합니다. 여기서 기본값을 설정하지 않으면 이 페이지의 gcloud container clusters 명령어에 --zone 또는 --region 옵션을 지정해야 합니다.
- 단일 영역 클러스터가 있는 경우 기본 영역을 설정합니다.
```
gcloud config set compute/zone ${CLUSTER_LOCATION}
```
- 리전 클러스터가 있는 경우 기본 리전을 설정합니다.
```
gcloud config set compute/region ${CLUSTER_LOCATION}
```
팁: 나중에 셸 환경을 더 쉽게 설정할 수 있도록 각 환경 변수의 export 문을 복사하여 새로운 셸을 시작할 때 source로 사용하는 간단한 셸 스크립트에 붙여넣습니다. 또한 스크립트에 기본값을 설정하는 gcloud 명령어를 추가할 수 있습니다. 또는 gcloud init를 사용하여 이름이 지정된 gcloud 구성을 만들고 활성화할 수 있습니다.

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

클러스터와 상호작용하기 위해 사용자 인증 정보를 가져옵니다. 또한 이 명령어는 kubectl의 현재 컨텍스트를 클러스터로 설정합니다.
```
gcloud container clusters get-credentials ${CLUSTER_NAME} \
    --project=${PROJECT_ID}
```
참고: 기본 영역 또는 리전을 설정하지 않았으면 명령어에 리전(--region=REGION) 또는 영역(--zone=ZONE)을 제공해야 합니다.
클러스터 관리자 권한을 현재 사용자에게 부여합니다. 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.9.8-asm.6-linux-amd64.tar.gz

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

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

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

원하는 파일 시스템 위치에 파일 콘텐츠 압축을 풉니다. 예를 들어 콘텐츠를 현재 작업 디렉터리에 추출하려면 다음을 사용하세요.
```
 tar xzf istio-1.9.8-asm.6-linux-amd64.tar.gz
```
이 명령어는 다음을 포함하는 현재 작업 디렉터리에 istio-1.9.8-asm.6이라는 설치 디렉터리를 만듭니다.
- 샘플 애플리케이션은 samples 디렉터리에 있습니다.
- Anthos Service Mesh를 설치하는 데 사용하는 istioctl 명령줄 도구는 bin 디렉터리에 있습니다.
- Anthos Service Mesh 구성 프로필은 manifests/profiles 디렉터리에 있습니다.
Anthos Service Mesh 설치 루트 디렉터리에 있는지 확인합니다.
```
cd istio-1.9.8-asm.6
```

MacOS

Anthos Service Mesh 설치 파일을 현재 작업 디렉터리에 다운로드합니다.
```
curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.9.8-asm.6-osx.tar.gz
```

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

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

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

원하는 파일 시스템 위치에 파일 콘텐츠 압축을 풉니다. 예를 들어 콘텐츠를 현재 작업 디렉터리에 추출하려면 다음을 사용하세요.
```
tar xzf istio-1.9.8-asm.6-osx.tar.gz
```
이 명령어는 다음을 포함하는 현재 작업 디렉터리에 istio-1.9.8-asm.6이라는 설치 디렉터리를 만듭니다.
- 샘플 애플리케이션은 samples 디렉터리에 있습니다.
- Anthos Service Mesh를 설치하는 데 사용하는 istioctl 명령줄 도구는 bin 디렉터리에 있습니다.
- Anthos Service Mesh 구성 프로필은 manifests/profiles 디렉터리에 있습니다.
Anthos Service Mesh 설치 루트 디렉터리에 있는지 확인합니다.
```
cd istio-1.9.8-asm.6
```

Windows

Anthos Service Mesh 설치 파일을 현재 작업 디렉터리에 다운로드합니다.
```
curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.9.8-asm.6-win.zip
```

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

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

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

원하는 파일 시스템 위치에 파일 콘텐츠 압축을 풉니다. 예를 들어 콘텐츠를 현재 작업 디렉터리에 추출하려면 다음을 사용하세요.
```
tar xzf istio-1.9.8-asm.6-win.zip
```
이 명령어는 다음을 포함하는 현재 작업 디렉터리에 istio-1.9.8-asm.6이라는 설치 디렉터리를 만듭니다.
- 샘플 애플리케이션은 samples 디렉터리에 있습니다.
- Anthos Service Mesh를 설치하는 데 사용하는 istioctl 명령줄 도구는 bin 디렉터리에 있습니다.
- Anthos Service Mesh 구성 프로필은 manifests/profiles 디렉터리에 있습니다.
Anthos Service Mesh 설치 루트 디렉터리에 있는지 확인합니다.
```
cd istio-1.9.8-asm.6
```

리소스 구성 파일 준비

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

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

Mesh CA

Anthos Service Mesh 패키지 리소스 구성 파일을 위한 새 디렉터리를 만듭니다. 클러스터 이름을 디렉터리 이름으로 사용하는 것이 좋습니다.
Anthos Service Mesh 패키지를 다운로드할 디렉터리로 변경합니다.
kpt 버전을 확인합니다. kpt의 이전 1.x 버전을 실행하는지 확인:
```
kpt version
```
출력은 다음과 비슷하게 표시됩니다.
```
0.39.2
```
kpt 버전이 1.x 이상인 경우 환경 설정을 참조하여 운영체제에 필요한 버전을 다운로드합니다.

패키지를 다운로드합니다.

kpt pkg get \
https://github.com/GoogleCloudPlatform/anthos-service-mesh-packages.git/asm@release-1.9-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}

설치하려는 Anthos Service Mesh 버전으로 태그를 설정합니다.
```
kpt cfg set asm anthos.servicemesh.tag 1.9.8-asm.6
```
Anthos Service Mesh 패키지 리소스 구성 파일의 버전을 설정합니다.
```
kpt cfg set asm anthos.servicemesh.rev asm-198-6
```
Anthos Service Mesh를 설치할 때 istiod에 버전 라벨을 설정합니다. 유효성 검증 웹훅에 동일한 버전을 설정해야 합니다.
멀티 클러스터 구성의 클러스터가 다른 프로젝트에 있으므로 멀티 클러스터/멀티 프로젝트서비스 메시를 구성하는 다른 프로젝트에 신뢰할 수 있는 도메인 별칭을 구성해야 합니다.
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

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

                          NAME                                                       VALUE
anthos.servicemesh.canonicalServiceHub               gke.gcr.io/asm/canonical-service-controller:1.9.8-asm.6
anthos.servicemesh.controlplane.monitoring.enabled   true
anthos.servicemesh.hub                               gke.gcr.io/asm
anthos.servicemesh.hubMembershipID                   MEMBERSHIP_ID
anthos.servicemesh.tag                               1.9.8-asm.6
anthos.servicemesh.trustDomainAliases                [example-project-12345.svc.id.goog,example-project-23456.svc.id.goog,example-project-98765.svc.id.goog]
base-dir                                             base
gcloud.compute.location                              us-central
gcloud.compute.network                               default
gcloud.compute.subnetwork                            default
gcloud.container.cluster                             example-cluster-1
gcloud.container.cluster.clusterSecondaryRange
gcloud.container.cluster.releaseChannel              REGULAR
gcloud.container.cluster.servicesSecondaryRange
gcloud.container.nodepool.max-nodes                  4
gcloud.core.project                                  example-project-12345
gcloud.project.environProjectID                      FLEET_PROJECT_ID
gcloud.project.environProjectNumber                  1234567890123
gcloud.project.projectNumber                         9876543210987

다음 setter의 값이 올바른지 확인합니다.

anthos.servicemesh.rev
anthos.servicemesh.tag
anthos.servicemesh.trustDomainAliases
gcloud.compute.location
gcloud.container.cluster
gcloud.core.project
gcloud.project.environProjectNumber

다른 setter의 값은 무시해도 됩니다.

Istio CA

Anthos Service Mesh 패키지 리소스 구성 파일을 위한 새 디렉터리를 만듭니다. 클러스터 이름을 디렉터리 이름으로 사용하는 것이 좋습니다.
Anthos Service Mesh 패키지를 다운로드할 디렉터리로 변경합니다.
kpt 버전을 확인합니다. kpt의 이전 1.x 버전을 실행하는지 확인:
```
kpt version
```
출력은 다음과 비슷하게 표시됩니다.
```
0.39.2
```
kpt 버전이 1.x 이상인 경우 필요한 버전을 다운로드합니다.
```
curl -L https://github.com/GoogleContainerTools/kpt/releases/download/v0.39.2/kpt_linux_amd64 > kpt_0_39_2
chmod +x kpt_0_39_2
alias kpt="$(readlink -f kpt_0_39_2)"
```

패키지를 다운로드합니다.

kpt pkg get \
https://github.com/GoogleCloudPlatform/anthos-service-mesh-packages.git/asm@release-1.9-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}

설치하려는 Anthos Service Mesh 버전으로 태그를 설정합니다.
```
kpt cfg set asm anthos.servicemesh.tag 1.9.8-asm.6
```
Anthos Service Mesh 패키지 리소스 구성 파일의 버전을 설정합니다.
```
kpt cfg set asm anthos.servicemesh.rev asm-198-6
```

kpt setter의 값을 출력합니다.

kpt cfg list-setters asm

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

                          NAME                                                       VALUE
anthos.servicemesh.canonicalServiceHub               gke.gcr.io/asm/canonical-service-controller:1.9.8-asm.6
anthos.servicemesh.controlplane.monitoring.enabled   true
anthos.servicemesh.hub                               gke.gcr.io/asm
anthos.servicemesh.hubMembershipID                   MEMBERSHIP_ID
anthos.servicemesh.tag                               1.9.8-asm.6
anthos.servicemesh.trustDomainAliases
base-dir                                             base
gcloud.compute.location                              us-central
gcloud.compute.network                               default
gcloud.compute.subnetwork                            default
gcloud.container.cluster                             example-cluster-1
gcloud.container.cluster.clusterSecondaryRange
gcloud.container.cluster.releaseChannel              REGULAR
gcloud.container.cluster.servicesSecondaryRange
gcloud.container.nodepool.max-nodes                  4
gcloud.core.project                                  example-project-12345
gcloud.project.environProjectID                      FLEET_PROJECT_ID
gcloud.project.environProjectNumber                  1234567890123
gcloud.project.projectNumber                         9876543210987

다음 setter의 값이 올바른지 확인합니다.

anthos.servicemesh.rev
anthos.servicemesh.tag
gcloud.compute.location
gcloud.container.cluster
gcloud.core.project
gcloud.project.environProjectNumber

다른 setter의 값은 무시해도 됩니다.

Anthos Service Mesh 업그레이드

Mesh CA

현재 kubeconfig 컨텍스트가 Anthos Service Mesh를 설치할 클러스터를 가리키는지 확인합니다.
```
kubectl config current-context
```
출력은 다음 형식입니다.
```
gke_PROJECT_ID_CLUSTER_LOCATION_CLUSTER_NAME
```
kubeconfig 컨텍스트와 kpt setter의 값이 일치해야 합니다. 필요한 경우 gcloud container clusters get-credentials 명령어를 실행하여 현재 kubeconfig 컨텍스트를 설정합니다.
필요한 경우 istio-1.9.8-asm.6 디렉터리로 변경합니다. istioctl 클라이언트는 버전에 따라 다릅니다. istio-1.9.8-asm.6/bin 디렉터리의 버전을 사용해야 합니다.
다음 명령어를 실행하여 asm-gcp-multiproject 프로필로 새 제어 영역을 배포합니다. 지원되는 선택 기능을 사용 설정하려면 다음 명령줄에 -f와 YAML 파일 이름을 포함합니다. 자세한 내용은 선택 기능 사용 설정을 참조하세요.

중요: GKE 1.15에 설치하는 경우 다음 명령어에 지정된 오버레이 파일 외에 오버레이 파일 -f asm/istio/options/v1beta1-crds.yaml을 추가해야 합니다.
```
bin/istioctl install \
  -f asm/istio/istio-operator.yaml \
  -f asm/istio/options/multiproject.yaml \
  -f asm/istio/options/multicluster.yaml \
  -f asm/istio/options/revisioned-istio-ingressgateway.yaml \
  --revision=asm-198-6
```
--revision 인수는 istio.io/rev=asm-198-6 형식의 버전 라벨을 istiod에 추가합니다. 버전 라벨은 자동 사이드카 인젝터 웹훅에서 삽입된 사이드카를 특정 istiod 버전과 연결하는 데 사용됩니다. 네임스페이스에 사이드카 자동 삽입을 사용 설정하려면 istiod 배포와 일치하는 버전으로 라벨을 지정해야 합니다.

다음 파일은 istio-operator.yaml 파일의 설정을 재정의합니다.
- multiproject.yaml 파일은 asm-gcp-multiproject 프로필을 설정합니다.
- multicluster.yaml 파일은 Anthos Service Mesh 멀티 클러스터 구성에 필요한 설정을 구성합니다.
- revisioned-istio-ingressgateway.yaml 파일은 istio-ingressgateway의 버전 지정된 배포를 구성합니다.

istio-system의 제어 영역 pod가 작동 중인지 확인합니다.

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-198-6-6d5cfd4b89-xztlr           1/1     Running   0          3m44s
istiod-fb7f746f4-wcntn                      1/1     Running   0          50m

두 개의 제어 영역 배포와 서비스가 나란히 실행됩니다.

클러스터에 표준 서비스 컨트롤러를 배포합니다.
```
kubectl apply -f asm/canonical-service/controller.yaml
```
표준 서비스 컨트롤러는 동일한 논리 서비스에 속한 워크로드를 그룹화합니다. 표준 서비스에 대한 자세한 내용은 표준 서비스 개요를 참조하세요.

Istio CA

현재 kubeconfig 컨텍스트가 Anthos Service Mesh를 설치할 클러스터를 가리키는지 확인합니다.
```
kubectl config current-context
```
출력은 다음 형식입니다.
```
gke_PROJECT_ID_CLUSTER_LOCATION_CLUSTER_NAME
```
kubeconfig 컨텍스트와 kpt setter의 값이 일치해야 합니다. 필요한 경우 gcloud container clusters get-credentials 명령어를 실행하여 현재 kubeconfig 컨텍스트를 설정합니다.
필요한 경우 istio-1.9.8-asm.6 디렉터리로 변경합니다. istioctl 클라이언트는 버전에 따라 다릅니다. istio-1.9.8-asm.6/bin 디렉터리의 버전을 사용해야 합니다.
다음 명령어를 실행하여 asm-gcp-multiproject 프로필로 새 제어 영역을 배포합니다. 지원되는 선택 기능을 사용 설정하려면 다음 명령줄에 -f와 YAML 파일 이름을 포함합니다. 자세한 내용은 선택 기능 사용 설정을 참조하세요.

중요: GKE 1.15에 설치하는 경우 다음 명령어에 지정된 오버레이 파일 외에 오버레이 파일 -f asm/istio/options/v1beta1-crds.yaml을 추가해야 합니다.
```
bin/istioctl install \
  -f asm/istio/istio-operator.yaml \
  -f asm/istio/options/citadel-ca.yaml \
  -f asm/istio/options/multiproject.yaml \
  -f asm/istio/options/multicluster.yaml \
  -f asm/istio/options/revisioned-istio-ingressgateway.yaml \
  --revision=asm-198-6
```
--revision 인수는 istio.io/rev=asm-198-6 형식의 버전 라벨을 istiod에 추가합니다. 버전 라벨은 자동 사이드카 인젝터 웹훅에서 삽입된 사이드카를 특정 istiod 버전과 연결하는 데 사용됩니다. 네임스페이스에 사이드카 자동 삽입을 사용 설정하려면 istiod 배포와 일치하는 버전으로 라벨을 지정해야 합니다.

다음 파일은 istio-operator.yaml 파일의 설정을 재정의합니다.
- citadel-ca.yaml은 Istio CA를 인증 기관으로 구성합니다.
- multiproject.yaml 파일은 asm-gcp-multiproject 프로필을 설정합니다.
- multicluster.yaml 파일은 Anthos Service Mesh 멀티 클러스터 구성에 필요한 설정을 구성합니다.
- revisioned-istio-ingressgateway.yaml 파일은 istio-ingressgateway의 버전 지정된 배포를 구성합니다.

istio-system의 제어 영역 pod가 작동 중인지 확인합니다.

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-198-6-6d5cfd4b89-xztlr           1/1     Running   0          3m44s
istiod-fb7f746f4-wcntn                      1/1     Running   0          50m

두 개의 제어 영역 배포와 서비스가 나란히 실행됩니다.

클러스터에 표준 서비스 컨트롤러를 배포합니다.
```
kubectl apply -f asm/canonical-service/controller.yaml
```
표준 서비스 컨트롤러는 동일한 논리 서비스에 속한 워크로드를 그룹화합니다. 표준 서비스에 대한 자세한 내용은 표준 서비스 개요를 참조하세요.

워크로드 배포 및 재배포

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

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

istioctl install을 실행할 때 revisioned-istio-ingressgateway.yaml을 포함한 경우 istio-ingressgateway에 버전 지정된 배포가 구성됩니다. 이렇게 해서 새 버전으로 전환할 시간을 제어할 수 있습니다.

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-198-6
istio-ingressgateway-asm-182-2-8b5fc8767-hn4w2   1/1     Running   0          20s   asm-198-6
istiod-asm-176-1-67998f4b55-lrzpz                1/1     Running   0          68m   asm-186-8
istiod-asm-176-1-67998f4b55-r76kr                1/1     Running   0          68m   asm-186-8
istiod-asm-182-2-5cd96f88f6-n7tj9                1/1     Running   0          27s   asm-198-6
istiod-asm-182-2-5cd96f88f6-wm68b                1/1     Running   0          27s   asm-198-6
```
1. istio-ingressgateway에 이전 버전과 새 버전이 모두 있는지 확인합니다.
  - 업그레이드 시 revisioned-istio-ingressgateway 옵션이 포함되어 있다면 istio-ingressgateway의 카나리아 업그레이드가 완료된 것입니다. 이 경우 출력에 이전 버전과 새 버전의 istio-ingressgateway가 모두 표시됩니다.
  - 업그레이드 시 revisioned-istio-ingressgateway를 포함하지 않은 경우라면 istio-ingressgateway의 인플레이스 업그레이드가 완료된 것입니다. 이 경우 출력에는 새 버전만 표시됩니다.
2. 출력의 REV 열에서 새 버전에 대한 버전 라벨 값을 확인합니다. 이 예시에서 값은 asm-198-6입니다.
3. 또한 이전 istiod 버전의 버전 라벨 값을 기록해 두세요. 워크로드를 새 버전으로 이동하고 나면 istiod의 이전 버전을 삭제할 때 필요합니다. 예시 출력에서 이전 버전의 버전 라벨 값은 asm-186-8입니다.
이전 버전과 새 버전의 istio-ingressgateway가 모두 있는 경우 istio-ingressgateway를 새 버전으로 전환합니다. 다음 명령어에서 REVISION을 새 버전의 버전 라벨과 일치하는 값으로 변경합니다.
```
kubectl patch service -n istio-system istio-ingressgateway --type='json' -p='[{"op": "replace", "path": "/spec/selector/service.istio.io~1canonical-revision", "value": "REVISION"}]'
```
예상 출력: service/istio-ingressgateway patched
네임스페이스에 버전 라벨을 추가하고 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 라벨 삭제가 포함됩니다.
pod를 다시 시작하여 재삽입을 트리거합니다.
```
kubectl rollout restart deployment -n NAMESPACE
```
pod가 새 버전의 istiod를 가리키도록 구성되었는지 확인합니다.
```
kubectl get pods -n NAMESPACE -l istio.io/rev=REVISION
```
애플리케이션을 테스트하여 워크로드가 올바르게 작동하는지 확인합니다.
다른 네임스페이스에 워크로드가 있으면 단계를 반복하여 네임스페이스에 라벨을 지정하고 pod를 다시 시작합니다.
애플리케이션이 예상대로 만족스럽게 작동한다면 계속해서 남은 단계를 진행하여 istiod의 새 버전으로의 전환합니다. 애플리케이션에 문제가 있는 경우 롤백 단계를 따르세요.
다음 명령어를 다시 실행하여 istio-ingressgateway의 이전 버전과 새 버전 모두 있는지 또는 새 버전만 있는지 확인하십시오. 이에 따라 istio-ingressgateway의 새 버전으로 전환하거나 이전 버전으로 롤백하는 방법을 결정합니다.
```
kubectl get pod -n istio-system -L istio.io/rev
```
주의: 새 버전의 istio-ingressgateway만 있는 경우 istio-ingressgateway 배포를 삭제하는 명령어를 실행하지 마세요. 이렇게 하면 트래픽이 서비스 메시로 유입되는 것을 방지할 수 있습니다.
전환 완료
애플리케이션이 예상 대로 작동하여 만족스러우면 이전 제어 영역을 삭제하여 새 버전으로의 변환을 완료합니다.
1. anthos-service-mesh GitHub 저장소의 파일이 있는 디렉터리로 변경합니다.
2. 새 제어 영역을 사용하도록 검증 웹훅을 구성합니다.
  kubectl apply -f asm/istio/istiod-service.yaml
3. 이전 버전 및 새 버전의 istio-ingressgateway가 모두 있다면 이전 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에서 마이그레이션한 경우 이전 istiod에는 버전 라벨이 없습니다.
  
  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-ingressgateway의 이전 버전으로 다시 전환합니다. 사용하는 명령어는 이전 버전과 새 버전의 istio-ingressgateway를 모두 가지고 있는지 아니면 새 버전만 가지고 있는지에 따라 달라집니다.
  - 이전 버전과 새 버전의 istio-ingressgateway가 모두 있는 경우 kubectl patch service 명령어를 실행하고 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"}]'
  - 새 버전의 istio-ingressgateway만 있는 경우 kubectl rollout undo 명령어를 실행합니다.
    
    kubectl -n istio-system rollout undo deploy istio-ingressgateway
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가 모두 있으면 새 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 플래그가 포함되지 않았으면 스크립트는 표준 서비스 컨트롤러를 사용 설정합니다. 사용 설정 상태로 두는 것이 좋지만 사용 중지해야 하는 경우 표준 서비스 컨트롤러 사용 설정 및 중지를 참조하세요.

멀티 프로젝트 메시에서 GKE의 Anthos Service Mesh 업그레이드

시작하기 전에

업그레이드 준비

환경 변수 설정

gcloud

콘솔

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

설치 파일 다운로드

Linux

MacOS

Windows

리소스 구성 파일 준비

Mesh CA

Istio CA

Anthos Service Mesh 업그레이드

Mesh CA

Istio CA

워크로드 배포 및 재배포

전환 완료

마이그레이션

업그레이드

마이그레이션

업그레이드

롤백

다음 단계