このページでは、ワークロードに最適な Google Kubernetes Engine（GKE）のオペレーション モードを選択する方法について説明します。このページは、GKE をマネージド Kubernetes プロバイダとして検討しており、Google Cloud で使用可能なオプションを確認する必要があるプラットフォーム管理者を対象としています。プラットフォームとしての GKE がコンテナ化されたアプリケーションに適しているかどうかを確認するには、GKE の概要と GKE と Cloud Run をご覧ください。
GKE のクラスタでは、次のオペレーション モードが用意されています。
- Autopilot モード（推奨）: 基盤となるインフラストラクチャ（ノード構成、自動スケーリング、自動アップグレード、ベースライン セキュリティ構成、ベースライン ネットワーキング構成など）は GKE によって管理されます。
- Standard モード: 個々のノードの構成を含め、基盤となるインフラストラクチャをユーザーが管理します。
クラスタの作成後に、クラスタを Standard から Autopilot に変換することはできません。このページを確認し、必要に応じて Autopilot と Standard の比較を確認して、十分な情報に基づいて選択することをおすすめします。
GKE Autopilot モードを選ぶ理由
Google では、GKE Autopilot クラスタでほとんどのインフラストラクチャを管理しており、GKE Standard モードより高度のマネージド Kubernetes エクスペリエンスを提供しています。Autopilot クラスタのデフォルト構成は、ほとんどの本番環境ワークロード用に最適化されています。GKE Autopilot には、セキュリティ、スケーラビリティ、費用の最適化に関する多くの Kubernetes のベスト プラクティスがデフォルトで実装されています。
ほとんどの場合、Autopilot で本番環境ワークロードを実行することをおすすめします。
Autopilot には、次のようなメリットがあるデフォルト構成が用意されています。
- 費用対効果: 実行中にワークロードで使用されるコンピューティング リソースに対してのみ料金が発生します。ノードで未使用の容量、システム Pod、オペレーティング システムの費用、スケジュールされていないワークロードに対して料金はかかりません。
- 自動化: ノードの管理、アプリの新しいノードの作成、自動アップグレードと修復の構成は Google が行います。GKE は、トラフィックに基づいてノードとワークロードを自動的にスケーリングします。
- セキュリティ ポスチャーと信頼度の改善: Autopilot クラスタでは、多くの GKE セキュリティ設定と Kubernetes のベスト プラクティスがデフォルトで有効になります。GKE は、取得可能になった時点でノードにセキュリティ パッチを自動的に適用します。
GKE Autopilot のメリットの一覧については、GKE Autopilot についてをご覧ください。
GKE Standard モードを選ぶ理由
Standard モードでは、クラスタとノードのすべての構成設定を管理します（特性を共有するノードプールの管理も含みます）。責任共有モデルでは、引き続き Google がコントロール プレーンを管理しますが、ユーザーがノードを構成する必要があります。ユーザーが管理する設定には次のようなものがあります。
- ノードプール: 類似の構成設定を持つノードのグループを作成し、管理します。
- セキュリティ: GKE Standard クラスタにはデフォルトの強化措置が適用されますが、GKE 用 Workload Identity 連携や シールドされた GKE ノードなど、多くの GKE セキュリティ機能はデフォルトでは有効になっていません。これらの機能は手動で有効にして、設定できます。
- スケジューリング: 未使用のリソースを GKE で効率的にスケジュールして、未使用のリソースを最小限に抑える（ビンパッキング）ように、ワークロードをモニタリングして設計する必要があります。
- スケーリング: ノードの自動プロビジョニングと自動スケーリングを設定して構成し、ノードのリソースが多すぎたり少なすぎたりしないようにする必要があります。
- リソース管理: Standard クラスタで実行する各ワークロードのリソースニーズを評価して、リソース リクエストがワークロード要件を満たしていることを確認する必要があります。
- バージョン管理: GKE のバージョンの自動アップグレードやリリース チャンネル登録などのベスト プラクティスは、Standard ではデフォルトで無効になっています。クラスタを作成または更新するときに、自動アップグレードと GKE バージョンを構成できます。
料金の違い
Autopilot の料金モデルは、次の点で Standard とは異なります。
- Autopilot モード: 実行中にワークロードで使用されるコンピューティング リソースに対してのみ料金が発生します。ノードで未使用のリソース、OS 実行コスト、スケジュールされていないワークロード、システム ワークロードに料金はかかりません。詳細については、Autopilot の料金をご覧ください。
- Standard モード: Pod がノードで実行されているかどうかにかかわらず、各ノード上のコンピューティング リソースに対して料金が発生します。未使用のリソースには料金がかかるため、ワークロードのスケジューリングを管理して、ノードでのリソースの無駄を最小限に抑える必要があります。詳しくは、Standard の料金をご覧ください。
Standard クラスタで一貫したレベルのリソース使用効率を確保するには、クラスタの状態を継続的にモニタリングする必要があります。Autopilot クラスタでは、GKE がモニタリングと管理を行います。
Standard クラスタでは、ノード上の未使用のコンピューティング リソースに対して料金が発生します。ビンパッキング を使用すると、可能な限り多くの Pod を各ノードに配置し、容量を無駄にしないように、これらのコストを削減できます。ビンパッキングでは、継続的なワークロード管理とスケジュールのカスタマイズが必要です。Autopilot クラスタでは、ワークロードで使用されるリソースに対してのみ料金が発生するため、ワークロードをビンパッキングする必要はありません。
Autopilot ではなく Standard を使用する場合
ほとんどのワークロードには Autopilot の使用をおすすめしますが、事前構成済みの強化されたクラスタ構成やデフォルトのクラスタ構成には、Autopilot で対応できない特有の要件がある場合があります。次のシナリオでは、Autopilot モードではなく Standard モードの使用を検討してください。
SSH を使用してノードに直接接続する機能など、クラスタとノードの構成をきめ細かく制御する必要がある場合。
ノード オペレーティング システムの変更など、ノード自体で実行されているソフトウェアをインストールまたは変更する場合。
Linux sysctls の設定などによって、ノードシステム構成をカスタマイズする場合。
kube-systemなどの GKE マネージド Namespace でのワークロードの実行など、Autopilot によって制限されるアクションを実行する場合。これらの Namespace にはワークロードをデプロイしないようおすすめします。Cloud TPU など、Standard でのみ利用可能な特定の GKE 機能を使用する場合。
オープンソースの Kubernetes でアルファ版の機能をテストする場合。
未使用の容量をクラスタにプロビジョニングする場合。
このような特定の要件がない限り、ワークロードで Autopilot を試すことをおすすめします。Autopilot クラスタを設定して hello-world アプリケーションを公開するインタラクティブなチュートリアルについては、Google Cloud コンソールの Autopilot チュートリアルをご覧ください。
次のステップ
- Autopilot と Standard の詳細な機能比較を確認する。
- Autopilot クラスタを作成する。
- GKE クラスタ アーキテクチャの詳細を学習する。
- Autopilot の詳細を学習する。