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

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

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

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

次に、名前空間に同じ revision ラベルを設定してローリング再起動を行い、新しいコントロール プレーンにワークロードを移行します。この再起動により、サイドカー プロキシが Pod 内に再度挿入され、プロキシで新しいコントロール プレーンが使用されるようになります。この方法では、少数のワークロードでアップグレードの効果をモニタリングできます。アプリケーションのテスト後、すべてのトラフィックを新しいコントロール プレーンに移行するか、古いコントロール プレーンにロールバックします。このアプローチは、インプレース アップグレードよりもはるかに安全です。インプレース アップグレードでは、新しいコントロール プレーンが古いコントロール プレーンに置き換わります。

この初期のプレビュー版では、asmcli はデフォルトでリビジョン ラベルを含む istio-ingressgateway をインストールします。これにより、コントロール プレーンだけでなく istio-ingressgateway のカナリア アップグレードも行えるようになります。

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

以前のインストールをカスタマイズした場合は、Anthos Service Mesh をアップグレードする際に、同じカスタマイズを行う必要があります。--set values フラグを istioctl install に追加してインストールをカスタマイズした場合は、それらの設定をオーバーレイ ファイルと呼ばれる IstioOperator YAML ファイルに追加する必要があります。オーバーレイ ファイルを指定するには、スクリプトの実行時に --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 に渡します。

認証局を選択する

現在の 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 トラフィックが中断されます。

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

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

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 をインストールしません。コントロール プレーンとゲートウェイを個別にデプロイして管理することをおすすめします。詳細については、ゲートウェイのインストールとアップグレードをご覧ください。クラスタ内コントロール プレーンにデフォルトの istio-ingressgateway をインストールする必要がある場合は、--option legacy-default-ingressgateway 引数を指定します。

次のステップ