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

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

利用可能なバージョン

Istio から Anthos Service Mesh への移行

このページは、異なる Google Cloud プロジェクトにある複数のクラスタを含むメッシュのために、GKE クラスタで Istio から Anthos Service Mesh バージョン 1.10.6 に移行する方法を説明するガイドの一部です。以前のバージョンの Istio を使用している場合は、Anthos Service Mesh に移行する前に、先にアップグレードする必要があります。アップグレードする必要がある場合は、該当する Istio のバージョンの Istio のアップグレードページに移動します。1 つの手順で複数のマイナーバージョンをまたいで Istio をアップグレードすること（例: 1.6.x から 1.8.x）は、正式にテストまたは推奨されていないことに注意してください。

単一クラスタメッシュでの移行または同じ Google Cloud プロジェクト内の複数のクラスタを含むメッシュの場合は、GKE のインストール、移行、アップグレードをご覧ください。

< 前へ

始める前に

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

環境を設定し、必要なツールをインストールしている。
プロジェクトを設定し、必要な API を有効にして権限を設定している。
クラスタを設定し、必要なクラスタオプションを有効にしている。

移行の準備

Istio からの移行の準備を必ずご確認ください。

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

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

認証情報と権限の設定

プロジェクトを初期化してインストールの準備をします。次のコマンドでサービスアカウントを作成し、サイドカープロキシなどのコントロールプレーンコンポーネントがプロジェクトのデータとリソースに安全にアクセスできるようにします。
```
curl --request POST \
  --header "Authorization: Bearer $(gcloud auth print-access-token)" \
  --data '' \
  "https://meshconfig.googleapis.com/v1alpha1/projects/${PROJECT_ID}:initialize"
```
コマンドを実行すると、空の中かっこ {} が返されます。
クラスタとやり取りするために必要な認証情報を取得します。このコマンドは、クラスタに対して 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
istio-ingressgateway-c56675fcd-vn4nv        1/1     Running   0          2m21s
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
istio-ingressgateway-c56675fcd-vn4nv        1/1     Running   0          2m21s
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 コントローラが有効になります。有効にしたままにすることをおすすめしますが、無効にする場合は、正規サービスコントローラの有効化と無効化をご覧ください。

次のステップ

< 前へ

Istio から Anthos Service Mesh への移行

始める前に

移行の準備

認証情報と権限の設定

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

Linux

Mac OS

Windows

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

Mesh CA

Istio CA

Anthos Service Mesh への移行

Mesh CA

Istio CA

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

移行を完了させる

移行

アップグレード

移行

アップグレード

ロールバック

次のステップ

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