このページでは、サービスの中断を最小限に抑えながら、ワークロードを Google Kubernetes Engine（GKE）Standard クラスタから Autopilot クラスタに移行する場合に役立つ考慮事項と推奨事項について説明します。このページは、すでに Autopilot への移行を決めているクラスタ管理者を対象としています。移行を決定する前に詳細情報が必要な場合は、GKE のオペレーション モードを選択すると GKE Autopilot と Standard の比較をご覧ください。
移行の仕組み
Autopilot クラスタは、Standard クラスタで手動構成する多くのオプション機能を自動化します。また、Autopilot クラスタは、アプリケーションにより安全なデフォルトの構成を適用することで、本番環境に対応した環境を提供します。Standard モードと比べると必要な管理オーバーヘッドが少なくなります。Autopilot クラスタは、多くの GKE のベスト プラクティスと推奨事項をデフォルトで適用します。Autopilot はワークロード中心の構成モデルを使用します。このモデルでは、必要な情報を Kubernetes マニフェストでリクエストすると、GKE が対応するインフラストラクチャをプロビジョニングします。
Standard ワークロードを Autopilot に移行する場合は、ワークロードのマニフェストを準備し、Autopilot クラスタとの互換性を確保する必要があります。たとえば、通常は手動でプロビジョニングする必要のあるインフラストラクチャを要求するようにマニフェストを変更します。
移行を準備して実施する際の大まかな流れは次のようになります。
- 既存の Standard クラスタでプリフライト チェックを実行して、Autopilot との互換性を確認します。
- Autopilot に対応するようにワークロード マニフェストを変更します（必要な場合）。
- ドライランを行い、Autopilot でワークロードが正しく機能していることを確認します。
- Autopilot クラスタを計画して作成します。
- Infrastructure as Code ツールを更新します（必要な場合）。
- 移行を実施します。
始める前に
始める前に、次の作業が完了していることを確認してください。
- Google Kubernetes Engine API を有効にする。 Google Kubernetes Engine API の有効化
- このタスクに Google Cloud CLI を使用する場合は、gcloud CLI をインストールして初期化する。すでに gcloud CLI をインストールしている場合は、
gcloud components updateを実行して最新のバージョンを取得する。
- 既存の Standard クラスタでワークロードが稼働していないことを確認します。
- Autopilot クラスタでドライランを実行しているワークロードがないことを確認します。新しい Autopilot クラスタを作成する場合は、Autopilot クラスタを作成するをご覧ください。
Standard クラスタでプリフライト チェックを実行する
Google Cloud CLI と Google Kubernetes Engine API には、実行中の Standard ワークロードの仕様を検証し、Autopilot クラスタとの互換性を確認するプリフライト チェック ツールが用意されています。このツールは GKE バージョン 1.26 以降で使用できます。
- このツールをコマンドラインで使用する場合は、次のコマンドを実行します。
gcloud container clusters check-autopilot-compatibility CLUSTER_NAME
CLUSTER_NAME は、Standard クラスタの名前に置き換えます。必要に応じて、このコマンドに --format=json を追加して、JSON ファイルの出力を取得します。
この出力には、実行中のすべての Standard ワークロードの調査結果が含まれています。調査結果はカテゴリに分類され、Autopilot との互換性を確保するための推奨事項（該当する場合）が提供されます。次の表にカテゴリの説明を示します。
| プリフライト ツールの結果 | |
|---|---|
Passed |
ワークロードは Autopilot で想定どおりに実行されます。移行に必要な構成はありません。 |
Passed with optional configuration |
ワークロードは Autopilot で実行されますが、構成を変更することでエクスペリエンスを最適化できます。構成を変更しない場合は、Autopilot がデフォルトの構成を適用します。 たとえば、ワークロードが Standard モードの N2 マシンで実行されている場合、GKE は Autopilot に汎用コンピューティング クラスを適用します。ワークロードを変更して、N2 マシンを基盤とする Balanced コンピューティング クラスをリクエストすることもできます。 |
Additional configuration required |
ワークロードを Autopilot で実行するには、構成を変更する必要があります。 たとえば、Standard で NET_ADMIN 機能を使用するコンテナについて考えてみましょう。Autopilot では、セキュリティ強化のため、この機能はデフォルトで無効になっています。このため、ワークロードをデプロイする前にクラスタで NET_ADMIN を有効にする必要があります。 |
Incompatibility |
Autopilot でサポートされていない機能が使用されているため、ワークロードを Autopilot で実行することはできません。 たとえば、デフォルトのセキュリティ ポスチャーを改善するため、Autopilot クラスタは特権 Pod（Pod 仕様の |
プリフライトの結果に基づいてワークロードの仕様を変更する
プリフライト チェックを実行したら、JSON 出力を確認し、変更が必要なワークロードを特定します。構成に関する推奨事項の実装もおすすめします。検出結果には、ワークロード仕様の内容を示すドキュメントへのリンクも含まれています。
Autopilot と Standard の最も重要な違いは、Autopilot のインフラストラクチャ構成がワークロード仕様に基づいて自動的に行われることです。ノードの taint や toleration などの Kubernetes スケジューリング コントロールは、実行中のワークロードに自動的に追加されます。Helm チャートや Kustomize オーバーレイなどの Infrastructure-as-Code の構成も変更が必要になることがあります。
一般的な構成で、次のようなものは変更が必要になります。
| Autopilot への移行で変更が必要な一般的な構成 | |
|---|---|
| コンピューティングとアーキテクチャの構成 | Autopilot クラスタは、デフォルトで E シリーズ マシンタイプを使用します。他のマシンタイプが必要な場合は、ワークロード仕様でコンピューティング クラスをリクエストする必要があります。これにより、特定のマシンタイプまたはアーキテクチャを使用するノードに Pod を配置するよう Autopilot に指示します。 詳細については、Autopilot のコンピューティング クラスをご覧ください。 |
| アクセラレータ | GPU ベースのワークロードは、ワークロード仕様で GPU をリクエストする必要があります。Autopilot は、必要なマシンタイプとアクセラレータを使用してノードを自動的にプロビジョニングします。 詳細については、Autopilot で GPU ワークロードをデプロイするをご覧ください。 |
| リソース リクエスト | Autopilot ワークロードでは、Pod 仕様に 詳細については、Autopilot のリソース リクエストをご覧ください。 |
| Spot VM でのフォールト トレラントなワークロード | ワークロードが Standard の Spot VM で実行されている場合は、 詳細については、Spot Pod をご覧ください。 |
ステージング Autopilot クラスタでドライランを実行する
ワークロードのマニフェストを変更した後、新しいステージング Autopilot クラスタでドライラン デプロイを行い、ワークロードが期待どおりに動作することを確認します。
コマンドライン
次のコマンドを実行します。
kubectl create --dry-run=server -f=PATH_TO_MANIFEST
PATH_TO_MANIFEST は、変更したワークロード マニフェストのパスに置き換えます。
IDE
Cloud Shell エディタには dry-run コマンドが組み込まれています。このコマンドは、開いているマニフェストに対して実行されます。Visual Studio Code または Intellij IDE で、開いているマニフェストに自動的にドライランを実行するには、Cloud Code 拡張機能をインストールします。
IDE の [Problems] ペインにドライランの問題が表示されます。たとえば、次の画像は、privileged: true を指定したマニフェストに対するドライランの失敗を示しています。
移行先の Autopilot クラスタを計画する
ドライランで問題が表示されなくなったら、ワークロードに新しい Autopilot クラスタを計画して作成します。このクラスタは、前のセクションでマニフェストの変更のテストで使用した Autopilot クラスタとは異なります。
基本的な構成要件については、GKE のオンボーディングに関するベスト プラクティスをご覧ください。さらに、Autopilot の概要もお読みください。ここには、さまざまなレイヤでのユースケースに固有の情報が記載されています。
また、次の点を考慮してください。
- Autopilot クラスタは VPC ネイティブであるため、ルートベースの Standard クラスタから Autopilot に移行することはおすすめしません。
- カスタム ファイアウォール ルールと VPC の設定など、Autopilot クラスタと Standard クラスタに同じまたは類似の VPC を使用してください。
- Autopilot クラスタは GKE Dataplane V2 を使用し、Cilium NetworkPolicies のみをサポートします。Calico NetworkPolicy はサポートされていません。
- Autopilot で IP マスカレードを使用する場合は、下り（外向き）NAT ポリシーを使用します。
- 限定公開 Standard クラスタがある場合は、同様の分離設定で限定公開 Autopilot クラスタを作成します。
- クラスタの作成時に、クラスタのプライマリ IPv4 範囲を Standard クラスタと同じサイズで指定します。
- 特に大規模なクラスタの場合は、各モードの割り当ての違いを確認してください。
- Autopilot のノードあたりの Pod の最大数は Standard と異なります。この点は、ノードまたは Pod アフィニティを頻繁に使用する場合、特に重要となります。
- Autopilot クラスタはすべて Cloud DNS を使用します。
Autopilot クラスタを作成する
クラスタを作成する準備ができたら、Autopilot クラスタを作成します。Autopilot クラスタはすべてリージョン クラスタです。リリース チャンネルに自動的に登録されますが、チャンネルとクラスタ バージョンを指定することもできます。本番環境のワークロードがすぐにスケジューリングされるように、クラスタに小規模なサンプル ワークロードをデプロイして、ノードの自動プロビジョニングをトリガーすることをおすすめします。
Infrastructure-as-Code ツールを更新する
Autopilot をサポートする Infrastructure as Code プロバイダは次のとおりです。
使用するプロバイダのドキュメントを参照して構成を変更してください。
移行方法を選択する
どの移行方法を使用するかは、ワークロードのタイプだけでなく、ネットワーキングのコンセプト（マルチクラスタ Service、マルチクラスタ Ingress など）に対する習熟度や、クラスタ内の Kubernetes オブジェクトの状態をどのように管理するのかによっても異なります。
| ワークロード タイプ | プリフライト ツールの結果 | 移行方法 |
|---|---|---|
| ステートレス アプリケーション |
|
|
| ステートフル アプリケーション |
|
次のいずれかの方法を使用します。
|
| 追加の構成が必要 | 計画的なダウンタイムの間に Kubernetes マニフェストを更新し、Autopilot に再デプロイします。大まかな手順については、ステートフル ワークロードを手動で移行するをご覧ください。 |
移行手順の概要
移行を開始する前に、プリフライト チェックの Incompatible または Additional configuration required の結果が解決されていることを確認します。この結果が含まれるワークロードを変更せずに Autopilot にデプロイすると、ワークロードが失敗します。
以下のセクションで説明する移行の概要は、仮定の環境を想定したものです。実際の手順は環境とワークロードによって異なります。本番環境を移行する前に、ワークロードの計画、テスト、再テストを実施してください。次の点を考慮する必要があります。
- 移行プロセスの所要時間は、移行するワークロードの数によって異なります。
- ステートフル ワークロードを移行する場合は、ダウンタイムが必要です。
- 手動移行では、移行中の個々のワークロードに集中できるため、ケースに応じてリアルタイムで問題を解決できます。
- いずれの場合も、Service、Ingress、ステートレス ワークロードとステートフル ワークロードの機能を促進する他の Kubernetes オブジェクトを移行する必要があります。
Backup for GKE を使用してすべてのワークロードを移行する
Standard クラスタで実行されているすべてのワークロード（ステートフルとステートレス）が Autopilot と互換性があり、プリフライト ツールですべてのワークロードの診断結果が Passed または Passed with optional configuration になっている場合は、Backup for GKE を使用して Standard クラスタとワークロードの状態全体をバックアップし、そのバックアップを Autopilot クラスタに復元します。
この方法には次のメリットがあります。
- 必要最小限の構成で、すべてのワークロードを Standard オペレーションから Autopilot オペレーションに移行できます。
- ワークロード間の関係や関連する PersistentVolume を保持しながら、ステートレス ワークロードとステートフル ワークロードを移行できます。
- ロールバックは直感的で、Google によって管理されます。移行全体をロールバックすることも、特定のワークロードのみをロールバックすることもできます。
- ステートフル ワークロードを Google Cloud のリージョン間で移行できます。ステートフル ワークロードの手動移行は、同じリージョン内でのみ行うことができます。
この方法の場合、GKE はプリフライト ツールの結果が Passed with optional configuration のワークロードに Autopilot のデフォルト構成を適用します。これらのワークロードを移行する前に、デフォルトの設定に問題がないことを確認してください。
ダウンタイムなしでステートレス ワークロードを手動で移行する
サービスのダウンタイムなしでステートレス ワークロードを移行するには、移行元と移行先のクラスタを GKE フリートに登録し、マルチクラスタ Service とマルチクラスタ Ingress を使用して、移行中もワークロードの可用性を維持する必要があります。
- 移行元クラスタと移行先クラスタでマルチクラスタ Service とマルチクラスタ Ingress を有効にします。手順については、マルチクラスタ サービスの構成とマルチクラスタ Ingress の設定をご覧ください。
- データベース ワークロードなどのバックエンドと依存関係がある場合は、マルチクラスタ Service を使用して Standard クラスタから Service をエクスポートします。これにより、Autopilot クラスタ内のワークロードが Standard クラスタの依存関係にアクセスできるようになります。手順については、エクスポートするサービスの登録をご覧ください。
- マルチクラスタ Ingress とマルチクラスタ Service をデプロイして、クラスタ間のインバウンド トラフィックを制御します。Standard クラスタにのみトラフィックを送信するようにマルチクラスタ Service を構成します。手順については、クラスタ間での Ingress のデプロイをご覧ください。
- 更新されたマニフェストを使用して、ステートレス ワークロードを Autopilot クラスタにデプロイします。エクスポートされたマルチクラスタ Service に対応するステートフル ワークロードが自動的に選択さ、そのワークロードにトラフィックが送信されます。
- インバウンド トラフィックを Autopilot クラスタに転送するようにマルチクラスタ Service を更新します。手順については、クラスタの選択をご覧ください。
これで、Autopilot クラスタからステートレス ワークロードが提供されるようになりました。移行元クラスタにステートレス ワークロードのみがあり、依存関係が残っていない場合は、移行を完了するをご覧ください。ステートフル ワークロードがある場合は、ステートフル ワークロードを手動で移行するに進みます。
ステートフル ワークロードを手動で移行する
ステートレス ワークロードを移行した後、Standard クラスタのステートフル ワークロードを停止して移行する必要があります。この手順では、クラスタのダウンタイムが必要になります。
- 環境のダウンタイムを開始します。
- ステートフル ワークロードを停止します。
- Autopilot との互換性を確保するために、ワークロード マニフェストが変更されていることを確認します。詳細については、プリフライトの結果に基づいてワークロードの仕様を変更するをご覧ください。
Autopilot クラスタにワークロードをデプロイします。
Autopilot クラスタにステートフル ワークロードの Service をデプロイします。
ステートレス ワークロードが引き続きバックエンド ワークロードと通信できるように、クラスタ内ネットワーキングを更新します。
- Standard クラスタのバックエンド サービスで静的 IP アドレスを使用していた場合は、Autopilot でその IP アドレスを再利用します。
- Kubernetes に IP アドレスの割り当てを許可する場合は、バックエンド Service をデプロイし、新しい IP アドレスを取得して、そのアドレスを使用するように DNS を更新します。
この段階で、次の条件を満たしている必要があります。
- すべてのステートレス ワークロードが Autopilot で実行されている。
- バックエンドのステートフル ワークロードも Autopilot で実行されている。
- ステートレス ワークロードとステートフル ワークロードが相互に通信できる。
- マルチクラスタ Service がすべてのインバウンド トラフィックを Autopilot クラスタに転送する。
すべてのワークロードと Kubernetes オブジェクトを新しいクラスタに移行したら、移行を完了するをご覧ください。
別の方法: ダウンタイム中にすべてのワークロードを手動で移行する
マルチクラスタ Service とマルチクラスタ Ingress を使用して最小限のダウンタイムでワークロードを移行しない場合は、ダウンタイム中にすべてのワークロードを移行します。この方法では、サービスのダウンタイムが長くなりますが、マルチクラスタ機能を使用する必要はありません。
- ダウンタイムを開始します。
- Autopilot クラスタにステートレス マニフェストをデプロイします。
- ステートフル ワークロードを手動で移行します。手順については、ステートフル ワークロードを手動で移行するをご覧ください。
- Service の新しい IP アドレスを使用するように、クラスタ内トラフィックとインバウンド外部トラフィックの両方の DNS レコードを変更します。
- ダウンタイムを終了します。
移行を完了する
すべてのワークロードと Service を新しい Autopilot クラスタに移行したら、ダウンタイムを終了し、環境がソーキングされるまで一定の期間待機します。移行の状態に問題がなく、移行をロールバックする必要がないことが確認できたら、移行アーティファクトをクリーンアップして移行を完了します。
省略可: マルチクラスタ機能をクリーンアップする
マルチクラスタ Ingress とマルチクラスタ Service を使用して移行した後、Autopilot クラスタをフリートに登録されたままにしない場合は、次の操作を行います。
- インバウンド外部トラフィックの場合は、Ingress をデプロイして、ワークロードを公開する Service の IP アドレスに設定します。手順については、外部アプリケーション ロードバランサの上り（内向き）をご覧ください。
- クラスタ内のトラフィック（フロントエンド ワークロードからステートフル依存関係へのトラフィックなど）の場合は、これらの Service の IP アドレスを使用するようにクラスタの DNS レコードを更新します。
- 移行中に作成したマルチクラスタ Ingress とマルチクラスタ Service リソースを削除します。
- マルチクラスタ Ingress とマルチクラスタ Service を無効にする。
- フリートから Autopilot クラスタの登録を解除する。
Standard クラスタを削除する
移行が完了して十分な時間が経過し、新しいクラスタの状態に問題がなければ、Standard クラスタを削除します。バックアップした Standard マニフェストは残しておくことをおすすめします。
失敗した移行をロールバックする
問題が発生し、Standard クラスタに戻す場合は、移行の実行方法に応じて次のいずれかを行います。
移行中に Backup for GKE を使用してバックアップを作成した場合は、元の Standard クラスタにバックアップを復元します。手順については、バックアップを復元するをご覧ください。
ワークロードを手動で移行した場合は、Standard クラスタを移行先、Autopilot クラスタを移行元にして、前のセクションで説明した移行操作を行います。大まかな流れは次のとおりです。
- ダウンタイムを開始します。
- ステートフル ワークロードを Standard クラスタに手動で移行します。手順については、ステートフル ワークロードを手動で移行するをご覧ください。
- 移行前にバックアップした元のマニフェストを使用して、ステートレス ワークロードを Standard クラスタに移動します。
- Ingress を Standard クラスタにデプロイし、DNS を Service の新しい IP アドレスにカットオーバーします。
- Autopilot クラスタを削除します。