バージョン 1.8

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

このガイドでは、VMware 上 の Anthos クラスタで、バージョン 1.7.3+ or a 1.8 patch release からバージョン 1.8.3 に 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 SDK（gcloud コマンドライン ツール）

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

  1. Cloud SDK で認証します。

    gcloud auth login

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

    gcloud components update

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

    gcloud components install kubectl

  4. Online Boutique のサンプル アプリケーションでインストールをデプロイしてテストする場合は、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.8.3-asm.2-linux-amd64.tar.gz
  2. 署名ファイルをダウンロードし、openssl を使用して署名を検証します。
    curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.8.3-asm.2-linux-amd64.tar.gz.1.sig
openssl dgst -verify /dev/stdin -signature istio-1.8.3-asm.2-linux-amd64.tar.gz.1.sig istio-1.8.3-asm.2-linux-amd64.tar.gz <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF

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

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

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

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

    4. Mac OS

  4. Anthos Service Mesh インストール ファイルを現在の作業ディレクトリにダウンロードします。
    curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.8.3-asm.2-osx.tar.gz
  5. 署名ファイルをダウンロードし、openssl を使用して署名を検証します。
    curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.8.3-asm.2-osx.tar.gz.1.sig
openssl dgst -sha256 -verify /dev/stdin -signature istio-1.8.3-asm.2-osx.tar.gz.1.sig istio-1.8.3-asm.2-osx.tar.gz <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF

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

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

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

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

    7. Windows

  7. Anthos Service Mesh インストール ファイルを現在の作業ディレクトリにダウンロードします。
    curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.8.3-asm.2-win.zip
  8. 署名ファイルをダウンロードし、openssl を使用して署名を検証します。
    curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.8.3-asm.2-win.zip.1.sig
openssl dgst -verify - -signature istio-1.8.3-asm.2-win.zip.1.sig istio-1.8.3-asm.2-win.zip <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF

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

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

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

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

  10. Anthos Service Mesh インストールのルート ディレクトリに移動していることを確認します。
    cd istio-1.8.3-asm.2
  11. 利便性を考えて、/bin ディレクトリ内のツールを PATH に追加します。
    export PATH=$PWD/bin:$PATH

Anthos Service Mesh の更新

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

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

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

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

istioctl install \
  --set profile=asm-multicloud \
  --set revision=asm-183-2

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

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-183-2-6d5cfd4b89-xztlr       1/1     Running   0          3m44s
istiod-fb7f746f4-wcntn                      1/1     Running   0          50m
promsd-579f9f9bf4-m65nc                     2/2     Running   1          50m

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

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

自動挿入を有効にするには、istioctl install を実行したときにリビジョン ラベルを取得し、同じリビジョン ラベルで名前空間にラベルを付けます。リビジョン ラベルは、サイドカー インジェクタ Webhook によって使用され、挿入されたサイドカーを特定の istiod リビジョンに関連付けます。ラベルを追加したら、サイドカーを挿入できるように、名前空間内の既存の Pod を再起動する必要があります。

自動挿入の有効化

自動挿入を有効にする手順は次のとおりです。

  1. 次のコマンドを使用して、istiod のリビジョンラベルを探します。

    kubectl -n istio-system get pods -l app=istiod --show-labels

    このコマンドからの出力は、次のようになります。 移行による出力は、アップグレードとは少し異なります。次の出力例は、移行によるものです。

    NAME                                READY   STATUS    RESTARTS   AGE   LABELS
istiod-7744bc8dd7-qhlss             1/1     Running   0          49m   app=istiod,istio.io/rev=default,istio=pilot,pod-template-hash=7744bc8dd7
istiod-asm-183-2-85d86774f7-flrt2   1/1     Running   0          26m   app=istiod,istio.io/rev=asm-183-2,istio=istiod,pod-template-hash=85d86774f7
istiod-asm-183-2-85d86774f7-tcwtn   1/1     Running   0          26m   app=istiod,istio.io/rev=asm-183-2,istio=istiod,pod-template-hash=85d86774f7

    1. 出力の LABELS 列の下で、接頭辞 istio.io/rev= に続く、新しいバージョンの istiod リビジョン ラベルの値をメモします。この例での値は asm-183-2 です。

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

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

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

    kubectl rollout restart deployment -n NAMESPACE

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

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

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

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

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

    移行を完了させる

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

    1. 古いバージョンの istiod を削除します。次のコマンドの OLD_REVISION は、以前のバージョンの istiod のリビジョン ラベルに置き換えます。

      kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-OLD_REVISION -n istio-system --ignore-not-found=true

    2. 古いバージョンの IstioOperator 構成を削除します。

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

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

      istiooperator.install.istio.io "installed-state-OLD_REVISION" deleted

    ロールバック

    新しいバージョンの istiod でアプリケーションをテストしたときに問題が発生した場合は、以前のバージョンにロールバックする手順は次の通りです。

    1. 以前のバージョンの istiod で自動挿入を有効にする場合は、Namespace に再びラベルを付けます。使用するコマンドは、リビジョン ラベルと以前のバージョンの 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

    2. Namespace のリビジョン ラベルが、以前のバージョンの istiod のリビジョン ラベルと一致していることを確認します。

      kubectl get ns NAMESPACE --show-labels

    3. プロキシが以前のバージョンになるように、Pod を再起動してインジェクションを再度トリガーします。

      kubectl rollout restart deployment -n NAMESPACE

    4. 以前のバージョンの istio-ingressgateway を再デプロイします。

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

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

      deployment.apps/istio-ingressgateway rolled back

    5. istiod の新しいバージョンを削除します。次のコマンドの REVISION の値が正しいことを確認します。

      kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-REVISION -n istio-system --ignore-not-found=true

    6. 新しいバージョンの IstioOperator 構成を削除します。

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

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

      istiooperator.install.istio.io "installed-state-REVISION" deleted

次のステップ