マネージド コントロール プレーン
ISTIODすべてのマネージド ISTIOD フリートを TRAFFIC_DIRECTOR 実装に移行する必要があります。
このドキュメントでは、非推奨の ISTIOD コントロール プレーン実装と Google の最新の TRAFFIC_DIRECTOR コントロール プレーン実装のアーキテクチャの違いについて説明し、クラスタで非推奨のコントロール プレーンがまだ使用されている場合の次の手順について説明します。
コントロール プレーンの概要
サービス メッシュでは、コントロール プレーンはトラフィック管理、Envoy プロキシの使用時のプロキシ管理、その他のネットワーキング機能を担っています。
GKE クラスタで Istio API を使用する Cloud Service Mesh は、Istio API の完全にサポートされた実装を提供します。API は、フルマネージドで Cloud Networking と統合された TRAFFIC_DIRECTOR コントロール プレーンによって実装され、サポートされています。以前は、次の 2 つの追加のコントロール プレーン実装がサポートされていました。
- 単一クラスタ専用のコントロール プレーンを実行する、非推奨の マネージド
ISTIOD実装。 - クラスタ内で顧客管理のコントロール プレーン コンポーネントを実行する、非推奨の クラスタ内
ISTIOD実装。
TRAFFIC_DIRECTOR コントロール プレーンの運用特性
TRAFFIC_DIRECTOR コントロール プレーンを使用する Cloud Service Mesh は、クラスタごとのコントロール プレーン インスタンスではなく、 Google Cloudのマネージド ネットワーキング インフラストラクチャを使用します。
Istio API(CRD)と Envoy サイドカーに送信される xDS 構成は互換性を維持しますが、次の運用上の特性が想定されます。
- ポリシーとサービス構成の伝播: 新しいサービスを作成するか、ルーティング ポリシーとセキュリティ ポリシーを更新すると、構成が検証され、サイドカーで有効になる前に Google Cloud システム全体に伝播されます。そのため、初期ポリシーとサービスの伝播には、クラスタ内または
ISTIODコントロール プレーンよりも時間がかかります。デプロイ ワークフローの最適化に関するガイダンスについては、構成の伝播をご覧ください。 - Pod のスケーリングとエンドポイントの更新: ワークロード エンドポイントの変更(水平 Pod 自動スケーリングによって作成された新しい Pod や、新しい IP アドレスで再起動する Pod など)は、ポリシー更新に関連するレイテンシなしで、コントロール プレーンによって直接伝播されます。既存の構成を取得する既存の Pod は、遅延なく起動します。
- マルチクラスタ エンドポイント検出: マルチクラスタ メッシュでは、クラスタはクラスタの各組み合わせ間でエンドポイントをポイントツーポイントで同期するのではなく、 Google Cloud を介してエンドポイントを直接共有します。これにより、メッシュのスケールアップ時に、クラスタ間のエンドポイントの状態がより迅速かつ一貫して収束します。
この変更による影響
次の手順は、クラスタで使用している Cloud Service Mesh のコントロール プレーンの実装によって異なります。
- マネージド コントロール プレーン(
TRAFFIC_DIRECTOR実装):- 現在のグローバルにスケーラブルなアーキテクチャをすでに使用している(Istio API、Gateway API、または Google CloudAPI を使用して構成されているかどうか)。
- 必要なご対応は特にありません。
- マネージド コントロール プレーン(
ISTIOD実装):- この実装は非推奨です。
- フリートの互換性ブロッカーを検査し、構成を更新して、マネージド コントロール プレーンのモダナイゼーションを完了するか、マネージド Cloud Service Mesh をアンインストールする必要があります。
- クラスタ内コントロール プレーン:
- GKE のクラスタ内コントロール プレーンは非推奨です。
- クラスタ内インストールはインプレースで最新化できません。クラスタ内から新しいクラスタのマネージド コントロール プレーンに移行するか、Cloud Service Mesh をアンインストールする必要があります。
ISTIOD 実装を使用したマネージド Cloud Service Mesh のコントロール プレーンのモダナイゼーション
非推奨の ISTIOD 実装を実行しているすべてのマネージド フリートは、非推奨の通知で指定されたサポート終了期限までに、TRAFFIC_DIRECTOR 実装へのモダナイゼーションを完了する必要があります。フリートのモダナイズには、お客様主導のモダナイゼーション(クラスタごとの制御と段階的なトラフィック シフトに推奨)または Google 主導のモダナイゼーション(対象となるフリートの自動ロールアウト)を使用できます。
手順については、マネージド コントロール プレーンのモダナイゼーションをご覧ください。
コントロール プレーンの互換性の確認
フリートをサポートされている機能に照らして評価し、モダナイゼーションの前に構成のブロッカーを特定するには、以下をご覧ください。
付録: コントロール プレーンのロールアウトと非推奨のタイムライン
ISTIOD コントロール プレーンからマネージド TRAFFIC_DIRECTOR コントロール プレーンの実装への移行は、次のスケジュールで行われました。
- 2024 年 5 月 23 日: Anthos Service Mesh と Traffic Director が Cloud Service Mesh に統合され、Istio API 用の
TRAFFIC_DIRECTORコントロール プレーン実装が導入されました。 - 2024 年 7 月 1 日: マネージド Cloud Service Mesh にオンボーディングされた新しいフリートは、デフォルトで
TRAFFIC_DIRECTOR実装を受け取るようになりました。 - 2024 年 9 月 8 日: 一般提供向けの新しいフリートに対する
ISTIOD実装のプロビジョニングが終了しました(許可リストに登録されている特定の組織については一時的な例外があります)。 - 2026 年 9 月 28 日: マネージド
ISTIODコントロール プレーンの実装と GKE のクラスタ内コントロール プレーンの両方で、正式な非推奨が発表されます。