アップグレードを計画する

このページでは、Anthos Service Mesh のアップグレードを計画する際に役立つ情報を提供します。Istio アップグレードのリリースノートも確認することをおすすめします。

カナリア アップグレードについて

新しいコントロール プレーンのカナリア デプロイを行ってから Anthos Service Mesh をアップグレードすることをおすすめします。カナリア アップグレードでは、asmcli は古いコントロール プレーンを残した状態で、コントロール プレーンの新しいリビジョンをインストールします。元のコントロール プレーンと新しいコントロール プレーンの両方に revision ラベルが設定されます。このラベルは、コントロール プレーンの識別子として機能します。

ワークロードを新しいコントロール プレーンに移行するには:

1. いずれかの名前空間に新しいコントロール プレーンの revision ラベルを設定します。

2. ローリング再起動を実行します。この再起動により、サイドカー プロキシが Pod 内に再度挿入され、プロキシで新しいコントロール プレーンが使用されるようになります。

3. アップグレードがワークロードに与える影響をモニタリングします。アプリケーションをテストする必要がある場合は、上記の手順を繰り返します。

4. アプリケーションのテスト後、すべてのトラフィックを新しいコントロール プレーンに移行するか、古いコントロール プレーンにロールバックします。

カナリア アップグレードは、インプレース アップグレードよりもはるかに安全です。インプレース アップグレードでは、新しいコントロール プレーンが古いコントロール プレーンに置き換わります。詳しい手順については、新しいコントロール プレーンに切り替えるをご覧ください。

コントロール プレーンをカスタマイズする

以前のインストールをカスタマイズした場合は、Anthos Service Mesh をアップグレードする際に、同じカスタマイズを行う必要があります。--set values フラグを istioctl install に追加してインストールをカスタマイズした場合は、それらの設定をオーバーレイ ファイルと呼ばれる IstioOperator YAML ファイルに追加する必要があります。オーバーレイ ファイルを指定するには、asmcli の実行時にファイル名で --custom_overlay オプションを使用します。

注意: オーバーレイ ファイルを省略すると、正常にインストールされます。ただし、コントロール プレーンが再デプロイされると、省略された値はデフォルト値に戻されるため、サービス メッシュは意図したものと異なる構成になります。

GitHub の anthos-service-mesh パッケージには、多くのオーバーレイ ファイルが含まれています。これらのファイルには、デフォルト構成に対する一般的なカスタマイズが含まれています。これらのファイルはそのまま使用することも、必要に応じて変更を加えることもできます。一部のファイルは、オプションの Anthos Service Mesh 機能を有効にする必要があります。asmcli を実行してプロジェクトとクラスタを検証すると、anthos-service-mesh パッケージがダウンロードされます。

asmcli install を使用して Anthos Service Mesh をインストールする場合は、--option または --custom_overlay で 1 つ以上のオーバーレイ ファイルを指定できます。anthos-service-mesh リポジトリ内のファイルを変更する必要がない場合は、--option を使用します。これにより、GitHub からファイルが取得されます。それ以外の場合は、オーバーレイ ファイルを変更してから、--custom_overlay オプションを使用して asmcli に渡します。

認証局を選択する

プラットフォームに関する注意: Mesh CA は、GKE on AWS、Amazon EKS、Microsoft AKS ではサポートされていません。これらのプラットフォームで --ca mesh_ca を指定して asmcli install を実行すると、インストールに失敗します。

現在の Anthos Service Mesh で、Anthos Service Mesh 認証局（Mesh CA）が相互 TLS（mTLS）証明書を発行する認証局（CA）として使用されている場合は、次の理由から、引き続きメッシュ CA を使用することをおすすめします。

• Mesh CA は、信頼性の高いスケーラブルなサービスで、Google Cloud 上で動的にスケーリングされるワークロード用に最適化されています。
• Mesh CA を使用する場合、Google は CA バックエンドのセキュリティと可用性を管理します。
• Mesh CA を使用すると、クラスタ間で単一のルート オブ トラストを使用できます。

現在の Anthos Service Mesh で Istio CA（旧「Citadel」）を使用している場合は、アップグレード時に Mesh CA に切り替えることができますが、ダウンタイムをスケジューリングする必要があります。アップグレード中は、すべてのワークロードが Mesh CA で新しいコントロール プレーンを使用するように切り替わるまで、mTLS トラフィックが中断されます。

プラットフォームに関する注: CA Service は次のプラットフォームでのみサポートされています。Google Cloud 上の GKE クラスタ、GKE on VMware、GDCV for Bare Metal。他のプラットフォームで asmcli install を実行して --ca gcp_cas を指定すると、インストールは成功したように見えますが、ワークロードは起動しません。

Mesh CA からの証明書には、アプリケーションのサービスに関する次のデータが含まれます。

• Google Cloud プロジェクト ID。
• GKE 名前空間
• GKE サービス アカウント名

重要: Mesh CA が発行した証明書は、サービス メッシュ内で安全なサービス間通信を可能にするためにのみ使用してください。他のいかなる目的にも使用してはなりません。これらの証明書は、相互 TLS を使用してサービスが相互に通信を試みるたびに送信されます。サービス メッシュの外部との通信時に、これらの証明書を使用して機密情報が誤って漏洩しないようにしてください。

CA の特定

asmcli install を実行してアップグレードするときに、新しいコントロール プレーンで asmcli を有効にする CA を指定します。

CA を変更すると、新しいコントロール プレーンにワークロードをデプロイする際にダウンタイムが発生します。ダウンタイムをスケジューリングできない場合は、古いコントロール プレーンが使用する CA を新しいコントロール プレーンに指定する必要があります。メッシュで有効になっている CA がわからない場合は、次のコマンドを実行します。

1. いずれかの名前空間から Pod のリストを取得します。

   kubectl get pods -n NAMESPACE
   

2. 次のコマンドで、POD_NAME はいずれかの Pod の名前に置き換えます。

   kubectl get pod POD_NAME -n NAMESPACE -o yaml | grep CA_ADDR -A 1
   

   名前空間で Mesh CA が有効になっている場合は、次の出力が表示されます。

   - name: CA_ADDR
     value: meshca.googleapis.com:443
   

ゲートウェイ構成を準備する

Anthos Service Mesh では、サービス メッシュの一部としてゲートウェイをデプロイし、管理できます。ゲートウェイでは、メッシュのエッジで動作し、受信または送信 HTTP / TCP 接続を処理するロードバランサを記述します。ゲートウェイは、メッシュ内外に送信されるトラフィックをきめ細かく制御する Envoy プロキシです。

asmcli は istio-ingressgateway をインストールしません。コントロール プレーンとゲートウェイを個別にデプロイして管理することをおすすめします。詳細については、ゲートウェイのインストールとアップグレードをご覧ください。

プラットフォームをアップグレードする（省略可）

Anthos Service Mesh は、現在のプラットフォームもサポートしている最新のサポートされているバージョンにアップグレードすることをおすすめします。次に、サポートされているプラットフォームと Kubernetes バージョンの範囲内になるように環境をアップグレードします。必要に応じて、Anthos Service Mesh の最新のサポートされているバージョンにアップグレードします。

次のステップ

• 依存ツールをインストールしてクラスタを検証する