オンプレミスの Anthos Service Mesh のアップグレード

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

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

注意: オーバーレイ ファイルを省略すると、正常にインストールされます。ただし、値が省略されることによって、コントロール プレーンと Ingress ゲートウェイの再デプロイでは、それらの値がデフォルト値に戻されるため、サービス メッシュの構成が意図したものとは異なるものになります。

注: istioctl upgrade によるインプレース アップグレードは、Anthos Service Mesh ではサポートされていません。

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

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

重要: スクリプトを実行する場合は、すべての例に示すように --option revisioned-istio-ingressgateway を含める必要があります。このオプションでは、スクリプトはリビジョンの istio-ingressgateway Deployment を作成します。これにより、新しいバージョンに切り替えるタイミングを管理できます。このオプションを指定しない場合、スクリプトは istio-ingressgateway のインプレース アップグレードを行います。

環境設定

Anthos Service Mesh をインストールするマシンには、次のツールが必要です。Anthos Service Mesh はユーザー クラスタにのみインストールできます。管理クラスタにはインストールできません。

• curl コマンドライン ツール
• Google Cloud CLI

Google Cloud CLI をインストールした後:

1. Google Cloud CLI で認証します。

   gcloud auth login
   

2. コンポーネントを更新します。

   gcloud components update
   

3. kubectl をインストールします。

   gcloud components install kubectl
   

4. 必要とするバージョンの kpt をインストールします。

      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 のインストールと更新に gcloud を使用しないでください。必要とするバージョンの kpt をダウンロードしてください。

5. 次のようにしてコンテキストをユーザー クラスタに切り替えます。

   kubectl config use-context CLUSTER_NAME

6. ユーザー アカウント（Google Cloud ログイン メールアドレス）にクラスタ管理者の権限を付与します。この権限は、Anthos Service Mesh に必要なロールベースのアクセス制御（RBAC）ルールを作成するのに必要です。

   kubectl create clusterrolebinding cluster-admin-binding \
     --clusterrole=cluster-admin \
     --user=USER_ACCOUNT

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

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 コマンドを実行するときに、コマンドラインで revisioned-custom-ingressgateway.yaml ファイルを含めます。このファイルを使用すると、アップグレード後に新しいバージョンの istio-ingressgateway に切り替えるタイミングを制御できます。このファイルをダウンロードして構成するには、次の手順を行います。

1. anthos-service-mesh パッケージをダウンロードするディレクトリに変更します。

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

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

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

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

4. リビジョン ラベルを使用するように Webhook の検証を設定します。

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

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

Anthos Service Mesh のアップグレード

新しいバージョンの Anthos Service Mesh をインストールするには、リビジョン ベースのアップグレード プロセス（「カナリア アップグレード」とも呼ばれます）に沿って操作することをおすすめします。リビジョン ベースのアップグレードでは、既存のコントロール プレーンを残しながら、新しいバージョンのコントロール プレーンをインストールします。新しいバージョンをインストールする際は、新しいコントロール プレーンのバージョンを識別する revision ラベルを含めます。各リビジョンは、独自の Deployment と Service を持つ完全な Anthos Service Mesh コントロール プレーンの実装です。

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

コントロール プレーンの更新

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

2. 次のコマンドを実行して、新しいコントロール プレーンをデプロイします。サポートされているオプション機能を有効にするには、コマンドラインで -f と YAML のファイル名を指定します。詳細については、オプション機能の有効化をご覧ください。

   bin/istioctl install \
     --set profile=asm-multicloud \
     -f asm/istio/options/revisioned-istio-ingressgateway.yaml \
     --set revision=asm-198-6

--set revision 引数は istiod に istio.io/rev ラベルを追加します。このコマンドの実行後は、コントロール プレーンの 2 つの Deployment と Service を並行して実行できます。

kubectl get pods -n istio-system

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

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
   

   注意: istio-ingressgateway の新しいバージョンのみがある場合は、istio-ingressgateway Deployment を削除するコマンドを実行しないでください。これにより、トラフィックがサービス メッシュに入るのを防ぐことができます。

   移行を完了させる

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

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

次のステップ

• Anthos Service Mesh オンプレミスにクラスタを追加する
• サードパーティ アドオンとの統合