このページでは、Google Kubernetes Engine（GKE）の Autopilot 運用モードについて説明し、クラスタの計画、設定、管理に使用できるリソースを提供します。
Autopilot とは
GKE Autopilot は GKE で運用されるモードの一つで、ノード、スケーリング、セキュリティ、その他の事前構成された設定など、クラスタ構成を Google が管理します。Autopilot クラスタは、ほとんどの本番環境ワークロードを実行するように最適化されており、Kubernetes マニフェストに基づいてコンピューティング リソースをプロビジョニングします。この合理化された構成は、クラスタとワークロードの設定、スケーラビリティ、セキュリティに関する GKE のベスト プラクティスと推奨事項を遵守しています。組み込まれている設定のリストについては、Autopilot と Standard の比較表をご覧ください。
料金
ほとんどの場合、GKE Autopilot での実行中にワークロードがリクエストした CPU、メモリ、ストレージに対してのみ料金が発生します。ノードは GKE によって管理されるため、ノードの未使用の容量に対しては課金されません。
システム Pod、オペレーティング システムの費用、スケジュールされていないワークロードについては、料金は発生しません。料金の詳細については、Autopilot の料金をご覧ください。
利点
- アプリケーションに専念する: Google がインフラストラクチャを管理するため、アプリケーションの構築とデプロイに専念できます。
- セキュリティ: クラスタにはデフォルトのセキュリティ強化構成があり、多くのセキュリティ設定がデフォルトで有効になっています。GKE は、構成されたメンテナンス スケジュールに従って、取得可能になった時点でノードにセキュリティ パッチを自動的に適用します。
- 料金: Autopilot の料金モデルは、請求の予測とアトリビューションを簡素化します。
- ノード管理: Google がワーカーノードを管理するため、ワークロードに対応する新しいノードを作成していただく必要はありません。また、自動アップグレードと修復を構成していただく必要もありません。
- スケーリング: ワークロードに高い負荷がかかり、トラフィックに対応するために Pod を追加する（Kubernetes の水平 Pod 自動スケーリングなどにより）と、GKE はそれらの Pod に新しいノードを自動的にプロビジョニングし、必要に応じて既存のノードのリソースを自動的に拡張します。
- スケジューリング: Autopilot は Pod のビンパッキングを管理します。したがって、各ノードで実行されている Pod の数を考慮する必要はありません。アフィニティや Pod スプレッド トポロジなどの Kubernetes メカニズムを使用して、Pod の配置を詳細に制御できます。
- リソース管理: CPU やメモリなどのリソース値を設定せずにワークロードをデプロイする場合、Autopilot は事前構成済みのデフォルト値を自動的に設定し、ワークロード レベルでリソース リクエストを変更します。
- ネットワーキング: Autopilot は、デフォルトでネットワーキング セキュリティ機能を有効にします。たとえば、すべての Pod ネットワーク トラフィックが Virtual Private Cloud ファイアウォール ルールを通過するようにします（トラフィックが他の Pod に送信される場合も同様です）。
- リリース管理: すべての Autopilot クラスタは GKE リリース チャンネルに登録されます。これにより、コントロール プレーンとノードがそのチャンネル内の最新の認定バージョンで実行されます。
- 柔軟な管理: ワークロードに特定のハードウェアまたはリソース（高使用率の CPU やメモリなど）の要件が存在する場合、Autopilot にはそのようなワークロードに合わせて構築され事前構成されたコンピューティング クラスが用意されています。カスタマイズされたマシンタイプとハードウェアに基づく新しいノードを手動で作成する必要はなく、その代わりにデプロイメントでコンピューティング クラスをリクエストします。GPU を選択して、バッチ アプリケーションや AI / ML アプリケーションなどのワークロードを高速化することもできます。
- 運用の複雑さの軽減: Autopilot では、ノードの継続的なモニタリングや、スケーリング、オペレーションのスケジュール設定を行う必要がなくなるため、プラットフォーム管理のオーバーヘッドが削減されます。
Autopilot には、コントロール プレーンと、Pod で使用されるコンピューティング容量の両方をカバーする SLA が用意されています。
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 ネットワーク トラフィックを監視する |
|
スケーリング
大規模なプラットフォームを効果的に運用するには、計画と慎重な検討が必要です。設計のスケーラビリティを考慮する必要があります。スケーラビリティとは、サービスレベル目標（SLO）内に収めつつ、クラスタを拡張できる能力のことです。プラットフォーム管理者とデベロッパー向けの詳細なガイダンスについては、スケーラブルなクラスタを作成するためのガイドラインをご覧ください。
また、GKE の割り当てと上限も考慮する必要があります。特に、数千もの Pod を含む可能性のある大規模なクラスタを実行する予定の場合は、注意が必要です。
Autopilot ワークロードをスケーリングする
Autopilot では、GKE はクラスタ内の Pod 数に基づいてノードを自動的にスケーリングします。クラスタに実行中のワークロードがない場合、Autopilot はクラスタをゼロノードまで自動的にスケールダウンします。新しく作成されるほとんどの Autopilot クラスタでは、最初にデプロイするワークロードのスケジュールに時間がかかることがあります。この理由は、新しい Autopilot クラスタでは作成時に使用可能なノード数がゼロであり、ワークロードがデプロイされるまでその状態で待機し、ワークロードがデプロイされてから追加ノードをプロビジョニングするためです。
クラスタ内の Pod の数を自動的にスケーリングするには、Kubernetes の水平 Pod 自動スケーリングなどのメカニズムを使用することをおすすめします。このメカニズムでは、組み込みの CPU とメモリの指標、または Cloud Monitoring のカスタム指標に基づいて、Pod をスケーリングできます。さまざまな指標に基づいてスケーリングを構成する方法については、指標に基づいて Pod の自動スケーリングを最適化するをご覧ください。
セキュリティ
Autopilot クラスタは、デフォルトでセキュリティのベスト プラクティスと設定を有効化して適用します。このベスト プラクティスには、クラスタのセキュリティの強化および GKE セキュリティの概要の推奨事項の多くが含まれます。
Autopilot の強化策と特定のセキュリティ要件の実装方法については、Autopilot のセキュリティ対策をご覧ください。
クラスタの作成
環境を計画して要件を理解したら、Autopilot クラスタを作成します。新しい Autopilot クラスタは、一般公開されている IP アドレスを持つリージョン クラスタです。各クラスタには、ベースライン強化対策や自動スケーリングなどの機能があります。事前構成済みの機能の一覧については、GKE Autopilot と GKE Standard の比較をご覧ください。
パブリック IP アドレスを持たないクラスタを作成する場合は、代わりに限定公開クラスタを作成します。
Autopilot にワークロードをデプロイする
実行中の Autopilot クラスタにワークロードをデプロイするには、Kubernetes マニフェストを作成してクラスタに適用します。デフォルトでは、Autopilot クラスタはほとんどの本番環境ワークロードを実行するように最適化されています。
アプリのデプロイと公開に関する Google Cloud コンソールのインタラクティブなガイドについては、[ガイドを表示] をクリックしてください。
一部のワークロードには、ハードウェア アクセラレータを必要とする ML ワークロードや、Arm アーキテクチャを必要とするモバイルアプリのテストなど、特殊なハードウェア要件がある場合があります。Autopilot には、特別なコンピューティング要件のあるワークロードを実行するように Google Cloud が構成されたコンピューティング クラスがあります。これらのワークロードをデプロイするときに、マニフェストでコンピューティング クラスをリクエストします。Autopilot は、専用マシンを基盤とするノードのプロビジョニング、スケジュール管理、ハードウェアの割り当てを自動的に行います。
次の表に、一般的な要件と推奨する対処方法を示します。
| ユースケース | リソース |
|---|---|
| Arm ワークロードを実行する | マニフェストで Scale-Out コンピューティング クラスと arm64 アーキテクチャをリクエストします。手順については、Arm アーキテクチャに Autopilot ワークロードをデプロイするをご覧ください。 |
| 高速化された AI / ML ワークロードを実行する | マニフェストで GPU をリクエストします。手順については、Autopilot に GPU ワークロードをデプロイするをご覧ください。 |
| 高いコンピューティングまたは高メモリ容量を必要とするワークロードを実行する | Balanced コンピューティング クラスをリクエストします。手順については、Autopilot Pod のコンピューティング クラスを選択するをご覧ください。 |
| CPU 容量の効率的な水平方向のスケーリングとコアごとのシングル スレッドを必要とするワークロードを実行する | Scale-Out コンピューティング クラスをリクエストします。手順については、Autopilot Pod のコンピューティング クラスを選択するをご覧ください。 |
| バッチジョブなどのフォールト トレラントなワークロードを低コストで実行する | マニフェストで Spot Pod を指定します。手順については、Spot Pod でフォールト トレラント ワークロードを低コストで実行するをご覧ください。 Spot Pod では、任意のコンピューティング クラスまたはハードウェア構成を使用できます。 |
| ゲームサーバーや作業キューなど、中断を最小限にする必要があるワークロードを実行する | Pod 仕様で cluster-autoscaler.kubernetes.io/safe-to-evict=false アノテーションを指定します。Pod は、最大 7 日間、ノードの自動アップグレードやスケールダウン イベントによって生じるエビクションから保護されます。詳細については、Autopilot Pod の実行時間を延長するをご覧ください。 |
| ノード上の Pod リソース リクエストの合計で使用可能な未使用のリソースがある場合、ワークロードがリクエストを超えてバーストできるようにします。 | リソース limits を requests よりも高く設定するか、リソース上限を設定しないでください。手順については、GKE で Pod バースト機能を構成するをご覧ください。 |
Autopilot を使用すると、ワークロード用の CPU、メモリ、エフェメラル ストレージ リソースをリクエストできます。許可される範囲は、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 の指標
- システム指標
- ワークロード指標（Managed Service for Prometheus から）
ロギングとモニタリングを有効にするために、追加の構成は必要ありません。次の表は、要件に基づいて収集されたテレメトリーを操作する方法を示しています。
| ユースケース | リソース |
|---|---|
| GKE ログを理解してアクセスする |
|
| GKE クラスタのパフォーマンスを観察する | クラスタのパフォーマンスを効果的にモニタリングすることで、クラスタとワークロードの運用費用を最適化できます。
|
| クラスタのセキュリティ対策をモニタリングする | セキュリティ対策ダッシュボードを使用して、実行中のワークロードを GKE のベスト プラクティスに対して監査し、コンテナのオペレーティング システムと言語パッケージの脆弱性をスキャンして、実行可能な緩和策を取得します。詳細は、[セキュリティ対策] ダッシュボードについてをご覧ください。 |
トラブルシューティング
トラブルシューティングの手順については、Autopilot クラスタのトラブルシューティングをご覧ください。