Autopilot は、Google Kubernetes Engine（GKE）のマネージド運用モードです。このページでは、Autopilot モードのメリットについて説明し、クラスタの計画、ワークロードのデプロイ、ネットワーキングとセキュリティの構成に関する情報を提供します。管理者、アーキテクト、オペレーターは、この情報を参考にして、GKE Autopilot モードがコンテナ化されたワークロードの運用要件にどの程度適合するかを評価する際に、十分な情報に基づいて意思決定を行うことができます。
GKE のオペレーション モードの違いについては、GKE Autopilot と Standard の比較をご覧ください。
Autopilot とは
GKE Autopilot は GKE で運用されるモードの一つで、ノード、スケーリング、セキュリティ、その他の事前構成された設定など、インフラストラクチャ構成を Google が管理します。Autopilot モードは、ほとんどの本番環境ワークロードを実行するように最適化されており、Kubernetes マニフェストに基づいてコンピューティング リソースをプロビジョニングします。
クラスタ全体を Autopilot モードで実行して、クラスタとそのすべてのワークロードが、スケーリング、セキュリティ、アップグレード、ノード構成に関する GKE のベスト プラクティスと推奨事項に沿って動作するようにできます。GKE Standard クラスタで、特定のワークロードを Autopilot モードで実行することもできます。このオプションを使用すると、インフラストラクチャを手動で制御する必要がある環境で Autopilot を使用できます。詳細については、GKE Standard での Autopilot モードのワークロードについてをご覧ください。
利点
- アプリケーションに専念する: Google がインフラストラクチャを管理するため、アプリケーションの構築とデプロイに専念できます。
- セキュリティ: Autopilot クラスタにはデフォルトのセキュリティ強化構成があり、多くのセキュリティ設定がデフォルトで有効になっています。GKE は、構成されたメンテナンス スケジュールに従って、取得可能になった時点でノードにセキュリティ パッチを自動的に適用します。
- 料金: Autopilot の料金モデルは、請求の予測とアトリビューションを簡素化します。
- ノード管理: Google がワーカーノードを管理するため、ワークロードに対応する新しいノードを作成していただく必要はありません。また、自動アップグレードと修復を構成していただく必要もありません。
- スケーリング: ワークロードに高い負荷がかかり、トラフィックに対応するために Pod を追加する（Kubernetes の水平 Pod 自動スケーリングなどにより）と、GKE はそれらの Pod に新しいノードを自動的にプロビジョニングし、必要に応じて既存のノードのリソースを自動的に拡張します。
- スケジューリング: Autopilot は Pod のビンパッキングを管理します。したがって、各ノードで実行されている Pod の数を考慮する必要はありません。アフィニティや Pod スプレッド トポロジなどの Kubernetes メカニズムを使用して、Pod の配置を詳細に制御できます。
- リソース管理: CPU やメモリなどのリソース値を設定せずにワークロードをデプロイする場合、Autopilot は事前構成済みのデフォルト値を自動的に設定し、ワークロード レベルでリソース リクエストを変更します。
- ネットワーキング: Autopilot は、デフォルトでネットワーキング セキュリティ機能を有効にします。たとえば、すべての Pod ネットワーク トラフィックが Virtual Private Cloud ファイアウォール ルールを通過するようにします（トラフィックがクラスタ内の他の Pod に送信される場合も同様です）。
- リリース管理: すべての Autopilot クラスタは GKE リリース チャンネルに登録されます。これにより、コントロール プレーンとノードがそのチャンネル内の最新の認定バージョンで実行されます。
- 柔軟な管理: ワークロードに特定のハードウェアまたはリソース（GPU など）の要件がある場合は、ComputeClasses でこれらの要件を定義できます。ワークロードで ComputeClass をリクエストすると、GKE は要件を使用して Pod のノードを構成します。ノードまたは個々のワークロードのハードウェアを手動で構成する必要はありません。
- 運用の複雑さの軽減: Autopilot では、ノードの継続的なモニタリングや、スケーリング、オペレーションのスケジュール設定を行う必要がなくなるため、プラットフォーム管理のオーバーヘッドが削減されます。
Autopilot には、コントロール プレーンと、Pod で使用されるコンピューティング容量の両方をカバーする SLA が用意されています。
Autopilot のコンテナ最適化コンピューティング プラットフォームについて
GKE バージョン 1.32.3-gke.1927002 以降では、Autopilot にワークロード用の専用のコンテナ最適化コンピューティング プラットフォームが含まれています。このプラットフォームは、ウェブサーバーや中程度のバッチジョブなど、特定のハードウェアを必要としないほとんどの汎用ワークロードに適しています。
コンテナ最適化コンピューティング プラットフォームは、実行中に動的にサイズ変更できる GKE Autopilot ノードを使用します。このノードは、CPU の一部からスケールアップするように設計されており、中断を最小限に抑えることができます。この動的サイズ変更により、ワークロードのスケーリングに合わせて新しい容量をプロビジョニングするために必要な時間が大幅に短縮されます。スケーリングとサイズ変更の速度を向上させるために、GKE は、リソース需要の増加に応じてワークロードに自動的に割り当て可能な、事前プロビジョニングされたコンピューティング容量のプールも維持します。
コンテナ用に最適化されたコンピューティング プラットフォームには、次の利点があります。
- コンピューティング容量がワークロードと一致する: Autopilot は、Pod の数やリソース使用量などの要因に基づいて、コンテナ最適化コンピューティング プラットフォームのコンピューティング容量を動的に調整します。その結果、クラスタ内のコンピューティング容量がワークロードのニーズと一致します。
- スケーリング時間の短縮: スケールアップ イベント中に、GKE は既存のノードのサイズを動的に変更して、より多くの Pod やリソース消費量の増加に対応できます。この動的容量プロビジョニングにより、新しい Pod が新しいノードの起動を待つ必要がなくなります。
Autopilot のコンテナ最適化コンピューティング プラットフォームは、次の方法で使用できます。
- Autopilot クラスタ: 特定のハードウェアを選択しない Pod は、デフォルトでこのコンピューティング プラットフォームを使用します。
- Standard クラスタ: 組み込みの Autopilot ComputeClass のいずれかを選択して、特定の Pod をコンテナ最適化コンピューティング プラットフォームに配置できます。
料金
Autopilot の料金は、Pod が使用するハードウェアのタイプに応じて、次のように異なるモデルを使用します。
汎用 Autopilot Pod: 次のタイプの Pod は、Pod ベースの課金モデルを使用し、汎用 Pod として分類されます。
- Autopilot クラスタまたは Standard クラスタのコンテナ最適化コンピューティング プラットフォームで実行される Pod。
- Autopilot クラスタで
BalancedまたはScale-Outの組み込み ComputeClass を選択する Pod。
詳細については、Google Kubernetes Engine の料金の「汎用 Autopilot ワークロード」セクションをご覧ください。
特定のハードウェアを選択する Autopilot ワークロード: 特定のハードウェア（Compute Engine マシンシリーズやハードウェア アクセラレータなど）を選択する Pod は、ノードベースの課金モデルを使用します。このモデルでは、基盤となるハードウェアとノード管理プレミアムの料金を支払います。
詳細については、Google Kubernetes Engine の料金の「特定のハードウェアを選択する Autopilot ワークロード」をご覧ください。
Autopilot クラスタとワークロード
GKE では、クラスタ全体または Standard クラスタ内の特定のワークロードに Autopilot モードを使用できます。Autopilot クラスタは、クラスタ全体で Google のベスト プラクティスがデフォルトで使用されるため、GKE の推奨される使用方法です。
ただし、一部の組織には、手動制御や柔軟性に関する要件があり、GKE Standard クラスタを使用する必要があります。このような場合でも、Standard クラスタの特定のワークロードに Autopilot を使用できます。これにより、ワークロード レベルで多くの Autopilot 機能を利用できます。
以降のセクションでは、Autopilot クラスタを計画して作成する方法について説明します。Standard クラスタがあり、一部のワークロードを Autopilot モードで実行する場合は、GKE Standard での Autopilot モードのワークロードについてをご覧ください。
Autopilot クラスタを計画する
クラスタを作成する前に、 Google Cloud アーキテクチャを計画して設計します。Autopilot では、ワークロードの仕様でハードウェアをリクエストします。GKE は、これらのワークロードを実行するために、対応するインフラストラクチャをプロビジョニングして管理します。たとえば、ML ワークロードを実行する場合は、ハードウェア アクセラレータをリクエストします。Android アプリを開発する場合は、Arm CPU をリクエストします。
ワークロードのスケールに基づいて、 Google Cloud プロジェクトまたは組織の割り当てを計画し、リクエストします。GKE がワークロードのインフラストラクチャをプロビジョニングできるのは、プロジェクトにそのハードウェアに対する十分な割り当てがある場合のみです。
計画するときは、次の要素を考慮してください。
- クラスタのサイズとスケールの見積もり
- ワークロード タイプ
- クラスタのレイアウトと使用状況
- ネットワークのレイアウトと構成
- セキュリティの構成
- クラスタの管理とメンテナンス
- ワークロードのデプロイと管理
- ロギングとモニタリング
以降のセクションでは、これらの考慮事項に関する情報と有用なリソースについて説明します。
ネットワーキング
パブリック ネットワーキングを使用して Autopilot クラスタを作成すると、クラスタ内のワークロードは相互に通信でき、インターネットとも通信できます。これは、デフォルトのネットワーキング モードです。 Google Cloud と Kubernetes には、プライベート ネットワーキングを使用するクラスタなど、要件に基づいて使用できるさまざまな追加のネットワーキング機能が用意されています。
Kubernetes とクラウドのネットワーキングは複雑です。Google Cloud に設定されたデフォルトの変更を開始する前に、ネットワーキングの基本コンセプトを理解しておいてください。次の表では、ユースケースに基づいて GKE でのネットワーキングの詳細を確認するためのリソースを示します。
| ユースケース | リソース |
|---|---|
| Kubernetes と GKE におけるネットワーキングの仕組みを理解する |
ネットワーキング モデルについて学習したら、組織のネットワークとネットワーク セキュリティの要件を検討します。これらの条件を満たす GKE と Google Cloud ネットワーキング機能を選択します。 |
| GKE ネットワーク構成を計画する | Service あたりのエンドポイントや API リクエストの上限など、GKE のネットワーク割り当てを把握しておくことをおすすめします。以下のリソースは、ネットワーキング設定の特定の側面を計画するのに役立ちます。
|
| ワークロードを公開する |
|
| 複数のクラスタで高可用性の連携サービスを実行する | マルチクラスタ サービス（MCS）を使用します。 |
| 受信トラフィックを負荷分散する |
|
| クラスタ ネットワーク セキュリティを構成する |
|
| Kubernetes ネットワーク トラフィックを監視する | デフォルトでは、Autopilot は指標とオブザーバビリティに GKE Dataplane V2 を使用します。
|
スケーリング
大規模なプラットフォームを効果的に運用するには、計画と慎重な検討が必要です。設計のスケーラビリティを考慮する必要があります。スケーラビリティとは、サービスレベル目標（SLO）内に収めつつ、クラスタを拡張できる能力のことです。プラットフォーム管理者とデベロッパー向けの詳細なガイダンスについては、スケーラブルなクラスタを作成するためのガイドラインをご覧ください。
また、GKE の割り当てと上限も考慮する必要があります。特に、数千もの Pod を含む可能性のある大規模なクラスタを実行する予定の場合は、注意が必要です。
Autopilot では、GKE はクラスタ内の Pod 数に基づいてノードを自動的にスケーリングします。クラスタに実行中のワークロードがない場合、Autopilot はクラスタをゼロノードまで自動的にスケールダウンします。 クラスタのスケールダウン後、クラスタ内にノードが残らず、システム Pod はスケジュール不可の状態になります。これは想定された挙動です。新しく作成されるほとんどの Autopilot クラスタでは、最初にデプロイするワークロードのスケジュールに時間がかかることがあります。この理由は、新しい Autopilot クラスタでは作成時に使用可能なノード数がゼロであり、ワークロードをデプロイして追加ノードをプロビジョニングするまで待つためです。
クラスタ内の Pod の数を自動的にスケーリングするには、Kubernetes の水平 Pod 自動スケーリングなどのメカニズムを使用します。このメカニズムでは、組み込みの CPU とメモリの指標、または Cloud Monitoring のカスタム指標に基づいて Pod をスケーリングできます。さまざまな指標に基づいてスケーリングを構成する方法については、指標に基づいて Pod の自動スケーリングを最適化するをご覧ください。
セキュリティ
Autopilot クラスタは、デフォルトでセキュリティのベスト プラクティスと設定を有効化して適用します。このベスト プラクティスには、クラスタのセキュリティの強化および GKE セキュリティの概要の推奨事項の多くが含まれます。
Autopilot の強化策と特定のセキュリティ要件の実装方法については、Autopilot のセキュリティ対策をご覧ください。
クラスタの作成
環境を計画して要件を理解したら、Autopilot クラスタを作成します。新しい Autopilot クラスタは、一般公開されている IP アドレスを持つリージョン クラスタです。各クラスタには、ベースライン強化対策や自動スケーリングなどの機能があります。事前構成済みの機能の一覧については、GKE Autopilot と GKE Standard の比較をご覧ください。
外部 IP アドレスにアクセスできないクラスタを作成する場合は、ネットワーク分離を構成します。
Autopilot モードでワークロードをデプロイする
互換性のある Kubernetes ワークロードを Autopilot モードで実行すると、GKE がスケーリング、効率的なスケジューリング、基盤となるインフラストラクチャを管理します。汎用ワークロードにコンテナ最適化コンピューティング プラットフォームを使用することも、ComputeClass を使用してワークロードに特定のハードウェアを選択することもできます。
これらの Autopilot ワークロードは、次のいずれかの方法で実行できます。
- ワークロードを Autopilot クラスタにデプロイします。
- ワークロードを Standard クラスタにデプロイする場合は、Autopilot ComputeClass を選択します。
Autopilot クラスタにアプリをデプロイして公開する Google Cloud コンソールのインタラクティブなガイドについては、[ガイドを表示] をクリックしてください。
次の表に、一般的な要件と推奨する対処方法を示します。
| ユースケース | リソース |
|---|---|
| クラスタをスケーリングするときに個々のノード プロパティを制御する | カスタム ComputeClass を作成し、ワークロード マニフェストでリクエストします。詳細については、カスタム ComputeClass についてをご覧ください。 |
| Standard クラスタで Autopilot ワークロードを実行する | Standard クラスタで Autopilot ComputeClass を使用します。詳細については、GKE Standard での Autopilot モードのワークロードについてをご覧ください。 |
| Arm ワークロードを実行する | ComputeClass またはワークロード マニフェストで Arm CPU を含むマシンシリーズをリクエストします。詳細については、カスタム ComputeClass についてをご覧ください。 |
| 高速化された AI / ML ワークロードを実行する | ComputeClass またはワークロード マニフェストで GPU をリクエストします。ワークロード マニフェストで GPU をリクエストする方法については、Autopilot に GPU ワークロードをデプロイするをご覧ください。 |
| バッチジョブなどのフォールト トレラントなワークロードを低コストで実行します。 |
Spot Pod では、任意の ComputeClass またはハードウェア構成を使用できます。 |
| ゲームサーバーや作業キューなど、中断を最小限にする必要があるワークロードを実行する | Autopilot クラスタでのみ、Pod 仕様で cluster-autoscaler.kubernetes.io/safe-to-evict=false アノテーションを指定します。Pod は、最大 7 日間、ノードの自動アップグレードやスケールダウン イベントによって生じるエビクションから保護されます。詳細については、Autopilot Pod の実行時間を延長するをご覧ください。 |
| ノード上の Pod リソース リクエストの合計で使用可能な未使用のリソースがある場合、ワークロードがリクエストを超えてバーストできるようにします。 | リソース limits を requests よりも高く設定するか、リソース上限を設定しないでください。詳細については、GKE で Pod バースト機能を構成するをご覧ください。 |
Autopilot を使用すると、ワークロード用の CPU、メモリ、エフェメラル ストレージ リソースをリクエストできます。許可される範囲は、Autopilot コンテナ最適化コンピューティング プラットフォームで Pod を実行するか、特定のハードウェアで実行するかによって異なります。デフォルトのコンテナ リソース リクエストと許容リソース範囲については、Autopilot のリソース リクエストをご覧ください。
ワークロードの分離
Autopilot クラスタは、ノードセレクタとノード アフィニティを使用してワークロードの分離を構成します。ワークロードの分離は、カスタム ノードラベルなどの特定の基準を満たすノードにワークロードを配置するように GKE に指示する必要がある場合に役立ちます。たとえば、GKE に game-server ラベルが付いているノードでゲームサーバー Pod をスケジュールするように指示して、それらのノード上の他の Pod がスケジュールされないようにします。
詳細については、GKE でワークロードの分離を構成するをご覧ください。
ゾーントポロジを使用して特定のゾーンで Pod をスケジューリングする
ゾーンの Compute Engine 永続ディスクの情報にアクセスするなど、特定の Google Cloud ゾーンに Pod を配置する必要がある場合は、GKE Pod を特定のゾーンに配置するをご覧ください。
Pod のアフィニティとアンチアフィニティ
Pod のアフィニティと反アフィニティを使用して、Pod を単一ノード上にともに配置するか、一部の Pod で他の Pod を避けるようにします。Pod のアフィニティと反アフィニティは、特定のリージョンやゾーンなど、特定のトポロジ ドメイン内のノードで実行されている Pod のラベルに基づいてスケジュールの決定を行うように Kubernetes に指示します。たとえば、同じノード上の他のフロントエンド Pod とともにフロントエンド Pod をスケジュールしないように GKE に指示することで、停止時の可用性を向上できます。
手順と詳細については、Pod のアフィニティとアンチアフィニティをご覧ください。
GKE では、topologyKey で次のラベルを持つ Pod のアフィニティと反アフィニティを使用できます。
topology.kubernetes.io/zonekubernetes.io/hostname
Pod トポロジの分散の制約
Kubernetes が Pod の数をスケールアップまたはスケールダウンしたときにワークロードの可用性を向上させるには、Pod トポロジの分散の制約を設定します。これにより、Kubernetes がリージョンなどのトポロジ ドメイン内のノードにわたって Pod を分散する方法を制御します。たとえば、us-central1 リージョンの 3 つの Google Cloud ゾーンのそれぞれに特定の数のゲームサーバー セッション Pod を配置するように Kubernetes に指示できます。
例、詳細、手順については、Pod トポロジの分散の制約をご覧ください。
Autopilot クラスタの管理とモニタリング
Autopilot では、GKE がコントロール プレーンとワーカーノードの両方のクラスタのアップグレードとメンテナンスを自動的に管理します。Autopilot クラスタには、クラスタとワークロードをモニタリングするための機能も組み込まれています。
GKE バージョンのアップグレード
すべての Autopilot クラスタが GKE リリース チャンネルに登録されます。リリース チャンネルでは、GKE がクラスタの Kubernetes バージョンを管理し、チャンネルに応じて機能の可用性とバージョンの安定性のバランスをとります。デフォルトでは、Autopilot クラスタは Regular リリース チャンネルに登録されますが、安定性と機能のニーズを満たす別のチャンネルを選択することもできます。リリース チャンネルの詳細については、リリース チャンネルについてをご覧ください。
GKE は、アップグレードを自動的に開始し、進行状況をモニタリングして、問題が発生した場合はオペレーションを一時停止します。アップグレード プロセスは、次の方法で手動で制御できます。
- GKE が自動アップグレードを実行できるタイミングを制御するには、メンテナンスの時間枠を作成します。たとえば、マルチプレーヤー ゲームの毎週のリセットの前夜にメンテナンスの時間枠を設定すると、プレイヤーがリセット時に混乱なくログインできます。
- 特定の期間内で GKE が自動アップグレードを開始できないタイミングを制御するには、メンテナンスの除外を使用します。たとえば、ブラック フライデーとサイバー マンデーのセール期間中にメンテナンスの除外を設定すると、問題なくショッピングすることができます。
- 自動アップグレードを開始する前に新しいバージョンを取得するには、コントロール プレーンを手動でアップグレードします。GKE は、時間の経過とともにノードのバージョンとコントロール プレーンのバージョンを調整します。
- 新しいリリース チャンネルでのみ利用可能なパッチ バージョンを取得するには、新しいチャンネルからパッチ バージョンを実行するをご覧ください。たとえば、最近の脆弱性開示の影響を軽減するために、特定のパッチ バージョンが必要になることがあります。
Autopilot クラスタをモニタリングする
Autopilot クラスタでは、Cloud Logging、Cloud Monitoring、Google Cloud Managed Service for Prometheus がすでに有効になっています。
Autopilot クラスタは、Google のテレメトリー収集のベスト プラクティスに沿って、次のタイプのログと指標を自動的に収集します。
Cloud Logging のログ
- システムログ
- ワークロード ログ
- 管理アクティビティ監査ログ
- データアクセス監査ログ
Cloud Monitoring の指標
- システム指標
- ワークロード指標（Google Cloud Managed Service for Prometheus から）
ロギングとモニタリングを有効にするために、追加の構成は必要ありません。次の表は、要件に基づいて収集されたテレメトリーを操作する方法を示しています。
| ユースケース | リソース |
|---|---|
| GKE ログを理解してアクセスする |
|
| GKE クラスタのパフォーマンスを観察する | クラスタのパフォーマンスを効果的にモニタリングすることで、クラスタとワークロードの運用費用を最適化できます。
|
| クラスタのセキュリティ ポスチャーをモニタリングする | セキュリティ ポスチャー ダッシュボードを使用して、実行中のワークロードを GKE のベスト プラクティスに対して監査し、コンテナのオペレーティング システムと言語パッケージの脆弱性をスキャンして、実行可能な緩和策を取得します。詳細は、セキュリティ ポスチャー ダッシュボードについてをご覧ください。 |
トラブルシューティング
トラブルシューティングの手順については、Autopilot クラスタのトラブルシューティングをご覧ください。