マネージド コントロール プレーンのモダナイゼーション

<0x0ISTIODすべてのマネージド ISTIOD フリートを TRAFFIC_DIRECTOR 実装に移行する必要があります。

サポート終了期限までに、Cloud Service Mesh フリートを非推奨の ISTIOD コントロール プレーン実装から TRAFFIC_DIRECTOR 実装にモダナイズする必要があります。移行は、独自のスケジュールで開始することも、組織が互換性を持つようになったら Google に自動的にスケジュール設定を任せることもできます。

モダナイゼーションには 2 つのパスがあり、これらを組み合わせて使用することもできます。

• お客様がトリガーするモダナイゼーション（セルフサービス）: Google が主導するスケジュールとは別に、Google Cloud CLI を使用して、フリートのモダナイゼーションの正確なタイミングを自分で開始して制御します。
• Google 主導のモダナイゼーション（デフォルト）: Google はフリートの互換性を評価し、メンテナンス ウィンドウと事前通知に従って、組織全体でモダナイゼーションを自動的にスケジュールします。Google は、組織内のすべてのフリートが互換性を持つまで待機します。そのため、互換性のないフリートが 1 つでもあると、モダナイゼーションがブロックされます。

どのパスを選択しても、コントロール プレーンを最新化するには、次のコア手順を完了する必要があります。

1. 互換性を確認する: 互換性チェックを有効にして、フリートのモダナイゼーションとの互換性を把握します。
2. モダナイズを計画して構成する: パスウェイを選択し、クラスタとフリートのロールアウト順序を構成するか、特定のフリートを延期します。
3. 互換性のギャップを修正する: モダナイゼーションを開始する前に、フリートがすべての互換性要件を満たしていることを確認します。
4. モダナイゼーションを開始する: スケジュールに基づいてお客様がトリガーするモダナイゼーションをトリガーするか、Google 主導のスケジューリングを待ちます。
5. クラスタのアクティブなモダナイゼーション: 構成されたメンテナンスの時間枠で、デュアル コントロール プレーンが並行して実行され、Deployment（ワークロードとゲートウェイ）が新しいコントロール プレーンに自動的に移行します。StatefulSet ワークロードと DaemonSet ワークロードを手動で再起動する必要があります。
6. ステータスのモニタリング、ソーク、最終処理: 条件の進行状況をモニタリングし、停止を解決します。ソーク期間（少なくとも 6 営業日）中にワークロードを観察します。フリートレベルの最終処理の前に、完全なロールバックをサポートします。

フリートの互換性を確認してギャップを解消する

フリートがモダナイズされる前に（お客様がトリガーするモダナイゼーションと Google がトリガーするモダナイゼーションのどちらの場合でも）、フリートが互換性があることを確認する必要があります。互換性レポートを有効にして、潜在的なブロッカー条件を検査し、構成のギャップを修正する必要があります。詳細については、Cloud Service Mesh の互換性についてをご覧ください。

• Google 主導のモダナイゼーションの場合: Google は、延期されていないすべてのフリートに互換性がある組織のみをスケジュールします。
• お客様がトリガーするモダナイゼーションの場合: モダナイゼーションを開始する前に、ターゲット フリートが MODERNIZATION_COMPATIBLE をレポートしていることを確認する必要があります。

互換性チェックでは、フリートの Istio CRD 構成、Pod アノテーション、インフラストラクチャの依存関係（Workload Identity など）、スケール パラメータが評価されます。

サポートされていない機能の処理

ISTIOD コントロール プレーンの非推奨に伴い、 Google Cloud は TRAFFIC_DIRECTOR コントロール プレーンの実装と互換性のない機能のサポートを終了します。API サポートの詳細をご覧ください。

サポートされていない機能を使用している場合は、サポートが終了する前に次のいずれかの対応を行う必要があります（非推奨を参照）。

• 構成をリファクタリングする（推奨）: サポートされていないフィールドを削除するか、サポートされている Cloud Service Mesh の代替フィールドに置き換えて、フリートが MODERNIZATION_COMPATIBLE を報告するようにします。その後、TRAFFIC_DIRECTOR コントロール プレーンの実装に移行します。
• オープンソース（OSS）Istio に移行する: ワークロードで TRAFFIC_DIRECTOR を使用するマネージド Cloud Service Mesh がサポートしていない機能を厳密に必要とする場合、これらのクラスタを TRAFFIC_DIRECTOR に移行することはできません。これらのワークロードは、セルフマネージドのオープンソース Istio に移行する必要があります。
• Cloud Service Mesh をアンインストールする: マネージド Cloud Service Mesh をアンインストールできます。

モダナイゼーションを計画して構成する

フリートをどのようにモダナイズするかを計画します。この操作を行わない場合、Google 主導のモダナイゼーションがデフォルトの方法で適用されます。非本番環境フリートを最初にモダナイズし、重要なフリートを最後にモダナイズするには、対応が必要です。また、Google 主導のモダナイゼーションでは、組織全体の延期されていないフリートの 100% が互換性を持つまで、組織のモダナイゼーションはスケジュールされません。そのため、ローカルの非互換性によってモダナイゼーションがブロックされる可能性があります。

モダナイゼーションを開始する前に、オプションを確認し、組織のフリートとクラスタ全体でロールアウト設定を構成します。

利用可能な経路

アプローチ	説明	最適な用途	範囲	前提条件	事前通知	ロールバック機能
顧客主導のモダナイゼーション	モダナイゼーションは、独自のスケジュールでフリートごとに開始します。	フリートのモダナイゼーションのタイミングをきめ細かく制御できます（フリートレベルで開始とロールバックのタイミングを決定できます）。既存のアプリケーション モニタリングを活用して、ロールバックが必要な場合にアラートを送信します。	フリート単位（FLEET_PROJECT_ID）。	移行先のフリートはモダナイゼーションに対応している必要があります。	該当なし。	Google Cloud CLI を使用した即時のセルフサービス ロールバック。
Google 主導のモダナイゼーション（デフォルト）	Google は、組織全体でモダナイゼーションを自動的にスケジュールします。	組織内のすべてのフリートが互換性を持つと、モダナイゼーションが自動的に行われます。	組織全体（遅延されていないすべてのフリート）。 Google Cloud	組織内の延期されていないすべてのフリートがモダナイゼーションに対応している必要があります。	開始前に 14 日以上のフリート通知と 24 時間以上のクラスタ通知。	標準化されたモニタリングでエラーが検出された場合、Google はロールバックします。アプリケーション モニタリングにエラーが表示された場合は、Cloud カスタマーケアにお問い合わせください。

組織全体で複数のフリートを管理する

Google Cloud 組織が複数のフリートを管理している場合、すべてのフリートに単一のアプローチを選択する必要はありません。戦略を組み合わせることもできます。例:

• 複雑なフリートや重要なフリートを延期する: --modernization-strategy deferred を使用して特定のフリートを以前の実装に固定し、依存関係を修正したり、顧客がトリガーする実行を計画したりしている間、Google 主導のスケジューリングから除外します。
• 選択したフリートで顧客トリガーのモダナイゼーションを開始する: テスト、開発、評価のフリートを最初にモダナイズして、独自のタイムラインで動作を検証します。
• Google が残りのフリートをモダナイズすることを許可する: 互換性があり、延期されていないフリートは、Google 主導のスケジューリングが有効なままになります。

フリートのモダナイゼーションを延期する（オプトアウト）

個々のフリートで Google 主導のモダナイゼーションをオプトアウトするには、その戦略を DEFERRED に設定します。

gcloud alpha container fleet mesh update \
  --modernization-strategy deferred \
  --project FLEET_PROJECT_ID

FLEET_PROJECT_ID は、フリートホスト プロジェクトの ID に置き換えます。

--modernization-strategy deferred を設定することは、次のことを行うための推奨される方法です。

• お客様がトリガーするモダナイゼーションを使用して、独自のスケジュールでモダナイゼーションを行うため、特定のフリートを Google 主導のスケジューリングから除外する。
• 依存関係を修正している間、複雑なフリートや重要なフリートのモダナイゼーションを一時的に保留し、組織内の他の互換性のあるフリートで Google 主導のスケジューリングを続行できるようにします。

以前のプロジェクト ラベル mesh-modernization-mode=manual は引き続き有効ですが、--modernization-strategy deferred を使用することをおすすめします。組織内の他の遅延されていないフリートは、すべてが互換性を持つようになれば、Google 主導のスケジューリングの対象となります。

警告: フリートを deferred に設定する（または互換性のギャップを未解決のままにする）と、フリートは Google 主導の自動スケジューリングからオプトアウトされますが、サポートの期限は延長されません（非推奨を参照）。

ロールアウトの順序を構成する

mesh-modernization-order ラベル（early、default、late）を使用して、クラスタとフリート間の順次ロールアウトの順序を制御できます。

クラスタのロールアウト順序（両方のパスウェイに適用）

フリートに複数のクラスタが含まれている場合は、各クラスタに mesh-modernization-order ラベルを適用して、クラスタの最新化の順序を制御できます。ユーザーまたは Google がフリートのモダナイゼーションをトリガーすると、各クラスタ グループが順番にモダナイズされます。次のグループを開始する前に、現在のグループで自動モダナイゼーション ステップが完了するのを待ちます。

gcloud container clusters update CLUSTER_NAME \
  --location LOCATION \
  --update-labels="mesh-modernization-order=VALUE"

CLUSTER_NAME はクラスタの名前に、LOCATION はクラスタのロケーションに、VALUE は次のいずれかに置き換えます。

• early: クラスタはモダナイゼーションの第 1 波でモダナイズされます。
• default: クラスタはモダナイゼーションの第 2 波でモダナイズされます。
• late: クラスタは、モダナイゼーションの第 3 波（最終波）でモダナイズされます。

フリートのロールアウト順序（Google 主導のみ）

Google 主導のモダナイゼーションが進行中の複数のフリートがある組織では、フリート ホスト プロジェクトにプロジェクト レベルのラベルを設定することで、Google がフリートをモダナイズする順序を制御できます。

gcloud alpha projects update FLEET_PROJECT_ID \
  --update-labels="mesh-modernization-order=VALUE"

FLEET_PROJECT_ID はフリート ホスト プロジェクトの ID に置き換え、VALUE は次のいずれかに置き換えます。

• early: フリートはモダナイゼーションの第 1 ウェーブでモダナイズされます。
• default: フリートはモダナイゼーションの第 2 波でモダナイズされます。
• late: フリートは、モダナイゼーションの第 3 波（最終波）でモダナイズされます。

Google は、各フリート階層のモダナイゼーションを完了してから、次の階層（早期、デフォルト（ラベルなし）、遅延）を開始します。遅延とマークされたフリートは、この順序付けに含まれません。

たとえば、非本番環境フリートを early に、特に重要なフリートを late に設定し、その他はデフォルトのままにできます。

Google Cloud 組織を使用しない場合は、フリートは個別にスケジュール設定され、モダナイズされます。順序を制御することはできません。

お客様がトリガーするモダナイゼーション（セルフサービス）

お客様がトリガーするモダナイゼーションでは、個々のフリートのモダナイゼーションの開始タイミングを直接制御できます。

フリートのモダナイゼーションをトリガーする

ターゲット フリートが MODERNIZATION_COMPATIBLE を報告したら、次のコマンドを使用してモダナイズをトリガーします。

gcloud alpha container fleet mesh update \
  --modernization-strategy automatic \
  --project FLEET_PROJECT_ID

FLEET_PROJECT_ID は、フリートホスト プロジェクトの ID に置き換えます。

• メンテナンスの時間枠: Google は、構成されたクラスタのメンテナンスの時間枠と除外を尊重します。クラスタのモダナイゼーションは、クラスタの次のメンテナンスの時間枠で開始されます。
• クラスタの順序: クラスタに mesh-modernization-order ラベルを構成した場合、Google はその順序を尊重します。

進捗の確認

モダナイゼーションのステータスを確認するの手順に沿って、フリートとクラスタのモダナイゼーションの進行状況をモニタリングします。特に MODERNIZATION_PREPARING ステータスと MODERNIZATION_MIGRATING_WORKLOADS ステータスの間は、アプリケーション モニタリングを注視して、ロールバックが必要かどうかを判断します。

お客様がトリガーしたモダナイゼーションをロールバックする

アクティブなクラスタのモダナイゼーション中またはフリートのソーク期間中（フリートレベルのファイナライズ前）に問題が検出された場合は、直ちにロールバックをトリガーできます。

gcloud alpha container fleet mesh update \
  --modernization-strategy deferred \
  --project FLEET_PROJECT_ID

FLEET_PROJECT_ID は、フリートホスト プロジェクトの ID に置き換えます。

これにより、フリートは延期状態になり、Google 主導のモダナイゼーションの対象外となります。モダナイズを再試行する準備ができたら、コマンドを再実行してフリートのモダナイズをトリガーします。

重要: ロールバックはすぐにトリガーされ、メンテナンスの時間枠はバイパスされます。ワークロードが以前の ISTIOD コントロール プレーンに戻ります。ロールバックは、アクティブなモダナイゼーションとソーク期間中はサポートされますが、フリートが MODERNIZATION_FINALIZED に達するとできなくなります。

Google 主導のモダナイゼーション（自動デフォルト）

お客様がトリガーするモダナイゼーションを開始しない場合、Google は組織全体のモダナイゼーションを自動的に管理します。

組織全体のスケジュール設定

Google はフリートを継続的にモニタリングします。組織内のすべてのメッシュ対応フリート（延期されたフリートを除く）がモダナイゼーションに対応すると、Google は組織のモダナイゼーションをスケジュールします。

事前通知とスケジュール設定

Google は、モダナイゼーションを開始する前に 2 つのレベルの事前通知を提供します。

フリートレベルの通知

まず、お客様のフリートがモダナイゼーションに対応していると判断され、将来的に Google 主導のモダナイゼーションの対象として選ばれた場合、通知が届きます。

• クラスタのモダナイゼーションは、通知の翌月の米国の最初の営業日から 14 日目以降に開始できます。たとえば、Google が 2027 年 1 月 10 日に組織の準備が整ったと判断した場合、2027 年 1 月 31 日までに、モダナイゼーションの開始日を 2027 年 2 月 15 日に設定できることをお知らせします。

• 組織内の各フリート（延期したフリートは除く）について同時に通知が届きます。この通知は、フリートレベルの機能の状態の条件（MODERNIZATION_WILL_BE_SCHEDULED）で使用できます。

クラスタレベルの通知

クラスタのモダナイゼーションが開始される少なくとも 1 日（24 時間）前に、Google 主導によるクラスタのモダナイゼーションの開始予定日がクラスタレベルで通知されます。

フリートレベルの通知に続いて、個々のクラスタのモダナイゼーションのタイミングをより正確に把握できます。この通知は、クラスタレベルの機能の状態の条件（MODERNIZATION_SCHEDULED）で使用できます。

Google 主導のモダナイゼーションのロールバックをリクエストする

Google 主導のモダナイゼーション フリートでアクティブなモダナイゼーションまたはソーキング中に問題が発生した場合は、Cloud カスタマーケアに連絡してロールバックをリクエストしてください。

進行中のモダナイゼーションの処理

このセクションでは、フリートとクラスタのモダナイゼーションがアクティブなときに発生する処理について説明します。

フリートのモダナイゼーション

モダナイズ中のフリートごとに（Google 主導かお客様主導かを問わず）、注文に基づいて（早期 → デフォルト → 後期）、すべてのクラスタで新しいコントロール プレーン実装を有効にします。

すべてのクラスタでコントロール プレーンが有効になると、順序（早期 → デフォルト → 後期）に基づいて、すべてのクラスタのトラフィックが新しいコントロール プレーン実装に移行されます。

現在のステータスを確認するには、フリートのモダナイゼーションのステータスを確認するをご覧ください。

フリート ソーク期間

すべてのクラスタでトラフィックが移行されると、フリートはソーク期間に入ります。すべてのクラスタでモダナイゼーションが完了してから MODERNIZATION_FINALIZED に移行するまで、フリートは少なくとも 6 営業日のソーク期間（MODERNIZATION_MODERNIZED）のままになります。完全なロールバック機能は、ソーク期間中も維持されます。モダナイゼーションが完了すると、ロールバックはできなくなり、ISTIOD コンポーネントのプロビジョニングが解除される可能性があります。

クラスタのモダナイゼーション

クラスタのアクティブなモダナイゼーション中は、両方のコントロール プレーン実装が一時的に並行して実行され、安全かつ制御された方法で次のタスクが処理されます。

1. 新しいコントロール プレーン実装を有効にします。クラスタにメンテナンスの時間枠を構成している場合、このステップはメンテナンスの時間枠中に開始され、完了するまで続行されます。次の点にご注意ください。
   • ヘルスチェックを有効にするために、クラスタの kube-system Namespace に snk DaemonSet が作成され、クラスタごとにファイアウォール ルールが作成されます。
   • ネットワーク エンドポイント グループ（NEG）の取り込みを有効にするには、すべての Kubernetes サービスにアノテーション cloud.google.com/neg を追加します。
   • メッシュ、ルート、バックエンド サービス、ヘルスチェックなどの新しい Google Cloud リソースがクラスタに作成されます。
   • 新しいリソースの一部は割り当てが制限されています。割り当てを確認し、必要に応じて追加をリクエストできます。
   • 次のステップに進む前に、ソーク時間中にクラスタがモニタリングされます。
2. トラフィックを新しいコントロール プレーン実装に移行します。クラスタにメンテナンスの時間枠を構成している場合、このステップはメンテナンスの時間枠中に開始され、完了するまで続行されます。次の点にご注意ください。
   • Cloud Service Mesh プロキシがある Kubernetes Deployment によって管理されている Pod が再起動され、新しいコントロール プレーンに再接続します。
   • Pod は、モニタリングのために各ウェーブの後にソーク時間を設定して、徐々に大きなウェーブで再起動されます。

3. 非デプロイのワークロードの手動再起動（お客様の操作が必要）。

   • Google は、Kubernetes Deployment によって管理されるワークロードを自動的に再起動します。StatefulSet や DaemonSet などの他のタイプの Kubernetes リソースで管理されるワークロードは、手動で再起動する必要があります。
   • クラスタのステータスが MODERNIZATION_COMPLETED と報告されたら（つまり、クラスタがソーキング期間に入ったら）、これらのワークロードを再起動します。
   • フリートのモダナイゼーションが完了する前に、これらのワークロードを再起動する必要があります。再起動しないと、これらのプロキシは、プロビジョニング解除が予定されている以前の Istiod コントロール プレーンに接続されたままになります。
   • kubectl rollout restart ... などの標準の Kubernetes アプローチを使用してワークロードを再起動する

4. クラスタ内のすべてのワークロードが移行されると、クラスタはフリート ソーク期間を待機します。

クラスタのアクティブ モダナイゼーションのステータスをモニタリングするには、モダナイゼーションのステータスを確認するをご覧ください。

最新化のステータスを確認して対応する

フリートとクラスタのモダナイゼーションの進行状況は、Google Cloud CLI を使用してモニタリングできます。

gcloud container fleet mesh describe --project FLEET_PROJECT_ID

FLEET_PROJECT_ID は、フリートホスト プロジェクトの ID に置き換えます。

出力は次のようになります。

  membershipStates:
    projects/123456789/locations/global/memberships/cluster-1:
      servicemesh:
        conditions:
        - code: MODERNIZATION_MIGRATING_WORKLOADS
          documentationLink: https://cloud.google.com/service-mesh/v1.30/docs/...
          severity: INFO
  state:
    servicemesh:
      conditions:
      - code: MODERNIZATION_MODERNIZING
        documentationLink: https://cloud.google.com/service-mesh/v1.30/docs/...
        severity: INFO

モダナイゼーションのステータスは、state.servicemesh.conditions（フリートレベル）フィールドと membershipStates.<MEMBERSHIP_NAME>.servicemesh.conditions（クラスタレベル）フィールドに報告されます。

フリートのモダナイゼーションの成功ステータス

フリートのモダナイゼーションが成功すると、フリートのステータスは MODERNIZATION_MODERNIZING になります。

各クラスタは次のステータスを通過します。

• MODERNIZATION_SCHEDULED
• MODERNIZATION_PREPARING
• MODERNIZATION_PREPARED
• MODERNIZATION_MIGRATING_WORKLOADS
• MODERNIZATION_COMPLETED

フリート内のすべてのクラスタのモダナイゼーションが完了すると、フリートは次のステータスになります。

• MODERNIZATION_MODERNIZED
• MODERNIZATION_FINALIZED

ロールバック

Google 主導のモダナイゼーションでは、モダナイゼーション プロセス全体を通してデプロイの準備状況と健全性をモニタリングし、問題が検出された場合は自動的にロールバックをトリガーします。問題が検出された場合は、Cloud カスタマーケアに連絡してロールバックをリクエストしてください。

お客様がトリガーしたモダナイゼーションでは、いつでもロールバックをトリガーできます。

ロールバック中、フリートにはステータス MODERNIZATION_ROLLING_BACK_FLEET が表示され、クラスタにはステータス MODERNIZATION_ROLLING_BACK_CLUSTER が表示されます。

クラスタのロールバックが完了すると、ステータスが一時的に MODERNIZATION_ABORTED と表示されます。

エラーと停止の処理（お客様によるトリガーのみ）

ユーザーがトリガーしたモダナイゼーション中に、クラスタで進行を妨げる問題が発生すると、クラスタの条件が MODERNIZATION_STALLED に移行します。お客様がトリガーしたモダナイゼーションに対して、Google がロールバックをトリガーすることはありません。問題をトリアージし、修正を転送するか、ロールバックをトリガーするかを決定する必要があります。

クラスタが MODERNIZATION_STALLED を報告した場合は、関連するエラー セクションへの直接リンクについて、条件の詳細を調べます。

ユーザーが対処可能なエラー

互換性のないメッシュまたはクラスタ構成が検出された場合、モダナイゼーションは停止します。互換性レポートが有効になっていることを確認し、Cloud Service Mesh の互換性についてで説明されているように、フリートレベルとクラスタレベルの条件のギャップを確認します。

• Immediate Retry: ブロックが解決されるとすぐに、変更が検出され、次のメンテナンスの時間枠を待たずにモダナイゼーションが直ちに再開されます。

内部エラー

Google の内部サービスの問題は Google のエンジニアが確認し、可能であればモダナイズを再開します。ユーザーが対応可能なエラーと同様に、メンテナンスの時間枠外でモダナイゼーションが再開されることがあります。この問題を回避するには、ロールバックをトリガーします。

移行が 24 時間以上停止し、互換性のギャップがない場合は、Cloud カスタマーケアにお問い合わせください。本番環境のワークロードに影響がある場合は、ロールバックをトリガーします。

フリートレベルの条件のリファレンス

条件	説明
MODERNIZATION_COMPATIBLE	フリートは新しいコントロール プレーン実装と互換性があります。
MODERNIZATION_WILL_BE_SCHEDULED	Google 主導のモダナイゼーション: 組織内の延期されていないすべてのフリートが互換性があり、スケジューリングのためにキューに登録されています。
MODERNIZATION_MODERNIZING	フリート内の 1 つ以上のクラスタでモダナイゼーションが進行中です。
MODERNIZATION_MODERNIZED	すべてのアクティブなモダナイゼーションが完了しました。フリートがソーク期間中である。
MODERNIZATION_FINALIZED	モダナイゼーションが完了し、最終処理が行われた。以前の Istiod コンポーネントが削除されます。ロールバックはできなくなります。
MODERNIZATION_ROLLING_BACK_FLEET	フリートレベルのロールバックが進行中です。

クラスタレベルの条件のリファレンス

条件	説明
MODERNIZATION_SCHEDULED	クラスタは、条件で指定された日付以降にモダナイズがスケジュールされています。クラスタにメンテナンスの時間枠または除外が構成されている場合、日付はターゲットのメンテナンスの時間枠を示します。
MODERNIZATION_PREPARING	新しいコントロール プレーン実装を有効にします。
MODERNIZATION_PREPARED	新しいコントロール プレーン実装が有効になります。ワークロードの移行はまだ開始されていません。
MODERNIZATION_MIGRATING_WORKLOADS	クラスタは、ワークロードを新しいコントロール プレーン実装にアクティブに移行しています。
MODERNIZATION_COMPLETED	クラスタのモダナイゼーションが完了し、ソーク期間に入っています。
MODERNIZATION_STALLED	エラーのためモダナイゼーションが停止しています（お客様がトリガーした場合のみ）。解決策については、条件の詳細をご覧ください。
MODERNIZATION_ROLLING_BACK_CLUSTER	クラスタがロールバック中です。
MODERNIZATION_ABORTED	クラスタが以前のコントロール プレーンにロールバックされた。短期間報告された。