このガイドでは、Google Kubernetes Engine で Anthos Service Mesh を 1.5.10 から 1.4.10 にダウングレードする方法について説明します。
Anthos Service Mesh のコントロール プレーン コンポーネントのデプロイには 5～10 分ほどかかります。また、すべてのワークロードに新しいサイドカー プロキシを挿入し、現在の Anthos Service Mesh バージョンで更新されるようにする必要があります。サイドカー プロキシの更新にかかる時間は、Pod 数、ノード数、デプロイのスケーリング設定、Pod 中断のコスト、その他の構成要素など、さまざまな要因に左右されます。サイドカー プロキシの更新にかかる大まかな時間は 1 分あたり 100 Pod です。
ダウングレードの概要
このセクションでは、Anthos Service Mesh のダウングレード手順を説明します。
サポートされている機能とこのガイドを確認して、機能とダウングレード プロセスをよく理解してください。
以前のバージョンの Anthos Service Mesh をインストールしたときにオプション機能を有効にした場合は、ダウングレードするときに同じ機能を有効にする必要があります。オプション機能を有効にするには、
--set valuesフラグを追加するか、istioctl applyコマンドを実行するときに YAML ファイルで-fフラグを指定します。Anthos Service Mesh の 1.5.10 から 1.4.10 にダウングレードし、YAML ファイルでオプション機能を有効にしている場合は、YAML ファイルを IstioOperator API から IstioControlPlane API に変換する必要があります。
限定公開クラスタの 1.4.10 にダウングレードする場合に、自動サイドカー インジェクションを使用するには、ポート 9443 を開くファイアウォール ルールを追加する必要があります。ファイアウォール ルールを追加せず、自動サイドカー インジェクションを有効にすると、ワークロードのデプロイでエラーが発生します。ファイアウォール ルールの追加方法については、特定のユースケースに対するファイアウォール ルールの追加をご覧ください。
ダウンタイムをスケジュール設定します。クラスタのスケールによりますが、ダウングレードには最大 1 時間かかります。これには、ワークロードを再デプロイしてサイドカー プロキシを更新するために必要な時間は含まれません。
プロジェクトとクラスタのデフォルトの設定
クラスタが作成されたプロジェクトのプロジェクト ID を取得します。
gcloud
gcloud projects list
コンソール
Google Cloud コンソールで、[ダッシュボード] ページに移動します。
ページ上部の [選択元] プルダウン リストをクリックします。表示された [選択元] ウィンドウで、プロジェクトを選択します。プロジェクト ID は、プロジェクト ダッシュボードの [プロジェクト情報] カードに表示されます。
プロジェクト ID の環境変数を作成します。
export PROJECT_ID=
YOUR_PROJECT_IDGoogle Cloud CLI のデフォルトのプロジェクト ID を設定します。
gcloud config set project ${PROJECT_ID}次の環境変数を作成します。
クラスタ名を設定します。
export CLUSTER_NAME=YOUR_CLUSTER_NAME
CLUSTER_LOCATIONをクラスタのゾーンまたはリージョンに設定します。export CLUSTER_LOCATION=YOUR_ZONE_OR_REGION
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です。 -
ファイル システム上の任意の場所にファイルの内容を抽出します。たとえば、現在の作業ディレクトリにコンテンツを抽出するには、次のコマンドを実行します。
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 インストール ファイルを現在の作業ディレクトリにダウンロードします。
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です。 -
ファイル システム上の任意の場所にファイルの内容を抽出します。たとえば、現在の作業ディレクトリにコンテンツを抽出するには、次のコマンドを実行します。
tar xzf istio-1.4.10-asm.18-osx.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 インストール ファイルを現在の作業ディレクトリにダウンロードします。
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-win.zip
このコマンドにより、現在の作業ディレクトリに
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
ウィンドウ
リソース構成ファイルの準備
istioctl apply command を実行して Anthos Service Mesh をダウングレードする場合は、コマンドラインで -f istio-operator.yaml を指定します。このファイルには、メッシュ テレメトリーとメッシュ セキュリティの機能を有効にするために必要なプロジェクトとクラスタに関する情報が含まれます。istio-operator.yaml と他のリソース構成ファイルをダウンロードして、プロジェクトとクラスタの情報を設定する必要があります。
リソース構成ファイルを準備するには:
まだ行っていない場合は、
kptをインストールします。gcloud components install kpt必要に応じて、Anthos Service Mesh パッケージのリソース構成ファイル用に新しいディレクトリを作成します。複数のクラスタを設定する場合は、クラスタ名をディレクトリ名として使用できます。
Anthos Service Mesh パッケージをダウンロードするディレクトリに変更します。
Anthos Service Mesh パッケージを現在の作業ディレクトリにダウンロードします。
kpt pkg get \ https://github.com/GoogleCloudPlatform/anthos-service-mesh-packages.git/asm@release-1.4-asm .クラスタ名を設定します。
kpt cfg set asm cluster-name ${CLUSTER_NAME}必要に応じて、
kptセッターを使用してリソース構成ファイルをカスタマイズします。デフォルトでは、これらのセッターはgcloud configのデフォルトを使用します。gcloud configのデフォルトを設定する場合、または値を変更する場合は、次のセッターを実行します。プロジェクト ID を設定します。
kpt cfg set asm gcloud.core.project ${PROJECT_ID}デフォルトのゾーンまたはリージョンを設定します。
kpt cfg set asm gcloud.compute.zone ${CLUSTER_LOCATION}
また、リソース構成ファイルを Cloud Source Repositories などの独自のソース管理システムにチェックインして、ファイルの変更をトラッキングすることもできます。
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 \ -f asm/cluster/istio-operator.yaml
STRICT mTLS
istioctl manifest apply --set profile=asm \ -f asm/cluster/istio-operator.yaml \ --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成功すると、次のような出力が返されます。
Using Kubernetes context: meshci145g-20200219_us-central1-a_meshci145g To change the context, use the --context flag Validating enabled APIs OK Validating Node-Agent configuration OK Validating Istio system OK Validating issued certs OK Validating sample traffic Launching example services... Sent traffic to example service http code: 200 verified mTLS configuration 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 ...