このガイドでは、Google Cloud 上の GKE クラスタで Anthos Service Mesh を 1.6.14 から 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 install
コマンドを実行するときに YAML ファイルで-f
フラグを指定します。限定公開クラスタで Anthos Service Mesh をダウングレードするときに、自動サイドカー インジェクションを使用する場合は、ポート 15017 を開くファイアウォール ルールを追加する必要があります。ファイアウォール ルールを追加せず、自動サイドカー インジェクションを有効にすると、ワークロードのデプロイでエラーが発生します。ファイアウォール ルールの追加方法については、特定のユースケースに対するファイアウォール ルールの追加をご覧ください。
ダウングレード
このガイドの手順を行い、Anthos Service Mesh のダウングレードを準備します。
アプリケーションをテストして、ワークロードが正しく機能していることを確認します。
環境設定
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 update
kubectl
をインストールします。gcloud components install kubectl
kpt
をインストールします。gcloud components install kpt
kpt
から検出できるように、パスに 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
認証情報と権限の設定
クラスタとのやり取りで必要な認証情報を取得します。
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.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 /dev/stdin -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
ディレクトリにあるサンプル アプリケーション- Anthos Service Mesh のインストールに使用する
istioctl
コマンドライン ツールは、bin
ディレクトリにあります。 - Anthos Service Mesh 構成プロファイルは
manifests/profiles
ディレクトリにあります。
- 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
ディレクトリにあるサンプル アプリケーション- Anthos Service Mesh のインストールに使用する
istioctl
コマンドライン ツールは、bin
ディレクトリにあります。 - Anthos Service Mesh 構成プロファイルは
manifests/profiles
ディレクトリにあります。
- 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
ディレクトリにあるサンプル アプリケーション- Anthos Service Mesh のインストールに使用する
istioctl
コマンドライン ツールは、bin
ディレクトリにあります。 - Anthos Service Mesh 構成プロファイルは
manifests/profiles
ディレクトリにあります。
- Anthos Service Mesh インストールのルート ディレクトリに移動していることを確認します。
cd istio-1.5.10-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 パッケージをダウンロードするディレクトリに変更します。
asm
パッケージをダウンロードします。kpt pkg get \ https://github.com/GoogleCloudPlatform/anthos-service-mesh-packages.git/asm@release-1.5-asm asm
クラスタが作成されたプロジェクトのプロジェクト ID を設定します。
kpt cfg set asm gcloud.core.project ${PROJECT_ID}
クラスタ名を設定します。
kpt cfg set asm gcloud.container.cluster ${CLUSTER_NAME}
デフォルトのゾーンまたはリージョンを設定します。
kpt cfg set asm gcloud.compute.location ${CLUSTER_LOCATION}
Anthos Service Mesh のダウングレード
Anthos Service Mesh をダウングレードするには:
istioctl install \ -f asm/cluster/istio-operator.yaml \ --set profile=asm-gcp
コントロール プレーン コンポーネントを確認する
ダウングレードするには、コントロール プレーン コンポーネントを再インストールする必要があります。完了するまでには約 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
のインスタンスが終了します。その他のコンポーネントはすべて、新たにインストールされます。
サイドカー プロキシの更新
ダウングレード前にクラスタで実行されていたワークロードの場合、現在の Anthos Service Mesh バージョンが使用されるように、サイドカー プロキシを再挿入する必要があります。
自動サイドカー インジェクションでは、Pod の再起動で既存の Pod のサイドカーを更新できます。Pod を再起動する方法は、Pod が Deployment の一部として作成されたかどうかによって異なります。
Deployment を使用した場合は、サイドカー付きのすべての Pod を再起動する Deployment を再起動します。
kubectl rollout restart deployment -n YOUR_NAMESPACE
Deployment を使用していない場合、Pod を削除すると、自動的にサイドカー付きで再作成されます。
kubectl delete pod -n YOUR_NAMESPACE --all
名前空間内のすべての Pod にサイドカーが挿入されたことを確認します。
kubectl get pod -n YOUR_NAMESPACE
次に前のコマンドの出力例を示します。ここで、
READY
列はワークロードごとに 2 つのコンテナ(プライマリ コンテナとサイドカー プロキシのコンテナ)があることを示しています。NAME READY STATUS RESTARTS AGE YOUR_WORKLOAD 2/2 Running 0 20s ...