アップグレードを計画する
このページでは、Cloud Service Mesh のアップグレードを計画する際に役立つ情報を提供します。Istio アップグレードのリリースノートも確認することをおすすめします。
カナリア アップグレードについて
新しいコントロール プレーンのカナリア デプロイを行ってから Cloud Service Mesh をアップグレードすることをおすすめします。カナリア アップグレードでは、asmcli は古いコントロール プレーンを残した状態で、コントロール プレーンの新しいリビジョンをインストールします。元のコントロール プレーンと新しいコントロール プレーンの両方に revision ラベルが設定されます。このラベルは、コントロール プレーンの識別子として機能します。
ワークロードを新しいコントロール プレーンに移行するには:
いずれかの名前空間に新しいコントロール プレーンの
revisionラベルを設定します。ローリング再起動を実行します。この再起動により、サイドカー プロキシが Pod 内に再度挿入され、プロキシで新しいコントロール プレーンが使用されるようになります。
アップグレードがワークロードに与える影響をモニタリングします。アプリケーションをテストする必要がある場合は、上記の手順を繰り返します。
アプリケーションのテスト後、すべてのトラフィックを新しいコントロール プレーンに移行するか、古いコントロール プレーンにロールバックします。
カナリア アップグレードは、インプレース アップグレードよりもはるかに安全です。インプレース アップグレードでは、新しいコントロール プレーンが古いコントロール プレーンに置き換わります。詳しい手順については、新しいコントロール プレーンに切り替えるをご覧ください。
コントロール プレーンをカスタマイズする
以前のインストールをカスタマイズした場合は、Cloud Service Mesh をアップグレードする際に、同じカスタマイズを行う必要があります。--set values フラグを istioctl install に追加してインストールをカスタマイズした場合は、それらの設定をオーバーレイ ファイルと呼ばれる IstioOperator YAML ファイルに追加する必要があります。オーバーレイ ファイルを指定するには、asmcli の実行時にファイル名で --custom_overlay オプションを使用します。
GitHub の anthos-service-mesh パッケージには、多くのオーバーレイ ファイルが含まれています。これらのファイルには、デフォルト構成に対する一般的なカスタマイズが含まれています。これらのファイルはそのまま使用することも、必要に応じて変更を加えることもできます。一部のファイルは、オプションの 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 がわからない場合は、次のコマンドを実行します。
いずれかの名前空間から Pod のリストを取得します。
kubectl get pods -n NAMESPACE次のコマンドで、
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 プロキシです。
asmcli は istio-ingressgateway をインストールしません。コントロール プレーンとゲートウェイを個別にデプロイして管理することをおすすめします。詳細については、ゲートウェイのインストールとアップグレードをご覧ください。
プラットフォームをアップグレードする（省略可）
Cloud Service Mesh は、現在のプラットフォームもサポートしている最新のサポートされているバージョンにアップグレードすることをおすすめします。次に、サポートされているプラットフォームと Kubernetes バージョンの範囲内になるように環境をアップグレードします。必要に応じて、Cloud Service Mesh の最新のサポートされているバージョンにアップグレードします。