このガイドでは、Google Kubernetes Engine で Anthos Service Mesh をバージョン 1.4.5+ からバージョン 1.4.10 にアップグレードする方法について説明します。Anthos Service Mesh 1.5 にアップグレードする場合は、GKE での Anthos Service Mesh のアップグレードのバージョン 1.5 をご覧ください。
Anthos Service Mesh のコントロール プレーン コンポーネントのデプロイには 5～10 分ほどかかります。また、すべてのワークロードに新しいサイドカー プロキシを挿入し、現在の Anthos Service Mesh バージョンで更新されるようにする必要があります。サイドカー プロキシの更新にかかる時間は、Pod 数、ノード数、デプロイのスケーリング設定、Pod 中断のコスト、その他の構成要素など、さまざまな要因に左右されます。サイドカー プロキシの更新にかかる大まかな時間は 1 分あたり 100 Pod です。
アップグレードの準備を行う
このセクションでは、Anthos Service Mesh のアップグレード手順を説明します。
サポートされている機能とこのガイドを確認して、機能とアップグレード プロセスをよく理解してください。
認可ポリシーで更新が必要であるかどうかを確認してください。
--set valuesフラグをistioctl applyコマンドラインに追加することによって以前のバージョンの Anthos Service Mesh をインストールする際にオプション機能を有効にした場合は、istioctl applyを実行して 1.4.10 にアップグレードする際に同じフラグを使用する必要があります。以前のバージョンの Anthos Service Mesh をインストールしたときに
-fフラグをistioctl applyコマンドラインに追加して YAML ファイルを指定した場合、istioctl applyを実行して 1.4.10 にアップグレードするときにも同じファイル（または同じコンテンツを持つファイル）を指定する必要があります。ダウンタイムをスケジュール設定します。クラスタのスケールによりますが、アップグレードには最大 1 時間かかります。これには、ワークロードを再デプロイしてサイドカー プロキシを更新するために必要な時間は含まれません。
プロジェクトとクラスタのデフォルトの設定
クラスタが作成されたプロジェクトのプロジェクト ID を取得します。
gcloud
gcloud projects list
コンソール
Google Cloud コンソールで、[ダッシュボード] ページに移動します。
ページ上部の [選択元] プルダウン リストをクリックします。表示された [選択元] ウィンドウで、プロジェクトを選択します。プロジェクト ID は、プロジェクト ダッシュボードの [プロジェクト情報] カードに表示されます。
プロジェクト ID の環境変数を作成します。
export PROJECT_ID=
YOUR_PROJECT_IDプロジェクト番号の環境変数を作成します。
export PROJECT_NUMBER=$(gcloud projects describe ${PROJECT_ID} --format="value(projectNumber)")Google Cloud CLI のデフォルトのプロジェクト ID を設定します。
gcloud config set project ${PROJECT_ID}次の環境変数を作成します。
クラスタ名を設定します。
export CLUSTER_NAME=YOUR_CLUSTER_NAME
CLUSTER_LOCATIONをクラスタのゾーンまたはリージョンに設定します。export CLUSTER_LOCATION=YOUR_ZONE_OR_REGION
ワークロード プールを設定します。
export WORKLOAD_POOL=${PROJECT_ID}.svc.id.googメッシュ ID を設定します。
export MESH_ID="proj-${PROJECT_NUMBER}"
Google Cloud CLI のデフォルトのゾーンまたはリージョンを設定します。
シングルゾーン クラスタがある場合は、デフォルト ゾーンを設定します。
gcloud config set compute/zone ${CLUSTER_LOCATION}リージョン クラスタがある場合は、デフォルト リージョンを設定します。
gcloud config set compute/region ${CLUSTER_LOCATION}
認証情報と権限の設定
-
クラスタとやり取りするために必要な認証情報を取得します。
gcloud container clusters get-credentials ${CLUSTER_NAME} -
現在のユーザーにクラスタ管理者の権限を付与します。この権限は、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.4.10-asm.18-linux.tar.gz
- 署名ファイルをダウンロードし、
opensslを使用して署名を検証します。curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.4.10-asm.18-linux.tar.gz.1.sig openssl dgst -verify - -signature istio-1.4.10-asm.18-linux.tar.gz.1.sig istio-1.4.10-asm.18-linux.tar.gz <<'EOF' -----BEGIN PUBLIC KEY----- MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw== -----END PUBLIC KEY----- EOF
想定される出力は
Verified OKです。 - Anthos Service Mesh インストール ファイルを現在の作業ディレクトリにダウンロードします。
curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.4.10-asm.18-osx.tar.gz
- 署名ファイルをダウンロードし、
opensslを使用して署名を検証します。curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.4.10-asm.18-osx.tar.gz.1.sig openssl dgst -sha256 -verify /dev/stdin -signature istio-1.4.10-asm.18-osx.tar.gz.1.sig istio-1.4.10-asm.18-osx.tar.gz <<'EOF' -----BEGIN PUBLIC KEY----- MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw== -----END PUBLIC KEY----- EOF
想定される出力は
Verified OKです。 - Anthos Service Mesh インストール ファイルを現在の作業ディレクトリにダウンロードします。
curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.4.10-asm.18-win.zip
- 署名ファイルをダウンロードし、
opensslを使用して署名を検証します。curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.4.10-asm.18-win.zip.1.sig openssl dgst -verify - -signature istio-1.4.10-asm.18-win.zip.1.sig istio-1.4.10-asm.18-win.zip <<'EOF' -----BEGIN PUBLIC KEY----- MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw== -----END PUBLIC KEY----- EOF
想定される出力は
Verified OKです。 -
ファイル システム上の任意の場所にファイルの内容を抽出します。たとえば、現在の作業ディレクトリにコンテンツを抽出するには、次のコマンドを実行します。
tar xzf istio-1.4.10-asm.18-linux.tar.gz
このコマンドにより、現在の作業ディレクトリに
istio-1.4.10-asm.18という名前のインストール ディレクトリが作成されます。このディレクトリには、次のものが含まれます。samplesにはサンプル アプリケーション。binディレクトリには次のツール:istioctl:istioctlは Anthos Service Mesh のインストールに使用します。asmctl:asmctlを使用して、Anthos Service Mesh をインストールした後、セキュリティ構成を検証します（現在、asmctlは GKE on VMware ではサポートされていません）。
- Anthos Service Mesh インストールのルート ディレクトリに移動していることを確認します。
cd istio-1.4.10-asm.18
- 利便性を考えて、
/binディレクトリ内のツールを PATH に追加します。export PATH=$PWD/bin:$PATH
Linux
Mac OS
Windows
Anthos Service Mesh のアップグレード
このセクションでは、Anthos Service Mesh をアップグレードして有効にする方法を説明します。
- サポートされている機能ページに表示されるサポートされているデフォルトの機能。
- Anthos Service Mesh の認証局（Mesh CA）。
- Google Cloud コンソールで Anthos Service Mesh ダッシュボードを強化するテレメトリー データ パイプライン。
サポートされているオプション機能の有効化については、オプション機能の有効化をご覧ください。
Anthos Service Mesh をアップグレードするには:
次のいずれかのコマンドを選択して、PERMISSIVE 相互 TLS（mTLS）認証モードまたは STRICT mTLS モードで Anthos Service Mesh を構成します。
PERMISSIVE mTLS
istioctl manifest apply --set profile=asm \
--set values.global.trustDomain=${WORKLOAD_POOL} \
--set values.global.sds.token.aud=${WORKLOAD_POOL} \
--set values.nodeagent.env.GKE_CLUSTER_URL=https://container.googleapis.com/v1/projects/${PROJECT_ID}/locations/${CLUSTER_LOCATION}/clusters/${CLUSTER_NAME} \
--set values.global.meshID=${MESH_ID} \
--set values.global.proxy.env.GCP_METADATA="${PROJECT_ID}|${PROJECT_NUMBER}|${CLUSTER_NAME}|${CLUSTER_LOCATION}"STRICT mTLS
istioctl manifest apply --set profile=asm \
--set values.global.trustDomain=${WORKLOAD_POOL} \
--set values.global.sds.token.aud=${WORKLOAD_POOL} \
--set values.nodeagent.env.GKE_CLUSTER_URL=https://container.googleapis.com/v1/projects/${PROJECT_ID}/locations/${CLUSTER_LOCATION}/clusters/${CLUSTER_NAME} \
--set values.global.meshID=${MESH_ID} \
--set values.global.proxy.env.GCP_METADATA="${PROJECT_ID}|${PROJECT_NUMBER}|${CLUSTER_NAME}|${CLUSTER_LOCATION}" \
--set values.global.mtls.enabled=trueコントロール プレーン コンポーネントを確認する
アップグレードするには、コントロール プレーン コンポーネントを再インストールする必要があります。完了するまでには約 5～10 分かかります。新しいコンポーネントがインストールされると、古いコントロール プレーン コンポーネントは終了し、削除されます。ワークロードの AGE 列の値を見ることで、進行状況を確認できます。
kubectl get pod -n istio-system
NAME READY STATUS RESTARTS AGE istio-galley-76d684bf9-jwz65 2/2 Running 0 5m36s istio-ingressgateway-5bfdf7c586-v6wxx 2/2 Terminating 0 25m istio-ingressgateway-7b598c5557-b88md 2/2 Running 0 5m44s istio-nodeagent-bnjg7 1/1 Running 0 5m16s istio-nodeagent-cps2j 1/1 Running 0 5m10s istio-nodeagent-f4x46 1/1 Running 0 5m26s istio-nodeagent-jbl5x 1/1 Running 0 5m38s istio-pilot-5dc4bc4dbf-ds5dh 2/2 Running 0 5m30s istio-pilot-74665549c5-7r6qh 2/2 Terminating 0 25m istio-sidecar-injector-7ddff4b99-b76l7 1/1 Running 0 5m36s promsd-6d4d5b7c5c-dgnd7 2/2 Running 0 5m30s
この例では、istio-ingressgateway と istio-pilot の 2 つのインスタンスが存在します。AGE 列に 25m が存在するインスタンスが強制終了されています。その他のコンポーネントはすべて、新たにインストールされます。
アップグレードの検証
asmctl 分析ツールを使用して、プロジェクト、クラスタ、ワークロードの基本構成を検証することをおすすめします。asmctl テストに失敗した場合は、可能であれば asmctl は推奨の解決策を提示します。asmctl validate コマンドは、以下を確認する基本的なテストを実行します。
- Anthos Service Mesh で必要な API がプロジェクトで有効になっている。
- Istio-Ingressgateway が Mesh CA を呼び出すよう適切に構成されている。
- Istiod と Istio-Ingressgateway の全般的な状態。
オプションの --with-testing-workloads フラグを使用して asmctl validate コマンドを実行した場合、基本テストに加えて、asmctl は以下を確認するセキュリティ テストを実行します。
- 相互 TLS（mTLS）通信が適切に構成されている。
- メッシュ CA が証明書を発行できる。
セキュリティ テストを行う際に asmctl はクラスタ上のテスト用名前空間にワークロードをデプロイします。mTLS 通信のテストを実行して結果を出力し、テスト用名前空間を削除します。
asmctl を実行するには:
gcloud application-default 認証情報が設定されていることを確認します。
gcloud auth application-default loginまだ行っていない場合は、クラスタとのやり取りに必要な認証情報を取得します。
gcloud container clusters get-credentials ${CLUSTER_NAME}基本テストとセキュリティ テストの両方を実行するには（
istio-1.4.10-asm.18/binがPATHにあると想定）:asmctl validate --with-testing-workloads成功すると、次のような出力が返されます。
[asmctl version 0.3.0] Using Kubernetes context: example-project_us-central1-example-cluster To change the context, use the --context flag Validating enabled APIs OK Validating ingressgateway configuration OK Validating istio system OK Validating sample traffic Launching example services... Sent traffic to example service http code: 200 verified mTLS configuration OK Validating issued certs OK
サイドカー プロキシの更新
Anthos Service Mesh のアップグレード前にクラスタで実行されていたワークロードの場合、現在の Anthos Service Mesh バージョンを使用するように、サイドカー プロキシを挿入または更新する必要があります。
自動サイドカー インジェクションでは、Pod の再起動で既存の Pod のサイドカーを更新できます。Pod を再起動する方法は、Pod が Deployment の一部として作成されたかどうかによって異なります。
Deployment を使用した場合は、サイドカー付きのすべての Pod を再起動する Deployment を再起動します。
kubectl rollout restart YOUR_DEPLOYMENT -n YOUR_NAMESPACE
Deployment を使用していない場合、Pod を削除すると、自動的にサイドカー付きで再作成されます。
kubectl delete pod -n YOUR_NAMESPACE --all
名前空間内のすべての Pod にサイドカーが挿入されたことを確認します。
kubectl get pod -n YOUR_NAMESPACE --all
次に前のコマンドの出力例を示します。ここで、
READY列はワークロードごとに 2 つのコンテナ（プライマリ コンテナとサイドカー プロキシのコンテナ）があることを示しています。NAME READY STATUS RESTARTS AGE YOUR_WORKLOAD 2/2 Running 0 20s ...
認可ポリシーの更新
オープンソースの Istio 1.4.x または以前のバージョンの Anthos Service Mesh からアップグレードし、既存の認可ポリシーがある場合は、更新する必要があります。詳細については、認可ポリシーの更新をご覧ください。