Istio から Anthos Service Mesh に移行するには、いくつかの計画が必要です。このページでは、移行の準備に役立つ情報を提供します。
プロファイルの確認
Anthos Service Mesh で提供される構成プロファイルは、オープンソースの Istio とは異なります。Anthos Service Mesh をインストールする場合は、環境に適した構成プロファイルを使用します。
asm-gcp: このプロファイルは、同じ Google Cloud プロジェクトに存在する単一クラスタまたは複数のクラスタを含むメッシュの GKE でのインストールに使用します。asm-gcp-multiprojectベータ版: このプロファイルは、異なる Google Cloud プロジェクトにあるクラスタの GKE でのインストールに使用します。asm-multicloud: このプロファイルは、次の環境へのインストールに使用します。- GKE on VMware
- GKE on AWS
- Amazon Elastic Kubernetes Service（Amazon EKS）
- Microsoft Azure Kubernetes Service（Microsoft AKS）
サポートされている Anthos Service Mesh の機能は、プロファイルによって異なります。構成に適したプロファイルのサポートされる機能を確認します。
プロファイルを比較する
使用する予定の Anthos Service Mesh プロファイルでの Istio のインストールに使用した構成プロファイルを比較できます。
インストール ファイルのダウンロードの手順に沿って、インストールと署名ファイルをダウンロードし、コンテンツを抽出して、ダウンロード ファイルから
istioctlのバージョンを使用するパスを設定します。使用する予定の Anthos Service Mesh プロファイルのマニフェストを生成します。
istioctl manifest generate -f manifests/profiles/ASM_PROFLE > a.yaml
Istio のインストールに使用したプロファイルを見つけます。プロファイルは Istio のバージョン間で変更される可能性があるため、Istio のバージョンと一致するインストール パッケージのプロファイルが必要です。
Istio のインストールに使用したプロファイルのマニフェストを生成します。
istioctl manifest generate -f ISTIO_PROFILE > b.yaml
マニフェストを比較します。
istioctl manifest diff a.yaml b.yaml
構成ファイルの準備
Istio のインストールをカスタマイズした場合は、Anthos Service Mesh に移行する際に、同じカスタマイズを行う必要があります。--set values フラグを追加してインストールをカスタマイズした場合は、それらの設定を IstioOperator 構成ファイルに追加することをおすすめします。構成ファイルを指定するには、istioctl install コマンドを実行するときに -f フラグを使用して構成ファイルを指定します。
認証局の選択
相互 TLS（mTLS）証明書を発行する認証局（CA）として Citadel（現在は istiod に組み込まれています）を引き続き使用することも、Anthos Service Mesh 認証局（Mesh CA）への移行を選択することもできます。
次の理由から、Mesh CA を使用することをおすすめします。
- Mesh CA は、信頼性の高いスケーラブルなサービスで、Google Cloud 上で動的にスケーリングされるワークロード用に最適化されています。
- Mesh CA を使用する場合、Google は CA バックエンドのセキュリティと可用性を管理します。
- Mesh CA を使用すると、クラスタ間で単一のルート オブ トラストを使用できます。
ただし、次のような場合、Citadel の使用を検討できます。
- カスタム CA を使用する場合。
- Mesh CA への移行のダウンタイムをスケジュールすることはできません。Mesh CA を使用することをおすすめしますが、すべての名前空間ですべての Pod を再起動するまで mTLS トラフィックがエラーとなるため、移行時のダウンタイムをスケジューリングする必要があります。
移行プロセスの確認
Istio から移行するには、デュアル コントロール プレーンのアップグレード プロセス（Istio ドキュメントではカナリア アップグレードと呼ばれます）に従います。デュアル コントロール プレーンのアップグレードでは、既存のコントロール プレーンを残しながら、新しいバージョンのコントロール プレーンをインストールします。新しいバージョンをインストールする際は、新しいコントロール プレーンのバージョンを識別する revision ラベルを含めます。各リビジョンは、独自の Deployment と Service を持つ完全な Anthos Service Mesh コントロール プレーンの実装です。
新しいコントロール プレーンを参照するようにワークロードに同じ revision ラベルを設定し、ローリング再起動を行い、新しい Anthos Service Mesh バージョンでプロキシを再挿入して新しいバージョンに移行します。この方法では、少数のワークロードでアップグレードの効果をモニタリングできます。アプリケーションのテスト後に、すべてのトラフィックを新しいバージョンに移行できます。これは、インプレース アップグレードを行うよりもはるかに安全です。インプレース アップグレードでは、以前のバージョンのコントロール プレーンが新しいコントロール プレーンで瞬時に置き換わります。
Blue/Green デプロイのロードバランサまたはルーターを設定していない場合を除いて、ステージング環境での移行と Pod の再起動をテストして、サービスがトラフィックの中断に対処できることを確認してください。