バージョン 1.11

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

このガイドでは、Anthos clusters on VMware で、バージョン 1.9 or a 1.10 patch release からバージョン 1.11.2 に Anthos Service Mesh をアップグレードする方法について説明します。これより前のバージョンからのアップグレードはサポートされていません。以前のバージョンがあり、アップグレードが必要な場合は、以前のバージョンからアップグレードするをご覧ください。

アップグレードする際は、リビジョン ベースのアップグレード(「カナリア アップグレード」とも呼ばれます)を行うことをおすすめします。この方法では、ワークロードのわずかな割合を新しいバージョンのテストに使用しながら、新しいバージョンと以前のバージョンの両方のコントロール プレーンが実行されます。このアプローチはインプレース アップグレードよりも安全です。インプレース アップグレードでは、コントロール プレーンの新しいバージョンが以前のバージョンに置き換わります。なお、istio-ingressgateway はインプレースでアップグレードされるため、クラスタの中断を考慮する必要があります。

Anthos Service Mesh のコントロール プレーン コンポーネントのデプロイには 5~10 分ほどかかります。また、すべてのワークロードに新しいサイドカー プロキシを挿入し、現在の Anthos Service Mesh バージョンで更新されるようにする必要があります。サイドカー プロキシの更新にかかる時間は、Pod 数、ノード数、デプロイのスケーリング設定、Pod 中断のコスト、その他の構成要素など、さまざまな要因に左右されます。サイドカー プロキシの更新にかかる大まかな時間は 1 分あたり 100 Pod です。

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

以前のインストールをカスタマイズした場合は、Anthos Service Mesh にアップグレードする際に、同じカスタマイズを行う必要があります。--set values フラグを istioctl install に追加してインストールをカスタマイズした場合は、これらの設定を IstioOperator YAML ファイルに追加することをおすすめします(--set_values フラグを引き続き使用することもできます)。インストールをカスタマイズするには、istioctl install コマンドの実行時に YAML ファイルで -f フラグを指定します。

環境設定

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

  • curl コマンドライン ツール
  • Cloud SDKgcloud コマンドライン ツール)

Cloud SDK をインストールしたら、次の手順を実施します。

  1. Cloud SDK で認証します。

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

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

    gcloud components install kubectl
    
  4. kpt をインストールします。

    gcloud components install 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.11.2-asm.17-linux-amd64.tar.gz
  2. 署名ファイルをダウンロードし、openssl を使用して署名を検証します。

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

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

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

     tar xzf istio-1.11.2-asm.17-linux-amd64.tar.gz

    このコマンドにより、現在の作業ディレクトリに istio-1.11.2-asm.17 という名前のインストール ディレクトリが作成されます。このディレクトリには、次のものが含まれます。

    • samples ディレクトリにあるサンプル アプリケーション。
    • Anthos Service Mesh のインストールに使用する istioctl コマンドライン ツールは、bin ディレクトリにあります。
    • Anthos Service Mesh 構成プロファイルは manifests/profiles ディレクトリにあります。
  4. Anthos Service Mesh インストールのルート ディレクトリに移動していることを確認します。

    cd istio-1.11.2-asm.17

Mac OS

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

    curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.11.2-asm.17-osx.tar.gz
  2. 署名ファイルをダウンロードし、openssl を使用して署名を検証します。

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

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

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

    tar xzf istio-1.11.2-asm.17-osx.tar.gz

    このコマンドにより、現在の作業ディレクトリに istio-1.11.2-asm.17 という名前のインストール ディレクトリが作成されます。このディレクトリには、次のものが含まれます。

    • samples ディレクトリにあるサンプル アプリケーション。
    • Anthos Service Mesh のインストールに使用する istioctl コマンドライン ツールは、bin ディレクトリにあります。
    • Anthos Service Mesh 構成プロファイルは manifests/profiles ディレクトリにあります。
  4. Anthos Service Mesh インストールのルート ディレクトリに移動していることを確認します。

    cd istio-1.11.2-asm.17

Windows

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

    curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.11.2-asm.17-win.zip
  2. 署名ファイルをダウンロードし、openssl を使用して署名を検証します。

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

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

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

    tar xzf istio-1.11.2-asm.17-win.zip

    このコマンドにより、現在の作業ディレクトリに istio-1.11.2-asm.17 という名前のインストール ディレクトリが作成されます。このディレクトリには、次のものが含まれます。

    • samples ディレクトリにあるサンプル アプリケーション。
    • Anthos Service Mesh のインストールに使用する istioctl コマンドライン ツールは、bin ディレクトリにあります。
    • Anthos Service Mesh 構成プロファイルは manifests/profiles ディレクトリにあります。
  4. Anthos Service Mesh インストールのルート ディレクトリに移動していることを確認します。

    cd istio-1.11.2-asm.17

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

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.11 asm
    
  3. インストールする Anthos Service Mesh のバージョンにタグを設定します。

    kpt cfg set asm anthos.servicemesh.tag 1.11.2-asm.17
    
  4. リビジョン ラベルを使用するように Webhook の検証を設定します。

    kpt cfg set asm anthos.servicemesh.rev asm-1112-17
    

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

Anthos Service Mesh のアップグレード

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

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

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

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

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

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

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

kubectl get pods -n istio-system

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

  1. istiodistio-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-1112-17
    istio-ingressgateway-asm-182-2-8b5fc8767-hn4w2   1/1     Running   0          20s   asm-1112-17
    istiod-asm-176-1-67998f4b55-lrzpz                1/1     Running   0          68m   asm-1104-14
    istiod-asm-176-1-67998f4b55-r76kr                1/1     Running   0          68m   asm-1104-14
    istiod-asm-182-2-5cd96f88f6-n7tj9                1/1     Running   0          27s   asm-1112-17
    istiod-asm-182-2-5cd96f88f6-wm68b                1/1     Running   0          27s   asm-1112-17
    1. 出力の REV 列にある、新しいバージョンのリビジョン ラベルの値をメモします。この例での値は asm-1112-17 です。

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

  2. 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 ラベルを削除します(ある場合)。次のコマンドで、REVISIONistiod の新しいリビジョンと一致する値に変更します。

    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 の新しいバージョンへの移行のステップに進みます。アプリケーションに問題がある場合は、次の手順に沿ってロールバックを行います。

    移行を完了させる

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

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

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

      kubectl apply -f asm/istio/istiod-service.yaml
      
    3. 古い istio-ingressgateway Deployment を削除します。次のコマンドの 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 を削除します。次のコマンドの 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-ingressgatewqy を古いバージョンに戻します。次のコマンドの 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 を再デプロイします。

      kubectl -n istio-system rollout undo deploy istio-ingressgateway
      

      成功時に想定される出力:

      deployment.apps/istio-ingressgateway rolled back
    6. 新しい istio-ingressgateway Deployment を削除します。次のコマンドの REVISION の値が正しいことを確認します。

      kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=REVISION -n istio-system --ignore-not-found=true
      
    7. istiod の新しいバージョンを削除します。次のコマンドの REVISION の値が正しいことを確認します。

      kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-REVISION -n istio-system --ignore-not-found=true
      
    8. 新しいバージョンの IstioOperator 構成を削除します。

      kubectl delete IstioOperator installed-state-REVISION -n istio-system
      

      予想される出力は次のようになります。

      istiooperator.install.istio.io "installed-state-REVISION" deleted
    9. --disable_canonical_service フラグを含めなかった場合、スクリプトで Canonical Service コントローラが有効になります。有効にしたままにすることをおすすめしますが、無効にする場合は、正規サービス コントローラの有効化と無効化をご覧ください。

次のステップ