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

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

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

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

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

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

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

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

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

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

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

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

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

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

認証局を選択する

現在の Cloud Service Mesh のインストールで、Cloud Service Mesh 認証局が相互 TLS(mTLS)証明書を発行する認証局(CA)として使用されている場合は、次の理由から、引き続き Cloud Service Mesh 認証局を使用することをおすすめします。

  • Cloud Service Mesh 認証局は、信頼性とスケーラビリティに優れたサービスであり、動的にスケーリングされるワークロード用に最適化されています。
  • Cloud Service Mesh 認証局を使用して、Google は CA バックエンドのセキュリティと可用性を管理します。
  • Cloud Service Mesh 認証局を使用すると、クラスタ全体で単一のルート オブ トラストを使用できます。

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

Cloud Service Mesh 認証局から発行された証明書には、アプリケーションのサービスに関する次のデータが含まれます。

  • 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
    

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

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

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

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

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

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

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

次のステップ