このガイドでは、Google Kubernetes Engine で Anthos Service Mesh をバージョン 1.4.5+ or 1.5.4+ からバージョン 1.5.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.4.5 以上からアップグレードし、YAML ファイルでオプション機能を有効にした場合は、YAML を IstioControlPlane API から IstioOperator API に変換する必要があります。
Anthos Service Mesh を限定公開クラスタでアップグレードするときに、自動サイドカー インジェクションを使用する場合は、ポート 15017 を開くファイアウォール ルールを追加する必要があります。ファイアウォール ルールを追加せず、自動サイドカー インジェクションを有効にすると、ワークロードのデプロイでエラーが発生します。ファイアウォール ルールの追加方法については、特定のユースケースに対するファイアウォール ルールの追加をご覧ください。
ダウンタイムをスケジュール設定します。クラスタのスケールによりますが、アップグレードには最大 1 時間かかります。これには、ワークロードを再デプロイしてサイドカー プロキシを更新するために必要な時間は含まれません。
1.4 リソースのプルーニング
GKE Enterprise CLI のアルファ版を使用して Anthos Service Mesh 1.4 をインストールした場合は、バージョン 1.5.10 にアップグレードする前に、1.4 リソースのプルーニングが必要になる場合があります。
Anthos Service Mesh リソースに operator.istio.io/component
ラベルがあるかどうかを確認します。
kubectl get all -n istio-system --selector operator.istio.io/component
コマンドから No resources found in istio-system namespace
が返された場合は、次のコマンドを使用して Anthos Service Mesh 1.4 リソースをプルーニングします。
kubectl delete deploy -n istio-system promsd
kubectl delete all -n istio-system --selector 'app in (galley, istio-ingressgateway, istio-nodeagent, sidecarInjectorWebhook, promsd, pilot)'
プロジェクトとクラスタのデフォルトの設定
クラスタが作成されたプロジェクトのプロジェクト ID を取得します。
gcloud
gcloud projects list
コンソール
Google Cloud コンソールで、[ダッシュボード] ページに移動します。
ページ上部の [選択元] プルダウン リストをクリックします。表示された [選択元] ウィンドウで、プロジェクトを選択します。プロジェクト ID は、プロジェクト ダッシュボードの [プロジェクト情報] カードに表示されます。
プロジェクト ID の環境変数を作成します。
export PROJECT_ID=
YOUR_PROJECT_ID
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
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.5.10-asm.2-linux.tar.gz
- 署名ファイルをダウンロードし、
openssl
を使用して署名を検証します。curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.5.10-asm.2-linux.tar.gz.1.sig openssl dgst -verify - -signature istio-1.5.10-asm.2-linux.tar.gz.1.sig istio-1.5.10-asm.2-linux.tar.gz <<'EOF' -----BEGIN PUBLIC KEY----- MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw== -----END PUBLIC KEY----- EOF
想定される出力は
Verified OK
です。 -
ファイル システム上の任意の場所にファイルの内容を抽出します。たとえば、現在の作業ディレクトリにコンテンツを抽出するには、次のコマンドを実行します。
tar xzf istio-1.5.10-asm.2-linux.tar.gz
このコマンドにより、現在の作業ディレクトリに
istio-1.5.10-asm.2
という名前のインストール ディレクトリが作成されます。このディレクトリには、次のものが含まれます。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.5.10-asm.2-osx.tar.gz
- 署名ファイルをダウンロードし、
openssl
を使用して署名を検証します。curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.5.10-asm.2-osx.tar.gz.1.sig openssl dgst -sha256 -verify /dev/stdin -signature istio-1.5.10-asm.2-osx.tar.gz.1.sig istio-1.5.10-asm.2-osx.tar.gz <<'EOF' -----BEGIN PUBLIC KEY----- MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw== -----END PUBLIC KEY----- EOF
想定される出力は
Verified OK
です。 -
ファイル システム上の任意の場所にファイルの内容を抽出します。たとえば、現在の作業ディレクトリにコンテンツを抽出するには、次のコマンドを実行します。
tar xzf istio-1.5.10-asm.2-osx.tar.gz
このコマンドにより、現在の作業ディレクトリに
istio-1.5.10-asm.2
という名前のインストール ディレクトリが作成されます。このディレクトリには、次のものが含まれます。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.5.10-asm.2-win.zip
- 署名ファイルをダウンロードし、
openssl
を使用して署名を検証します。curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.5.10-asm.2-win.zip.1.sig openssl dgst -verify - -signature istio-1.5.10-asm.2-win.zip.1.sig istio-1.5.10-asm.2-win.zip <<'EOF' -----BEGIN PUBLIC KEY----- MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw== -----END PUBLIC KEY----- EOF
想定される出力は
Verified OK
です。 -
ファイル システム上の任意の場所にファイルの内容を抽出します。たとえば、現在の作業ディレクトリにコンテンツを抽出するには、次のコマンドを実行します。
tar xzf istio-1.5.10-asm.2-win.zip
このコマンドにより、現在の作業ディレクトリに
istio-1.5.10-asm.2
という名前のインストール ディレクトリが作成されます。このディレクトリには、次のものが含まれます。samples
にはサンプル アプリケーション。bin
ディレクトリには次のツール:istioctl
:istioctl
は Anthos Service Mesh のインストールに使用します。asmctl
:asmctl
を使用して、Anthos Service Mesh をインストールした後、セキュリティ構成を検証します(現在、asmctl
は GKE on VMware ではサポートされていません)。
- Anthos Service Mesh インストールのルート ディレクトリに移動していることを確認します。
cd istio-1.5.10-asm.2
- 利便性を考えて、
/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.5-asm .
クラスタ名を設定します。
kpt cfg set asm gcloud.container.cluster ${CLUSTER_NAME}
必要に応じて、
kpt
セッターを使用してリソース構成ファイルをカスタマイズします。デフォルトでは、これらのセッターはgcloud config
のデフォルトを使用します。gcloud config
のデフォルトを設定する場合、または値を変更する場合は、次のセッターを実行します。プロジェクト ID を設定します。
kpt cfg set asm gcloud.core.project ${PROJECT_ID}
デフォルトのゾーンまたはリージョンを設定します。
kpt cfg set asm gcloud.compute.location ${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-ingressgateway-5bfdf7c586-v6wxx 2/2 Terminating 0 25m istio-ingressgateway-7b598c5557-b88md 2/2 Running 0 5m44s istiod-78cdbbbdb-d7tps 1/1 Running 0 5m16s promsd-576b8db4d6-lqf64 2/2 Running 1 5m26s
この例では、istio-ingressgateway
のインスタンスが 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.5.10-asm.2/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 ...