このガイドでは、GKE で Anthos Service Mesh をバージョン 1.5.4+ or 1.6.4+ からバージョン 1.6.14 にアップグレードする方法について説明します。Anthos Service Mesh 1.4.5 以降からアップグレードするには、まず Anthos Service Mesh 1.5 にアップグレードする必要があります。Anthos Service Mesh 1.4 から 1.6 に直接アップグレードすることはできません。
アップグレードを行う際は、デュアル コントロール プレーンのアップグレード（カナリア アップグレード）をおすすめします。ここでは、コントロール プレーンの新しいバージョンと以前のバージョンの両方を実行し、少数のワークロードで新しいバージョンのテストを行います。このアプローチはインプレース アップグレードよりも安全です。インプレース アップグレードでは、コントロール プレーンの新しいバージョンが以前のバージョンに置き換わります。istio-ingressgateway はインプレースでアップグレードされるため、クラスタの中断を計画する必要があるので注意してください。Anthos Service Mesh のコントロール プレーン コンポーネントのデプロイには 5～10 分ほどかかります。また、すべてのワークロードに新しいサイドカー プロキシを挿入し、現在の Anthos Service Mesh バージョンで更新されるようにする必要があります。サイドカー プロキシの更新にかかる時間は、Pod 数、ノード数、デプロイのスケーリング設定、Pod 中断のコスト、その他の構成要素など、さまざまな要因に左右されます。サイドカー プロキシの更新にかかる大まかな時間は 1 分あたり 100 Pod です。
アップグレードの準備を行う
このセクションでは、Anthos Service Mesh をアップグレードする際に行う準備について説明します。
サポートされている機能とこのガイドを確認して、機能とアップグレード プロセスをよく理解してください。
以前のバージョンの Anthos Service Mesh をインストールしたときにオプション機能を有効にした場合は、アップグレードするときに同じ機能を有効にする必要があります。オプション機能を有効にするには、
--set valuesフラグを追加するか、istioctl installコマンドを実行するときに YAML ファイルで-fフラグを指定します。限定公開クラスタに Anthos Service Mesh をインストールする場合は、ファイアウォールでポート 15017 を開き、自動サイドカー インジェクションで使用される Webhook が適切に機能する必要があります。詳細については、限定公開クラスタのポートを開くをご覧ください。
Anthos Service Mesh 1.5 からアップグレードする場合は、ロールバックが必要となる場合に備えて、次の手順を行ってください。
asm-1-5という名前のディレクトリを作成します。asm-1-5ディレクトリに 1.5 インストール ファイルをダウンロードします。ファイルの内容を
asm-1-5ディレクトリに抽出します。Anthos Service Mesh 1.5 インストールのルート ディレクトリにいることを確認します。
1.5
kptパッケージをダウンロードし、1.5istio-operator.yamlを構成します。
環境設定
Google Kubernetes Engine へのインストールは、インストール ガイドに沿って行います。インストールは、Cloud Shell、Google Cloud リソースに対するブラウザ内コマンドライン インターフェース、Linux または macOS を実行している独自のコンピュータを使用して行うことができます。
オプション A: Cloud Shell を使用する
Cloud Shell は、Debian ベースの Linux オペレーティング システムを実行している g1-small Compute Engine 仮想マシン（VM）をプロビジョニングします。Cloud Shell を使用する利点は次のとおりです。
Cloud Shell には、必要な
gcloud、kubectl、helmコマンドライン ツールが含まれています。Cloud Shell の $HOME ディレクトリには 5 GB の永続ストレージ スペースがあります。
テキスト エディタを選択できます。
コードエディタ。Cloud Shell ウィンドウの上部にある をクリックしてアクセスします。
Emacs、Vim、Nano。Cloud Shell のコマンドラインからアクセスします。
Cloud Shell を使用するには:
- Google Cloud コンソールに移動します。
- Google Cloud プロジェクトを選択します。
Google Cloud コンソール ウィンドウの上部にある [Cloud Shell をアクティブにする] ボタンをクリックします。
Google Cloud コンソールの一番下にある新しいフレームの中で Cloud Shell セッションが開き、コマンドライン プロンプトが表示されます。
コンポーネントを更新します。
gcloud components update次のような出力が返されます。
ERROR: (gcloud.components.update) You cannot perform this action because the gcloud CLI component manager is disabled for this installation. You can run the following command to achieve the same result for this installation: sudo apt-get update && sudo apt-get --only-upgrade install ...
long コマンドをコピーし、貼り付けてコンポーネントを更新します。
kptから検出できるように、パスに Git を設定します。
オプション B: ローカルのコマンドライン ツールを使用する
ローカルマシンに gcloud CLI をインストールして初期化します。
gcloud CLI がすでにインストールされている場合は、次の手順を行います。
gcloud CLI を使用して認証します。
gcloud auth loginコンポーネントを更新します。
gcloud components updatekubectlをインストールします。gcloud components install kubectlkptをインストールします。gcloud components install kptkptから検出できるように、パスに Git を設定します。
環境変数の設定
クラスタが作成されたプロジェクトのプロジェクト ID と、フリートのホスト プロジェクトのプロジェクト番号を取得します。
gcloud
次のコマンドを実行します。
gcloud projects listコンソール
Google Cloud コンソールの [ダッシュボード] ページに移動します。
ページ上部の [選択元] プルダウン リストをクリックします。表示された [選択元] ウィンドウで、プロジェクトを選択します。
プロジェクト ID は、プロジェクト ダッシュボードの [プロジェクト情報] カードに表示されます。
クラスタが作成されたプロジェクトのプロジェクト ID の環境変数を作成します。
export PROJECT_ID=YOUR_PROJECT_ID
フリートのホスト プロジェクトのプロジェクト番号の環境変数を作成します。
export FLEET_PROJECT_NUMBER=YOUR_FLEET_PROJECT_NUMBER
次の環境変数を作成します。
クラスタ名を設定します。
export CLUSTER_NAME=YOUR_CLUSTER_NAME
CLUSTER_LOCATIONをクラスタのゾーンまたはリージョンに設定します。export CLUSTER_LOCATION=YOUR_ZONE_OR_REGION
クラスタのメッシュ ID を変更する（省略可）
サービス メッシュに異なるプロジェクトの複数のクラスタが含まれているか、含まれる予定がある場合は、すべてのクラスタに同じメッシュ ID が設定されている必要があります。この ID は、フリートのホスト プロジェクトのプロジェクト番号に基づいて設定されます。クラスタのメッシュ ID は、Anthos Service Mesh が使用するメッシュ ID と一致する必要があります。
クラスタが 1 つしかない場合、またはサービス メッシュに同じプロジェクトのクラスタしか含まれていないか、同じプロジェクトのクラスタを追加する場合は、次の手順をスキップして、認証情報と権限の設定を行ってください。
クラスタに新しいメッシュ ID ラベルを設定するには:
メッシュ ID の環境変数を作成します。
export MESH_ID="proj-${FLEET_PROJECT_NUMBER}"クラスタの既存のラベルを残す場合は、
mesh_idラベルの追加時にそれらのラベルを含める必要があります。クラスタに既存のラベルがあるかどうかを確認するには:
gcloud container clusters describe ${CLUSTER_NAME} \ --project ${PROJECT_ID}出力で
resourceLabelsフィールドを探します。ラベルは、resourceLabelsフィールドごとに別々の行に格納されます。次に例を示します。resourceLabels: csm: '' env: dev release: stable
既存の
mesh_idを保持する必要はありません。新しいmesh_idラベルで上書きします。利便性を考えて、環境変数にラベルを追加することもできます。以下の例の
YOUR_EXISTING_LABELSは、クラスタに存在するラベルのカンマ区切りのリスト（KEY=VALUE形式、たとえばenv=dev,release=stable）で置き換えます。export EXISTING_LABELS="YOUR_EXISTING_LABELS"
mesh_idラベルを設定します。クラスタの既存のラベルを残す場合は、
mesh_idと既存のラベルでクラスタを更新します。gcloud container clusters update ${CLUSTER_NAME} \ --project ${PROJECT_ID} --update-labels=mesh_id=${MESH_ID},${EXISTING_LABELS}クラスタに既存のラベルがない場合は、新しい
mesh_idラベルだけでクラスタを更新します。gcloud container clusters update ${CLUSTER_NAME} \ --project=${PROJECT_ID} \ --update-labels=mesh_id=${MESH_ID}
認証情報と権限の設定
クラスタとやり取りするために必要な認証情報を取得します。
gcloud container clusters get-credentials ${CLUSTER_NAME} \ --project=${PROJECT_ID}現在のユーザーにクラスタ管理者の権限を付与します。この権限は、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 を続行しても問題ありません。
インストール ファイルのダウンロード
- Anthos Service Mesh インストール ファイルを現在の作業ディレクトリにダウンロードします。
curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.6.14-asm.2-linux-amd64.tar.gz
- 署名ファイルをダウンロードし、
opensslを使用して署名を検証します。curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.6.14-asm.2-linux-amd64.tar.gz.1.sig openssl dgst -verify /dev/stdin -signature istio-1.6.14-asm.2-linux-amd64.tar.gz.1.sig istio-1.6.14-asm.2-linux-amd64.tar.gz <<'EOF' -----BEGIN PUBLIC KEY----- MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw== -----END PUBLIC KEY----- EOF
想定される出力は
Verified OKです。 -
ファイル システム上の任意の場所にファイルの内容を抽出します。たとえば、現在の作業ディレクトリにコンテンツを抽出するには、次のコマンドを実行します。
tar xzf istio-1.6.14-asm.2-linux-amd64.tar.gz
このコマンドにより、現在の作業ディレクトリに
istio-1.6.14-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.6.14-asm.2-osx.tar.gz
- 署名ファイルをダウンロードし、
opensslを使用して署名を検証します。curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.6.14-asm.2-osx.tar.gz.1.sig openssl dgst -sha256 -verify /dev/stdin -signature istio-1.6.14-asm.2-osx.tar.gz.1.sig istio-1.6.14-asm.2-osx.tar.gz <<'EOF' -----BEGIN PUBLIC KEY----- MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw== -----END PUBLIC KEY----- EOF
想定される出力は
Verified OKです。 -
ファイル システム上の任意の場所にファイルの内容を抽出します。たとえば、現在の作業ディレクトリにコンテンツを抽出するには、次のコマンドを実行します。
tar xzf istio-1.6.14-asm.2-osx.tar.gz
このコマンドにより、現在の作業ディレクトリに
istio-1.6.14-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.6.14-asm.2-win.zip
- 署名ファイルをダウンロードし、
opensslを使用して署名を検証します。curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.6.14-asm.2-win.zip.1.sig openssl dgst -verify - -signature istio-1.6.14-asm.2-win.zip.1.sig istio-1.6.14-asm.2-win.zip <<'EOF' -----BEGIN PUBLIC KEY----- MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw== -----END PUBLIC KEY----- EOF
想定される出力は
Verified OKです。 -
ファイル システム上の任意の場所にファイルの内容を抽出します。たとえば、現在の作業ディレクトリにコンテンツを抽出するには、次のコマンドを実行します。
tar xzf istio-1.6.14-asm.2-win.zip
このコマンドにより、現在の作業ディレクトリに
istio-1.6.14-asm.2という名前のインストール ディレクトリが作成されます。このディレクトリには、次のものが含まれます。samplesディレクトリにあるサンプル アプリケーション- Anthos Service Mesh のインストールに使用する
istioctlコマンドライン ツールは、binディレクトリにあります。 - Anthos Service Mesh 構成プロファイルは
manifests/profilesディレクトリにあります。
- Anthos Service Mesh インストールのルート ディレクトリに移動していることを確認します。
cd istio-1.6.14-asm.2
- 利便性を考えて、
/binディレクトリ内のツールを PATH に追加します。export PATH=$PWD/bin:$PATH
Linux
Mac OS
Windows
リソース構成ファイルの準備
istioctl install コマンドを実行するときは、コマンドラインで -f istio-operator.yaml を指定します。このファイルには、Anthos Service Mesh で必要なプロジェクトとクラスタに関する情報が含まれています。プロジェクトとクラスタの情報を設定できるように、istio-operator.yaml と他のリソース構成ファイルを含むパッケージをダウンロードする必要があります。
開始するには、使用する認証局（CA）に基づいてダウンロードするパッケージを選択します。
asm: thumb_up_alt このパッケージは新規インストールに推奨される Mesh CA を有効にします。asm-citadel: 必要に応じて、Citadel を CA として有効にすることもできます。このパッケージを選択する前に、認証局の選択で詳細をご確認ください。
リソース構成ファイルを準備するには:
Anthos Service Mesh パッケージのリソース構成ファイル用に新しいディレクトリを作成します。クラスタ名をディレクトリ名として使用することをおすすめします。
Anthos Service Mesh パッケージをダウンロードするディレクトリに変更します。
CA に基づいて、使用するパッケージをダウンロードします。
Mesh CA
asmパッケージをダウンロードします。これにより、Mesh CA が有効になります。kpt pkg get \ https://github.com/GoogleCloudPlatform/anthos-service-mesh-packages.git/asm@release-1.6-asm asmCitadel
asm-citadelパッケージをダウンロードします。これにより、Citadel が CA として使用できるようになります。kpt pkg get \ https://github.com/GoogleCloudPlatform/anthos-service-mesh-packages.git/asm-citadel@release-1.6-asm asmクラスタが作成されたプロジェクトのプロジェクト ID を設定します。
kpt cfg set asm gcloud.core.project ${PROJECT_ID}フリート ホスト プロジェクトのプロジェクト番号を設定します。
kpt cfg set asm gcloud.project.environProjectNumber ${FLEET_PROJECT_NUMBER}クラスタ名を設定します。
kpt cfg set asm gcloud.container.cluster ${CLUSTER_NAME}デフォルトのゾーンまたはリージョンを設定します。
kpt cfg set asm gcloud.compute.location ${CLUSTER_LOCATION}使用する構成プロファイルを設定します。
すべてのクラスタが同じプロジェクトにある場合、
asm-gcpプロファイルを設定します。kpt cfg set asm anthos.servicemesh.profile asm-gcpサービス メッシュに別のプロジェクトのクラスタが含まれている場合は、
asm-gcp-multiprojectプロファイルを設定します（ベータ版）。kpt cfg set asm anthos.servicemesh.profile asm-gcp-multiproject
asm-gcp-multiprojectプロファイルを設定してasmパッケージをダウンロードすると、Mesh CA が有効になります。その場合、マルチクラスタ / マルチプロジェクトのサービス メッシュを形成する他のプロジェクトに信頼ドメイン エイリアスを構成する必要があります。それ以外の場合は、この手順をスキップします。マルチクラスタ / マルチプロジェクト メッシュに含まれるすべてのクラスタのプロジェクト ID を取得します。
各クラスタのプロジェクト 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 をインストールした後、信頼ドメイン エイリアスを設定するだけでなく、クラスタ間で負荷分散を有効にする必要があります。
kptセッターの値を出力します。kpt cfg list-setters asmコマンドの出力で、次のセッターの値が正しいことを確認します。
- gcloud.compute.location
- gcloud.container.cluster
- gcloud.core.project
- gcloud.project.environProjectNumber
Anthos Service Mesh の更新
新しいバージョンの Anthos Service Mesh をインストールするには、デュアル コントロール プレーンのアップグレード プロセス（Istio ドキュメントではカナリア アップグレード）に沿って操作することをおすすめします。デュアル コントロール プレーンのアップグレードでは、既存のコントロール プレーンを残しながら、新しいバージョンのコントロール プレーンをインストールします。新しいバージョンをインストールする際は、新しいコントロール プレーンのバージョンを識別する revision ラベルを含めます。各リビジョンは、独自の Deployment と Service を持つ完全な Anthos Service Mesh コントロール プレーンの実装です。
新しいコントロール プレーンを参照するようにワークロードに同じ revision ラベルを設定し、ローリング再起動を行い、新しい Anthos Service Mesh バージョンでプロキシを再挿入して新しいバージョンに移行します。この方法では、少数のワークロードでアップグレードの効果をモニタリングできます。アプリケーションのテスト後に、すべてのトラフィックを新しいバージョンに移行できます。これは、インプレース アップグレードを行うよりもはるかに安全です。インプレース アップグレードでは、以前のバージョンのコントロール プレーンが新しいコントロール プレーンで置き換わります。
コントロール プレーンの更新
次のコマンドを実行して、istio-operator.yaml ファイルで設定した構成プロファイルを使用して新しいコントロール プレーンをデプロイします。サポートされているオプション機能を有効にするには、コマンドラインで -f と YAML のファイル名を指定します。詳細については、オプション機能の有効化をご覧ください。
istioctl install \
-f asm/cluster/istio-operator.yaml \
--set revision=asm-1614-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-1614-2-6d5cfd4b89-xztlr 1/1 Running 0 3m44s istiod-fb7f746f4-wcntn 1/1 Running 0 50m
ワークロードの再デプロイ
新しいリビジョンをインストールしても、既存のサイドカー プロキシには影響しません。これらをアップグレードするには、新しいコントロール プレーンを指すように構成する必要があります。これは、名前空間ラベル istio.io/rev に基づいたサイドカー インジェクションで制御されます。
新しい Anthos Service Mesh バージョンで挿入されるワークロードを更新します。
kubectl label namespace NAMESPACE istio-injection- istio.io/rev=asm-1614-2 --overwrite
istio.io/revラベルよりも優先されるため、istio-injectionラベルは削除する必要があります。Pod を再起動してインジェクションを再度トリガーします。
kubectl rollout restart deployment -n NAMESPACE
Pod が
istiod-asm-1614-2コントロール プレーンを参照するように構成されていることを確認します。kubectl get pods -n NAMESPACE -l istio.io/rev=asm-1614-2
アプリケーションをテストして、ワークロードが正しく機能していることを確認します。
他の名前空間にワークロードがある場合は、各名前空間に対して前の手順を繰り返します。
アプリケーションが期待どおりに機能していることを確認したら、アップグレードを完了するに進みます。それ以外の場合は、次の手順で以前のバージョンにロールバックします。
コントロール プレーンの以前のバージョンで挿入されるワークロードを更新します。
kubectl label namespace NAMESPACE istio.io/rev- istio-injection=enabled --overwrite
プロキシが Istio のバージョンになるように、Pod を再起動してインジェクションを再度トリガーします。
kubectl rollout restart deployment -n NAMESPACE
コントロール プレーン コンポーネントをロールバックします。
以前の 1.6 にロールバックする
以前のバージョンの
istio-ingressgatewayを再デプロイします。kubectl -n istio-system rollout undo deploy istio-ingressgateway新しいコントロール プレーンを削除します。
kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-asm-1614-2 -n istio-system --ignore-not-found=true
1.5 にロールバックする
1.5 Anthos Service Mesh インストール ファイルをダウンロードしたディレクトリに移動します。
以前のバージョンの Anthos Service Mesh を再インストールします。オプション機能を有効にした場合は、次のコマンドで該当する
--set valuesフラグまたは-fフラグ（YAML ファイル名）を指定してください。bin/istioctl install \ -f asm/cluster/istio-operator.yaml
アップグレードを完了する
アプリケーションが想定どおりに機能していることを確認したら、次の手順でアップグレードを完了します。
古いコントロール プレーンを削除します。
kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod -n istio-system --ignore-not-found=true次のコマンドを実行して、Canonical Service コントローラをデプロイします。
kubectl apply -f asm/canonical-service/controller.yaml
このコマンドでは、Canonical Service コントローラをクラスタにデプロイします。Canonical Service コントローラは、同じ論理サービスに属するワークロードをグループにまとめ、Google Cloud コンソールのサービス ダッシュボードで追加機能のロックを解除する必要があります。詳細については、Canonical Service コントローラの有効化と無効化をご覧ください。