オンプレミスの Anthos Service Mesh のダウングレード

このガイドでは、VMware 上の Anthos クラスタで 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 のダウングレード手順を説明します。

1. サポートされている機能とこのガイドを確認して、機能とダウングレード プロセスをよく理解してください。

2. 以前のバージョンの Anthos Service Mesh をインストールしたときにオプション機能を有効にした場合は、ダウングレードするときに同じ機能を有効にする必要があります。オプション機能を有効にするには、--set values フラグを追加するか、istioctl apply コマンドを実行するときに YAML ファイルで -f フラグを指定します。

   注意: --set values フラグまたは YAML ファイルの -f フラグを省略すると、インストールに成功します。ただし、省略された値は Anthos Service Mesh が再デプロイされるとデフォルトにリセットされるため、意図したものと異なる構成になります。istioctl apply を実行して 1.5.10 にダウングレードするときは、同じフラグを使用する必要があります。

   Anthos Service Mesh の 1.5.10 から 1.4.10 にダウングレードし、YAML ファイルでオプション機能を有効にしている場合は、YAML ファイルを IstioOperator API から IstioControlPlane API に変換する必要があります。

3. ダウンタイムをスケジュール設定します。クラスタのスケールによりますが、ダウングレードには最大 1 時間かかります。これには、ワークロードを再デプロイしてサイドカー プロキシを更新するために必要な時間は含まれません。

環境設定

ローカルマシンに、Cloud SDK（gcloud コマンドライン ツール）をインストールして初期化します。

注: Linux ユーザーが Linux のクイックスタートを使用して Cloud SDK をインストールすることがあります。apt-get または yum を使用して Cloud SDK をインストールする場合、gcloud components を使用したコンポーネントの更新と削除は無効になります。この場合、Cloud SDK を管理するには、インストール中に使用していたパッケージ管理ツールを引き続き使用し、コンポーネントの更新または削除を行ってください。

Cloud SDK がすでにインストールされている場合:

1. Cloud SDK で認証します。

   gcloud auth login
   

2. コンポーネントを更新します。

   gcloud components update
   

3. kubectl をインストールします。

   gcloud components install kubectl
   

4. クラスタが作成されたプロジェクトのプロジェクト ID を取得します。

   gcloud

   gcloud projects list

   Console

   1. Cloud Console で [ダッシュボード] ページに移動します。

      [ダッシュボード] ページに移動する

   2. ページ上部の [選択元] プルダウン リストをクリックします。表示された [選択元] ウィンドウで、プロジェクトを選択します。プロジェクト ID は、プロジェクト ダッシュボードの [プロジェクト情報] カードに表示されます。

5. gcloud コマンドライン ツールのデフォルトのプロジェクト ID を設定します。

   gcloud config set project PROJECT_ID

認証情報と権限の設定

1. Anthos Service Mesh をインストールする VMware ユーザー クラスタ上に Anthos クラスタのための kubectl があることを確認します。Anthos Service Mesh はユーザー クラスタにのみインストールできます。管理クラスタにはインストールできません。
2. 現在のユーザーにクラスタ管理者の権限を付与します。この権限は、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 を続行しても問題ありません。

インストール ファイルのダウンロード

Linux

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 は VMware 上の Anthos クラスタではサポートされていません）。

Mac OS

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 は VMware 上の Anthos クラスタではサポートされていません）。

Windows

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 は VMware 上の Anthos クラスタではサポートされていません）。

1. Anthos Service Mesh インストールのルート ディレクトリに移動していることを確認します。

   cd istio-1.4.10-asm.18

2. 利便性を考えて、/bin ディレクトリ内のツールを PATH に追加します。

   export PATH=$PWD/bin:$PATH

Anthos Service Mesh のダウングレード

このセクションでは、Anthos Service Mesh をダウングレードし、[サポートされている機能] ページに表示されたサポートされているデフォルト機能を有効にする方法について説明します。サポートされているオプション機能の有効化については、オプション機能の有効化をご覧ください。

Anthos Service Mesh をインストールするには:

次のいずれかのコマンドを選択して、PERMISSIVE 相互 TLS（mTLS）認証モードまたは STRICT mTLS モードで Anthos Service Mesh を構成します。

PERMISSIVE mTLS

istioctl manifest apply --set profile=asm-onprem

注意: PERMISSIVE モードでは、デフォルトで、平文トラフィックと相互 TLS トラフィックを同時に受け入れ、平文のイントラメッシュ トラフィックを送信できます。ダウングレード後にサービス メッシュを保護するには、相互 TLS 移行での説明に従い、サービスを相互 TLS STRICT モードに移行します。

STRICT mTLS

istioctl manifest apply --set profile=asm-onprem \
  --set values.global.mtls.enabled=true

コントロール プレーン コンポーネントを確認する

ダウングレードするには、コントロール プレーン コンポーネントを再インストールする必要があります。完了するまでには約 5～10 分かかります。新しいコンポーネントがインストールされると、古いコントロール プレーン コンポーネントは終了し、削除されます。ワークロードの AGE 列の値を見ることで、進行状況を確認できます。

kubectl get pod -n istio-system

出力例

NAME                                      READY   STATUS       RESTARTS   AGE
istio-citadel-64f6d7c7c7-jtmw7            1/1     Running      0          38s
istio-galley-6b4878d445-c4rtt             1/2     Running      0          37s
istio-ingressgateway-7866c5c88f-llp28     0/1     Running      0          37s
istio-ingressgateway-7866c5c88f-m9sck     1/1     Terminating  0          25m
istio-pilot-7f4fdcb89c-r98jl              1/2     Running      0          37s
istio-sidecar-injector-65cbd565b9-q4wm9   1/1     Running      0          37s
promsd-78dfdf7c7d-2bhr6                   2/2     Running      1          37s

この例では、istio-ingressgateway のインスタンスが 2 つあります。AGE 列の 25m のインスタンスが終了します。その他のコンポーネントはすべて、新たにインストールされます。

サイドカー プロキシの更新

Anthos Service Mesh のダウングレード前にクラスタで実行されていたワークロードの場合は、現在の Anthos Service Mesh バージョンを使用するように、サイドカー プロキシを挿入または更新する必要があります。

注意: Blue / Green デプロイのロードバランサまたはルーターを設定していない場合を除いて、必ずステージング環境で Pod の再起動をテストし、サービスがトラフィックの中断に対処できることを確認するようにしてください。

自動サイドカー インジェクションでは、Pod 再起動で既存の Pod のサイドカーを更新できます。Pod を再起動する方法は、Pod が Deployment の一部として作成されたかどうかによって異なります。

1. Deployment を使用した場合は、サイドカー付きのすべての Pod を再起動する Deployment を再起動します。

   kubectl rollout restart YOUR_DEPLOYMENT -n YOUR_NAMESPACE

   Deployment を使用していない場合、Pod を削除すると、自動的にサイドカー付きで再作成されます。

   kubectl delete pod -n YOUR_NAMESPACE --all

2. 名前空間内のすべての Pod にサイドカーが挿入されたことを確認します。

   kubectl get pod -n YOUR_NAMESPACE --all

   次に前のコマンドの出力例を示します。ここで、READY 列はワークロードごとに 2 つのコンテナ（プライマリ コンテナとサイドカー プロキシのコンテナ）があることを示しています。

   NAME                    READY   STATUS    RESTARTS   AGE
   YOUR_WORKLOAD           2/2     Running   0          20s
   ...