Istio から Anthos Service Mesh への移行

このページは、異なる Google Cloud プロジェクトにある複数のクラスタを含むメッシュのために、GKE クラスタで Istio 1.8 or 1.9 から Anthos Service Mesh バージョン 1.9.8 に移行する方法を説明するガイドの一部です。以前のバージョンの Istio を使用している場合は、Anthos Service Mesh に移行する前に、先にアップグレードする必要があります。アップグレードする必要がある場合は、該当する Istio のバージョンの Istio のアップグレード ページに移動します。複数のマイナー バージョンをまたいで Istio を一度にアップブレードすること（たとえば 1.6.x から 1.8.x へのアップブレード）は、公式にテストされておらず、推奨もされていません。

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

始める前に

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

移行の準備

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

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

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

認証情報と権限の設定

  1. プロジェクトを初期化してインストールの準備をします。次のコマンドでサービス アカウントを作成し、サイドカー プロキシなどのコントロール プレーン コンポーネントがプロジェクトのデータとリソースに安全にアクセスできるようにします。

    curl --request POST \
  --header "Authorization: Bearer $(gcloud auth print-access-token)" \
  --data '' \
  "https://meshconfig.googleapis.com/v1alpha1/projects/${PROJECT_ID}:initialize"

    コマンドを実行すると、空の中かっこ {} が返されます。

  2. クラスタとやり取りするために必要な認証情報を取得します。このコマンドは、クラスタに対して kubectl の現在のコンテキストも設定します。

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

  3. 現在のユーザーにクラスタ管理者の権限を付与します。この権限は、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

  1. Anthos Service Mesh インストール ファイルを現在の作業ディレクトリにダウンロードします。

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

  2. 署名ファイルをダウンロードし、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 です。

  3. ファイル システム上の任意の場所にファイルの内容を抽出します。たとえば、現在の作業ディレクトリにコンテンツを抽出するには、次のコマンドを実行します。

     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 ディレクトリにあります。

  4. Anthos Service Mesh インストールのルート ディレクトリに移動していることを確認します。

    cd istio-1.9.8-asm.6

Mac OS

  1. Anthos Service Mesh インストール ファイルを現在の作業ディレクトリにダウンロードします。

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

  2. 署名ファイルをダウンロードし、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 です。

  3. ファイル システム上の任意の場所にファイルの内容を抽出します。たとえば、現在の作業ディレクトリにコンテンツを抽出するには、次のコマンドを実行します。

    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 ディレクトリにあります。

  4. Anthos Service Mesh インストールのルート ディレクトリに移動していることを確認します。

    cd istio-1.9.8-asm.6

Windows

  1. Anthos Service Mesh インストール ファイルを現在の作業ディレクトリにダウンロードします。

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

  2. 署名ファイルをダウンロードし、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 です。

  3. ファイル システム上の任意の場所にファイルの内容を抽出します。たとえば、現在の作業ディレクトリにコンテンツを抽出するには、次のコマンドを実行します。

    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 ディレクトリにあります。

  4. Anthos Service Mesh インストールのルート ディレクトリに移動していることを確認します。

    cd istio-1.9.8-asm.6

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

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

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

Mesh CA

  1. Anthos Service Mesh パッケージのリソース構成ファイル用に新しいディレクトリを作成します。クラスタ名をディレクトリ名として使用することをおすすめします。

  2. Anthos Service Mesh パッケージをダウンロードするディレクトリに変更します。

  3. kpt のバージョンを確認します。1.x より前のバージョンの kpt を実行していることを確認します。

    kpt version

    出力例を以下に示します。

    0.39.2

    kpt のバージョンが 1.x 以上の場合は、環境の設定を参照して、ご使用のオペレーティング システムに必要なバージョンをダウンロードしてください。

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

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

  5. クラスタが作成されたプロジェクトのプロジェクト ID を設定します。

    kpt cfg set asm gcloud.core.project ${PROJECT_ID}

  6. フリート ホスト プロジェクトのプロジェクト番号を設定します。

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

  7. クラスタ名を設定します。

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

  8. デフォルトのゾーンまたはリージョンを設定します。

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

  9. インストールする Anthos Service Mesh のバージョンにタグを設定します。

    kpt cfg set asm anthos.servicemesh.tag 1.9.8-asm.6

  10. Anthos Service Mesh のパッケージ リソース構成ファイルでリビジョンを設定します。

    kpt cfg set asm anthos.servicemesh.rev asm-198-6

    Anthos Service Mesh をインストールするときに、istiod にリビジョン ラベルを設定します。検証 Webhook に同じリビジョンを設定する必要があります。

  11. マルチクラスタ構成内のクラスタは異なるプロジェクトにあるため、マルチクラスタ / マルチプロジェクトのサービスメッシュを形成する他のプロジェクトに、信頼できるドメイン エイリアスを構成する必要があります。

    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 をインストールした後、信頼ドメイン エイリアスを設定するだけでなく、クラスタ間で負荷分散を有効にする必要があります。

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

    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

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

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

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

Istio CA

  1. Anthos Service Mesh パッケージのリソース構成ファイル用に新しいディレクトリを作成します。クラスタ名をディレクトリ名として使用することをおすすめします。

  2. Anthos Service Mesh パッケージをダウンロードするディレクトリに変更します。

  3. 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)"

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

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

  5. クラスタが作成されたプロジェクトのプロジェクト ID を設定します。

    kpt cfg set asm gcloud.core.project ${PROJECT_ID}

  6. フリート ホスト プロジェクトのプロジェクト番号を設定します。

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

  7. クラスタ名を設定します。

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

  8. デフォルトのゾーンまたはリージョンを設定します。

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

  9. インストールする Anthos Service Mesh のバージョンにタグを設定します。

    kpt cfg set asm anthos.servicemesh.tag 1.9.8-asm.6

  10. Anthos Service Mesh のパッケージ リソース構成ファイルでリビジョンを設定します。

    kpt cfg set asm anthos.servicemesh.rev asm-198-6

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

    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

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

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

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

Anthos Service Mesh への移行

Mesh CA

  1. 現在の kubeconfig コンテキストが、Anthos Service Mesh をインストールするクラスタを指していることを確認します。

    kubectl config current-context

    出力は次の形式になります。

    gke_PROJECT_ID_CLUSTER_LOCATION_CLUSTER_NAME

    kubeconfig コンテキストと kpt セッターの値は一致する必要があります。必要に応じて、gcloud container clusters get-credentials コマンドを実行して、現在の kubeconfig コンテキストを設定します。

  2. 必要に応じて、istio-1.9.8-asm.6 ディレクトリに移動します。istioctl クライアントはバージョンに依存します。istio-1.9.8-asm.6/bin ディレクトリにあるバージョンを使用してください。

  3. 次のコマンドを実行し、asm-gcp-multiproject プロファイルを使用して新しいコントロール プレーンをデプロイします。サポートされているオプション機能を有効にするには、コマンドラインで -f と 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 に追加します。リビジョン ラベルは、自動サイドカー インジェクタ Webhook によって使用され、挿入されたサイドカーを特定の istiod リビジョンに関連付けます。名前空間のサイドカー自動挿入を有効にするには、istiod Deployment に一致するリビジョンにラベルを付ける必要があります。

    次のファイルは istio-operator.yaml ファイルの設定をオーバーライドします。

    • multiproject.yaml ファイルは asm-gcp-multiproject プロファイルを設定します。

    • multicluster.yaml ファイルは、マルチクラスタ構成で Anthos Service Mesh が必要とする設定を構成します。

    • revisioned-istio-ingressgateway.yaml ファイルは、istio-ingressgateway のリビジョンされた Deployment を構成します。

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

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

  5. 正規サービス コントローラをクラスタにデプロイします。

    kubectl apply -f asm/canonical-service/controller.yaml

    正規サービス コントローラは、同じ論理サービスに属するワークロードをグループ化します。正規サービスのさらに詳しい内容については、正規サービスの概要をご覧ください。

Istio CA

  1. 現在の kubeconfig コンテキストが、Anthos Service Mesh をインストールするクラスタを指していることを確認します。

    kubectl config current-context

    出力は次の形式になります。

    gke_PROJECT_ID_CLUSTER_LOCATION_CLUSTER_NAME

    kubeconfig コンテキストと kpt セッターの値は一致する必要があります。必要に応じて、gcloud container clusters get-credentials コマンドを実行して、現在の kubeconfig コンテキストを設定します。

  2. 必要に応じて、istio-1.9.8-asm.6 ディレクトリに移動します。istioctl クライアントはバージョンに依存します。istio-1.9.8-asm.6/bin ディレクトリにあるバージョンを使用してください。

  3. 次のコマンドを実行し、asm-gcp-multiproject プロファイルを使用して新しいコントロール プレーンをデプロイします。サポートされているオプション機能を有効にするには、コマンドラインで -f と 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 に追加します。リビジョン ラベルは、自動サイドカー インジェクタ Webhook によって使用され、挿入されたサイドカーを特定の istiod リビジョンに関連付けます。名前空間のサイドカー自動挿入を有効にするには、istiod Deployment に一致するリビジョンにラベルを付ける必要があります。

    次のファイルは istio-operator.yaml ファイルの設定をオーバーライドします。

    • citadel-ca.yaml は Istio CA を認証局として構成します。

    • multiproject.yaml ファイルは asm-gcp-multiproject プロファイルを設定します。

    • multicluster.yaml ファイルは、マルチクラスタ構成で Anthos Service Mesh が必要とする設定を構成します。

    • revisioned-istio-ingressgateway.yaml ファイルは、istio-ingressgateway のリビジョンされた Deployment を構成します。

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

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

  5. 正規サービス コントローラをクラスタにデプロイします。

    kubectl apply -f asm/canonical-service/controller.yaml

    正規サービス コントローラは、同じ論理サービスに属するワークロードをグループ化します。正規サービスのさらに詳しい内容については、正規サービスの概要をご覧ください。

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

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

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

istioctl install の実行時に revisioned-istio-ingressgateway.yaml を指定した場合は、istio-ingressgateway のリビジョンの Deployment が構成されます。これにより、新しいバージョンに切り替えるタイミングを管理できます。

  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-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 です。

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

  3. リビジョン ラベルを名前空間に追加し、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 ラベルの削除が含まれています。

  4. Pod を再起動してインジェクションを再度トリガーします。

    kubectl rollout restart deployment -n NAMESPACE

  5. Pod が新しいバージョンの istiod を指すように構成されていることを確認します。

    kubectl get pods -n NAMESPACE -l istio.io/rev=REVISION

  6. アプリケーションをテストして、ワークロードが正しく機能していることを確認します。

  7. 他の名前空間にワークロードがある場合は、手順を繰り返して名前空間にラベルを付け、Pod を再起動します。

  8. アプリケーションが想定どおりに動作していることを確認したら、istiod の新しいバージョンへの移行のステップに進みます。アプリケーションに問題がある場合は、次の手順に沿ってロールバックを行います。

  9. 次のコマンドをもう一度実行して、istio-ingressgateway の古いバージョンと新しいバージョンの両方が存在するか、新しいバージョンのみであることを確認します。これにより、istio-ingressgateway の新しいバージョンへの移行または古いバージョンへのロールバックの処理方法が決まります。

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

    移行を完了させる

    アプリケーションが想定どおりに動作していることを確認したら、古いコントロール プレーンを削除して新しいバージョンへの移行を完了します。

    1. anthos-service-mesh GitHub リポジトリから取得したファイルがあるディレクトリに移動します。

    2. 新しいコントロール プレーンを使用するように検証 Webhook を構成します。

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

    3. istio-ingressgateway の古いバージョンと新しいバージョンの両方がある場合は、古い 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 から移行した場合、古い 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. プロキシが Istio のバージョンになるように、Pod を再起動してインジェクションを再度トリガーします。

      kubectl rollout restart deployment -n NAMESPACE

    5. istio-ingressgateway の古いバージョンと新しいバージョンの両方がある場合は、新しい 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 コントローラが有効になります。有効にしたままにすることをおすすめしますが、無効にする場合は、正規サービス コントローラの有効化と無効化をご覧ください。

次のステップ