Anthos Service Mesh 1.10 はサポート期間が終了し、今後はサポートされません。以前のバージョンからのアップグレードをご覧ください。

最新のドキュメントを表示するか、他の利用可能なバージョンを選択します。

利用可能なバージョン

マルチプロジェクトメッシュの GKE で Anthos Service Mesh をアップグレードする

このガイドでは、異なる Google Cloud プロジェクトにある複数のクラスタから構成されるメッシュで、Google Kubernetes Engine（GKE）クラスタの Anthos Service Mesh を 1.9 or a 1.10 patch release から 1.10.6 にアップグレードする方法について説明します。

始める前に

Anthos Service Mesh をインストールする前に、次のことを確認してください。

環境を設定し、必要なツールをインストールしている。

アップグレードの準備を行う

以前のインストールをカスタマイズした場合は、Anthos Service Mesh バージョンにアップグレードするか、Istio から移行する際に、同じカスタマイズを行う必要があります。--set values フラグを istioctl install に追加してインストールをカスタマイズした場合は、それらの設定をオーバーレイファイルと呼ばれる IstioOperator YAML ファイルに追加する必要があります。オーバーレイファイルを指定するには、スクリプトの実行時にファイル名で --custom_overlay オプションを使用します。このスクリプトは、オーバーレイファイルを istioctl install に渡します。

スクリプトは、リビジョンアップグレードプロセス（Istio ドキュメントでは「カナリア」アップグレード）に沿って実行されます。リビジョンベースのアップグレードでは、スクリプトは既存のコントロールプレーンを残しながら、コントロールプレーンの新しいリビジョンをインストールします。新しいバージョンをインストールすると、新しいコントロールプレーンを識別する revision ラベルがスクリプトに追加されます。

新しいバージョンへの移行では、ワークロードにこれと同じ revision ラベルを設定し、ローリング再起動を実行してプロキシを再挿入することで、新しい Anthos Service Mesh のバージョンと構成が使用されるようになります。この方法では、少数のワークロードでアップグレードの効果をモニタリングできます。アプリケーションのテスト後に、すべてのトラフィックを新しいバージョンに移行できます。この手法は、前のバージョンを新しいコントロールプレーンコンポーネントに置き換えるインプレースアップグレードよりも安全です。

環境変数を設定する

クラスタが作成されたプロジェクトのプロジェクト 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.10.6-asm.2-linux-amd64.tar.gz
```

署名ファイルをダウンロードし、openssl を使用して署名を検証します。

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

想定される出力は Verified OK です。

ファイルシステム上の任意の場所にファイルの内容を抽出します。たとえば、現在の作業ディレクトリにコンテンツを抽出するには、次のコマンドを実行します。
```
 tar xzf istio-1.10.6-asm.2-linux-amd64.tar.gz
```
このコマンドにより、現在の作業ディレクトリに istio-1.10.6-asm.2 という名前のインストールディレクトリが作成されます。このディレクトリには、次のものが含まれます。
- samples ディレクトリにあるサンプルアプリケーション。
- Anthos Service Mesh のインストールに使用する istioctl コマンドラインツールは、bin ディレクトリにあります。
- Anthos Service Mesh 構成プロファイルは manifests/profiles ディレクトリにあります。
Anthos Service Mesh インストールのルートディレクトリに移動していることを確認します。
```
cd istio-1.10.6-asm.2
```

Mac OS

Anthos Service Mesh インストールファイルを現在の作業ディレクトリにダウンロードします。
```
curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.10.6-asm.2-osx.tar.gz
```

署名ファイルをダウンロードし、openssl を使用して署名を検証します。

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

想定される出力は Verified OK です。

ファイルシステム上の任意の場所にファイルの内容を抽出します。たとえば、現在の作業ディレクトリにコンテンツを抽出するには、次のコマンドを実行します。
```
tar xzf istio-1.10.6-asm.2-osx.tar.gz
```
このコマンドにより、現在の作業ディレクトリに istio-1.10.6-asm.2 という名前のインストールディレクトリが作成されます。このディレクトリには、次のものが含まれます。
- samples ディレクトリにあるサンプルアプリケーション。
- Anthos Service Mesh のインストールに使用する istioctl コマンドラインツールは、bin ディレクトリにあります。
- Anthos Service Mesh 構成プロファイルは manifests/profiles ディレクトリにあります。
Anthos Service Mesh インストールのルートディレクトリに移動していることを確認します。
```
cd istio-1.10.6-asm.2
```

Windows

Anthos Service Mesh インストールファイルを現在の作業ディレクトリにダウンロードします。
```
curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.10.6-asm.2-win.zip
```

署名ファイルをダウンロードし、openssl を使用して署名を検証します。

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

想定される出力は Verified OK です。

ファイルシステム上の任意の場所にファイルの内容を抽出します。たとえば、現在の作業ディレクトリにコンテンツを抽出するには、次のコマンドを実行します。
```
tar xzf istio-1.10.6-asm.2-win.zip
```
このコマンドにより、現在の作業ディレクトリに istio-1.10.6-asm.2 という名前のインストールディレクトリが作成されます。このディレクトリには、次のものが含まれます。
- samples ディレクトリにあるサンプルアプリケーション。
- Anthos Service Mesh のインストールに使用する istioctl コマンドラインツールは、bin ディレクトリにあります。
- Anthos Service Mesh 構成プロファイルは manifests/profiles ディレクトリにあります。
Anthos Service Mesh インストールのルートディレクトリに移動していることを確認します。
```
cd istio-1.10.6-asm.2
```

リソース構成ファイルの準備

istioctl install コマンドを実行するときは、コマンドラインで -f istio-operator.yaml を指定します。このファイルには、Anthos Service Mesh で必要なプロジェクトとクラスタに関する情報が含まれています。プロジェクトとクラスタの情報を設定できるように、istio-operator.yaml と他のリソース構成ファイルを含むパッケージをダウンロードする必要があります。

リソース構成ファイルを準備するには:

Mesh CA

Anthos Service Mesh パッケージのリソース構成ファイル用に新しいディレクトリを作成します。クラスタ名をディレクトリ名として使用することをおすすめします。
Anthos Service Mesh パッケージをダウンロードするディレクトリに変更します。
kpt のバージョンを確認します。1.x より前のバージョンの kpt を実行していることを確認します。
```
kpt version
```
出力例を以下に示します。
```
0.39.2
```
kpt のバージョンが 1.x 以上の場合は、環境の設定を参照して、ご使用のオペレーティングシステムに必要なバージョンをダウンロードしてください。

パッケージをダウンロードします。

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

クラスタが作成されたプロジェクトのプロジェクト ID を設定します。
```
kpt cfg set asm gcloud.core.project ${PROJECT_ID}
```
フリートホストプロジェクトのプロジェクト番号を設定します。
```
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.10.6-asm.2
```
Anthos Service Mesh のパッケージリソース構成ファイルでリビジョンを設定します。
```
kpt cfg set asm anthos.servicemesh.rev asm-1106-2
```
Anthos Service Mesh をインストールするときに、istiod にリビジョンラベルを設定します。検証 Webhook に同じリビジョンを設定する必要があります。
マルチクラスタ構成内のクラスタは異なるプロジェクトにあるため、マルチクラスタ / マルチプロジェクトのサービスメッシュを形成する他のプロジェクトに、信頼できるドメインエイリアスを構成する必要があります。
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 セッターの値を出力します。

kpt cfg list-setters asm

コマンドの出力は、次のようになります。

                          NAME                                                       VALUE
anthos.servicemesh.canonicalServiceHub               gke.gcr.io/asm/canonical-service-controller:1.10.6-asm.2
anthos.servicemesh.controlplane.monitoring.enabled   true
anthos.servicemesh.hub                               gke.gcr.io/asm
anthos.servicemesh.hubMembershipID                   MEMBERSHIP_ID
anthos.servicemesh.tag                               1.10.6-asm.2
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

次のセッターの値が正しいことを確認します。

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

他のセッターの値は無視してかまいません。

Istio CA

Anthos Service Mesh パッケージのリソース構成ファイル用に新しいディレクトリを作成します。クラスタ名をディレクトリ名として使用することをおすすめします。
Anthos Service Mesh パッケージをダウンロードするディレクトリに変更します。
kpt のバージョンを確認します。1.x より前のバージョンの kpt を実行していることを確認します。
```
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.10-asm asm

クラスタが作成されたプロジェクトのプロジェクト ID を設定します。
```
kpt cfg set asm gcloud.core.project ${PROJECT_ID}
```
フリートホストプロジェクトのプロジェクト番号を設定します。
```
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.10.6-asm.2
```
Anthos Service Mesh のパッケージリソース構成ファイルでリビジョンを設定します。
```
kpt cfg set asm anthos.servicemesh.rev asm-1106-2
```

kpt セッターの値を出力します。

kpt cfg list-setters asm

コマンドの出力は、次のようになります。

                          NAME                                                       VALUE
anthos.servicemesh.canonicalServiceHub               gke.gcr.io/asm/canonical-service-controller:1.10.6-asm.2
anthos.servicemesh.controlplane.monitoring.enabled   true
anthos.servicemesh.hub                               gke.gcr.io/asm
anthos.servicemesh.hubMembershipID                   MEMBERSHIP_ID
anthos.servicemesh.tag                               1.10.6-asm.2
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

次のセッターの値が正しいことを確認します。

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

他のセッターの値は無視してかまいません。

Anthos Service Mesh のアップグレード

Mesh CA

現在の kubeconfig コンテキストが、Anthos Service Mesh をインストールするクラスタを指していることを確認します。
```
kubectl config current-context
```
出力は次の形式になります。
```
gke_PROJECT_ID_CLUSTER_LOCATION_CLUSTER_NAME
```
kubeconfig コンテキストと kpt セッターの値は一致する必要があります。必要に応じて、gcloud container clusters get-credentials コマンドを実行して、現在の kubeconfig コンテキストを設定します。
必要に応じて、istio-1.10.6-asm.2 ディレクトリに移動します。istioctl クライアントはバージョンに依存します。istio-1.10.6-asm.2/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 \
  --revision=asm-1106-2
```
--revision 引数は、istio.io/rev=asm-1106-2 形式のリビジョンラベルを istiod に追加します。リビジョンラベルは、自動サイドカーインジェクタ Webhook によって使用され、挿入されたサイドカーを特定の istiod リビジョンに関連付けます。名前空間のサイドカー自動挿入を有効にするには、istiod Deployment に一致するリビジョンにラベルを付ける必要があります。

次のファイルは istio-operator.yaml ファイルの設定をオーバーライドします。
- multiproject.yaml ファイルは asm-gcp-multiproject プロファイルを設定します。
- multicluster.yaml ファイルは、マルチクラスタ構成で Anthos Service Mesh が必要とする設定を構成します。

istio-system のコントロールプレーン Pod が稼働していることを確認します。

kubectl get pods -n istio-system

出力例:

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

コントロールプレーンの 2 つの Deployment と Service が並行して実行されている。

正規サービスコントローラをクラスタにデプロイします。
```
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 セッターの値は一致する必要があります。必要に応じて、gcloud container clusters get-credentials コマンドを実行して、現在の kubeconfig コンテキストを設定します。
必要に応じて、istio-1.10.6-asm.2 ディレクトリに移動します。istioctl クライアントはバージョンに依存します。istio-1.10.6-asm.2/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 \
  --revision=asm-1106-2
```
--revision 引数は、istio.io/rev=asm-1106-2 形式のリビジョンラベルを istiod に追加します。リビジョンラベルは、自動サイドカーインジェクタ Webhook によって使用され、挿入されたサイドカーを特定の istiod リビジョンに関連付けます。名前空間のサイドカー自動挿入を有効にするには、istiod Deployment に一致するリビジョンにラベルを付ける必要があります。

次のファイルは istio-operator.yaml ファイルの設定をオーバーライドします。
- citadel-ca.yaml は Istio CA を認証局として構成します。
- multiproject.yaml ファイルは asm-gcp-multiproject プロファイルを設定します。
- multicluster.yaml ファイルは、マルチクラスタ構成で Anthos Service Mesh が必要とする設定を構成します。

istio-system のコントロールプレーン Pod が稼働していることを確認します。

kubectl get pods -n istio-system

出力例:

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

コントロールプレーンの 2 つの Deployment と Service が並行して実行されている。

正規サービスコントローラをクラスタにデプロイします。
```
kubectl apply -f asm/canonical-service/controller.yaml
```
正規サービスコントローラは、同じ論理サービスに属するワークロードをグループ化します。正規サービスのさらに詳しい内容については、正規サービスの概要をご覧ください。

ワークロードのデプロイと再デプロイ

自動サイドカープロキシインジェクション（自動挿入）を有効にするまで、インストールは完了しません。OSS Istio からの移行とアップグレードは、リビジョンベースのアップグレードプロセスに沿って進めます（Istio ドキュメントでは「カナリアアップグレード」と呼ばれます）。リビジョンベースのアップグレードでは、既存のコントロールプレーンに並ぶ形で新しいバージョンのコントロールプレーンがインストールされます。次に、一部のワークロードを新しいバージョンに移行します。これにより、すべてのトラフィックを新しいバージョンに移行する前に、ワークロードのごく一部でアップグレードの影響をモニタリングできます。

istioctl install を実行した際に、istio.io/rev=asm-1106-2 形式のリビジョンラベルを istiod に設定します。自動挿入を有効にするには、一致するリビジョンラベルを名前空間に追加します。リビジョンラベルは、サイドカーインジェクタ Webhook によって使用され、挿入されたサイドカーを特定の istiod リビジョンに関連付けます。ラベルを追加したら、サイドカーを挿入するために名前空間内の Pod を再起動します。

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-1106-2
istio-ingressgateway-asm-182-2-8b5fc8767-hn4w2   1/1     Running   0          20s   asm-1106-2
istiod-asm-176-1-67998f4b55-lrzpz                1/1     Running   0          68m   asm-198-3
istiod-asm-176-1-67998f4b55-r76kr                1/1     Running   0          68m   asm-198-3
istiod-asm-182-2-5cd96f88f6-n7tj9                1/1     Running   0          27s   asm-1106-2
istiod-asm-182-2-5cd96f88f6-wm68b                1/1     Running   0          27s   asm-1106-2

出力の REV 列にある、新しいバージョンのリビジョンラベルの値をメモします。この例での値は asm-1106-2 です。
古い istiod バージョンのリビジョンラベルの値もメモしてください。これは、新しいバージョンへのワークロードの移行を完了した後に古いバージョンの istiod を削除するために必要です。この出力例では、古いバージョンのリビジョンラベルの値は asm-198-3 です。

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 の新しいバージョンへの移行のステップに進みます。アプリケーションに問題がある場合は、次の手順に沿ってロールバックを行います。
移行を完了させる
アプリケーションが想定どおりに動作していることを確認したら、古いコントロールプレーンを削除して新しいバージョンへの移行を完了します。
1. anthos-service-mesh GitHub リポジトリから取得したファイルがあるディレクトリに移動します。
2. 新しいコントロールプレーンを使用するように検証 Webhook を構成します。
```
kubectl apply -f asm/istio/istiod-service.yaml
```
3. 古い istio-ingressgateway Deployment を削除します。実行するコマンドは、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-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. プロキシが Istio のバージョンになるように、Pod を再起動してインジェクションを再度トリガーします。
```
kubectl rollout restart deployment -n NAMESPACE
```
5. 新しい istio-ingressgateway Deployment を削除します。次のコマンドの 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 フラグを含めなかった場合、スクリプトで Canonical Service コントローラが有効になります。有効にしたままにすることをおすすめしますが、無効にする場合は、正規サービスコントローラの有効化と無効化をご覧ください。

マルチプロジェクト メッシュの GKE で Anthos Service Mesh をアップグレードする

始める前に

アップグレードの準備を行う

環境変数を設定する

gcloud

コンソール

認証情報と権限の設定

インストール ファイルのダウンロード

Linux

Mac OS

Windows

リソース構成ファイルの準備

Mesh CA

Istio CA

Anthos Service Mesh のアップグレード

Mesh CA

Istio CA

ワークロードのデプロイと再デプロイ

移行を完了させる

移行

アップグレード

移行

アップグレード

ロールバック

次のステップ

マルチプロジェクトメッシュの GKE で Anthos Service Mesh をアップグレードする

インストールファイルのダウンロード