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 クラスタは多くのセキュリティ設定がデフォルトで有効になっており、最初から高度なセキュリティが組み込まれています。セキュリティ パッチは、お客様が構成したメンテナンス スケジュールに従い、取得可能になった時点でノードに自動的に適用されます。
- 料金: Autopilot の料金モデルは、請求の予測とアトリビューションを簡素化します。
- ノード管理: Google がワーカーノードを管理するため、ワークロードに対応する新しいノードをお客様が作成する必要はありません。また、自動アップグレードや修復を構成する必要もありません。
- スケーリング: ワークロードの負荷が向上し、そのトラフィックに対応するために（Kubernetes の水平 Pod 自動スケーリングなどによって）Pod を追加すると、それらの Pod 用の新しいノードが自動的にプロビジョニングされ、必要に応じて既存ノードのリソースが自動的に拡張されます。
- スケジューリング: Autopilot は Pod のビンパッキングを管理します。そのため、各ノードで実行されている Pod の数を気にする必要はありません。アフィニティや Pod スプレッド トポロジなどの Kubernetes メカニズムを使用して、Pod の配置を詳細に制御できます。
- リソース管理: CPU やメモリなどのリソース値を設定せずにワークロードをデプロイした場合は、事前構成されたデフォルト値が自動的に設定され、ワークロード レベルでリソース リクエストが変更されます。
- ネットワーキング: Autopilot では、デフォルトでネットワーキング セキュリティ機能が有効になります。たとえば、Pod ネットワーク トラフィックはすべて、たとえそのトラフィックがクラスタ内の他の Pod へ向かう場合でも、Virtual Private Cloud ファイアウォール ルールによって検査されます。
- リリース管理: すべての Autopilot クラスタは GKE リリース チャンネルに登録されます。そのため、コントロール プレーンとノードはそのチャンネル内の最新の認定バージョンで実行されます。
- 柔軟な管理: ワークロードで特定のハードウェアまたはリソース（GPU など）を使用する必要がある場合は、ComputeClass でそれらの要件を定義できます。ワークロードで ComputeClass をリクエストすると、GKE はお客様が定義した要件を使用して Pod のノードを構成します。ノードまたは個々のワークロード用のハードウェアを手動で構成する必要はありません。
- 運用の複雑さの軽減: Autopilot では、ノードの継続的なモニタリングや、スケーリング、オペレーションのスケジュール設定を行う必要がなくなるため、プラットフォーム管理のオーバーヘッドが削減されます。
Autopilot には、コントロール プレーンと、Pod で使用されるコンピューティング容量の両方をカバーする SLA が用意されています。
Autopilot のコンテナ最適化コンピューティング プラットフォームについて
GKE バージョン 1.32.3-gke.1927002 以降の Autopilot には、ワークロードの実行用に特別なコンテナ最適化コンピューティング プラットフォームが含まれています。このプラットフォームは、ウェブサーバーや中程度のバッチジョブなど、特定のハードウェアを必要としないほとんどの汎用ワークロードに適しています。
コンテナ最適化コンピューティング プラットフォームで使用される GKE Autopilot ノードは、実行中に動的にサイズ変更することができ、1 コア未満の CPU から最小限の中断でスケールアップするように設計されています。この動的なサイズ変更により、ワークロードの規模に合わせて新しい容量をプロビジョニングするために必要な時間が大幅に短縮されます。スケーリングとサイズ変更の速度を向上させるため、事前にプロビジョニングされたコンピューティング容量のプールも維持されており、リソース需要の増加に応じてこれらのコンピューティング容量がワークロードに自動的に割り当てられます。
コンテナ最適化コンピューティング プラットフォームには、次の利点があります。
- コンピューティング容量がワークロードと一致する: Pod の数やリソース消費量などの要素に基づいて、Autopilot がコンテナ最適化コンピューティング プラットフォームのコンピューティング容量を動的に調整します。その結果、クラスタ内のコンピューティング容量がワークロードのニーズと一致します。
- スケーリング時間の短縮: より多くの Pod やリソース消費量の増加に対応するため、GKE はスケールアップ イベント中に既存のノードのサイズを動的に変更できます。この動的な容量プロビジョニングにより、新しい 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 モードを使用できます。GKE の推奨される使用方法は、Autopilot クラスタです。Autopilot クラスタでは、クラスタ全体で Google のベスト プラクティスがデフォルトで使用されます。
ただし、組織によっては、手動での制御や柔軟性に関する要件のために 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 では、クラスタ内の 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 を選択します。
Google Cloud コンソールを使用して Autopilot クラスタにアプリをデプロイして公開する方法のインタラクティブなガイドを見るには、[ガイドを表示] をクリックしてください。
次の表に、一般的な要件と推奨する対処方法を示します。
| ユースケース | リソース |
|---|---|
| クラスタをスケーリングするときに個々のノード プロパティを制御する | カスタムの ComputeClass を作成し、ワークロード マニフェストでその 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、メモリ、エフェメラル ストレージ リソースをリクエストできます。許可される範囲は、Pod を Autopilot コンテナ最適化コンピューティング プラットフォームで実行するか、または特定のハードウェアで実行するかによって異なります。デフォルトのコンテナ リソース リクエストと許可されるリソースの範囲については、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 が自動アップグレードを実行できるタイミングを制御するには、メンテナンスの時間枠を作成します。たとえば、マルチプレーヤー型ゲームの週 1 回のリセットの前夜にメンテナンスの時間枠を設定すると、プレイヤーがリセット時に混乱なくログインできます。
- 特定の期間内で 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 クラスタのトラブルシューティングをご覧ください。