このガイドでは、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 をインストールしたら、次の手順を実施します。
Cloud SDK で認証します。
gcloud auth login
コンポーネントを更新します。
gcloud components update
kubectl
をインストールします。gcloud components install kubectl
Online Boutique のサンプル アプリケーションでインストールをデプロイしてテストする場合は、
kpt
をインストールします。gcloud components install kpt
次のようにしてコンテキストをユーザー クラスタに切り替えます。
kubectl config use-context CLUSTER_NAME
ユーザー アカウント(Google Cloud ログイン メールアドレス)にクラスタ管理者の権限を付与します。この権限は、Anthos Service Mesh に必要なロールベースのアクセス制御(RBAC)ルールを作成するのに必要です。
kubectl create clusterrolebinding cluster-admin-binding \ --clusterrole=cluster-admin \ --user=USER_ACCOUNT
インストール ファイルのダウンロード
- Anthos Service Mesh インストール ファイルを現在の作業ディレクトリにダウンロードします。
curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.8.3-asm.2-linux-amd64.tar.gz
- 署名ファイルをダウンロードし、
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
です。 -
ファイル システム上の任意の場所にファイルの内容を抽出します。たとえば、現在の作業ディレクトリにコンテンツを抽出するには、次のコマンドを実行します。
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
ディレクトリにあります。
- Anthos Service Mesh インストール ファイルを現在の作業ディレクトリにダウンロードします。
curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.8.3-asm.2-osx.tar.gz
- 署名ファイルをダウンロードし、
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
です。 -
ファイル システム上の任意の場所にファイルの内容を抽出します。たとえば、現在の作業ディレクトリにコンテンツを抽出するには、次のコマンドを実行します。
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
ディレクトリにあります。
- Anthos Service Mesh インストール ファイルを現在の作業ディレクトリにダウンロードします。
curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.8.3-asm.2-win.zip
- 署名ファイルをダウンロードし、
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
です。 -
ファイル システム上の任意の場所にファイルの内容を抽出します。たとえば、現在の作業ディレクトリにコンテンツを抽出するには、次のコマンドを実行します。
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
ディレクトリにあります。
- Anthos Service Mesh インストールのルート ディレクトリに移動していることを確認します。
cd istio-1.8.3-asm.2
- 利便性を考えて、
/bin
ディレクトリ内のツールを PATH に追加します。export PATH=$PWD/bin:$PATH
Linux
Mac OS
Windows
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 を再起動する必要があります。
自動挿入の有効化
自動挿入を有効にする手順は次のとおりです。
次のコマンドを使用して、
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
出力の
LABELS
列の下で、接頭辞istio.io/rev=
に続く、新しいバージョンのistiod
リビジョン ラベルの値をメモします。この例での値はasm-183-2
です。古い
istiod
バージョンのリビジョン ラベルの値にも注意してください。 これは、新しいバージョンへのワークロードの移行を完了した後に古いバージョンのistiod
を削除するために必要です。この出力例では、istiod
の古いバージョンのリビジョン ラベルの値はdefault
です。
リビジョン ラベルを名前空間に追加し、
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
への移行を完了します。アプリケーションに問題がある場合は、次の手順に沿ってロールバックを行います。移行を完了させる
アプリケーションが想定どおりに動作していることを確認したら、古いコントロール プレーンを削除して新しいバージョンへの移行を完了します。
古いバージョンの
istiod
を削除します。次のコマンドのOLD_REVISION
は、以前のバージョンのistiod
のリビジョン ラベルに置き換えます。kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-OLD_REVISION -n istio-system --ignore-not-found=true
古いバージョンの
IstioOperator
構成を削除します。kubectl delete IstioOperator installed-state-OLD_REVISION -n istio-system
このコマンドからの出力は、次のようになります。
istiooperator.install.istio.io "installed-state-OLD_REVISION" deleted
ロールバック
新しいバージョンの
istiod
でアプリケーションをテストしたときに問題が発生した場合は、以前のバージョンにロールバックする手順は次の通りです。以前のバージョンの
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
Namespace のリビジョン ラベルが、以前のバージョンの
istiod
のリビジョン ラベルと一致していることを確認します。kubectl get ns NAMESPACE --show-labels
プロキシが以前のバージョンになるように、Pod を再起動してインジェクションを再度トリガーします。
kubectl rollout restart deployment -n NAMESPACE
以前のバージョンの
istio-ingressgateway
を再デプロイします。kubectl -n istio-system rollout undo deploy istio-ingressgateway
成功時に想定される出力:
deployment.apps/istio-ingressgateway rolled back
istiod
の新しいバージョンを削除します。次のコマンドのREVISION
の値が正しいことを確認します。kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-REVISION -n istio-system --ignore-not-found=true
新しいバージョンの
IstioOperator
構成を削除します。kubectl delete IstioOperator installed-state-REVISION -n istio-system
想定される出力は次のようになります。
istiooperator.install.istio.io "installed-state-REVISION" deleted