このページは、ワークロードに最適な Google Kubernetes Engine（GKE）モードを選択するのに役立ちます。このページは、GKE をマネージド Kubernetes プロバイダとしてしており、Google Cloud で利用可能なオプションを確認する必要があるプラットフォーム管理者を対象としています。GKE をプラットフォームとしてコンテナ化するアプリケーションに最適な選択肢であるかどうかを確認するには、GKE の概要をご覧ください。
GKE のクラスタでは、次のオペレーション モードが用意されています。
- 自動パイロット モード（推奨）: GKE は、ノード構成、自動スケーリング、自動アップグレード、ベースライン セキュリティ構成、ベースライン ネットワーキング構成など、基盤となるインフラストラクチャを管理します。
- 標準モード: 個々のノードの構成など、基盤となるインフラストラクチャを管理します。
クラスタの作成後に、クラスタを 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 モードを使用する理由
標準モードでは、クラスタとノードのすべての構成設定を管理します。これには、特性を共有するノードプールと呼ばれるノードのグループも含まれます。共有責任モデルでは、Google は引き続きコントロール プレーンを管理しますが、ノードを構成する必要があります。ご自身で管理する設定は次のとおりです。
- ノードプール: 同様の構成設定を持つノードのグループを作成して管理します。
- セキュリティ: GKE スタンダード クラスタにはデフォルトの強化措置が適用されますが、Workload Identity や シールドされた GKE ノードなど、多くの GKE セキュリティ機能はデフォルトでは有効になっていません。これらの機能は、手動で有効にして設定を行うことが可能です。
- スケジューリング: 未使用のリソースを GKE で効率的にスケジュールして、未使用のリソースを最小限に抑える（ビンパッキング）ように、ワークロードをモニタリングして設計する必要があります。
- スケーリング: ノードの自動プロビジョニングと自動スケーリングを設定して構成し、ノードのリソースが多すぎたり少なすぎたりしないようにする必要があります。
- リソース管理: リソース リクエストがワークロード要件を満たすように、標準クラスタで実行する各ワークロードのリソースニーズを評価する必要があります。
- バージョン管理: GKE の自動アップグレードやリリース チャンネルの登録などのベスト プラクティスは、デフォルトで無効になっています。クラスタを作成または更新するときに、自動アップグレードと GKE バージョンを構成できます。
料金の違い
Autopilot の料金モデルは、次の点でスタンダードとは異なります。
- 自動パイロット モード: ワークロードが実行中に使用するコンピューティング リソースに対してのみ料金が発生します。ノードで未使用のリソース、OS 実行コスト、スケジュールされていないワークロード、システム ワークロードに料金はかかりません。詳細については、Autopilot の料金をご覧ください。
- 標準モード: Pod がノード上で実行されているかどうかに関係なく、各ノードのコンピューティング リソースに対して課金されます。未使用のリソースに対する料金が発生するため、ノードのリソース消費を最小限に抑えるには、ワークロードのスケジューリングを管理する必要があります。詳細については、標準料金をご覧ください。
標準クラスタでリソース使用効率を一定に保つには、クラスタの状態を継続的にモニタリングする必要があります。Autopilot クラスタでは、GKE がモニタリングと管理を行います。
標準クラスタでは、ノード上の未使用のコンピューティング リソースに対する料金が発生します。ビンパッキング を使用すると、可能な限り多くの Pod を各ノードに配置し、容量を無駄にしないように、これらのコストを削減できます。ビンパッキングには、継続的なワークロード管理とスケジューリングのカスタマイズが必要です。Autopilot クラスタを使用すれば、ワークロードで使用されるリソースに対してのみ課金されるため、ワークロードをバイナリパックする必要がなくなります。
Autopilot の代わりに Standard を使用する場合
ほとんどのワークロードには Autopilot を使用することをおすすめしますが、事前構成済みの強化やデフォルトのクラスタ構成により、Autopilot が満たせない特定の要件がある場合があります。次のような場合は、Autopilot モードではなく Standard モードを使用することをおすすめします。
SSH を使用してノードに直接接続するなど、クラスタやノードの構成を細かく制御する必要がある場合。
ノード オペレーティング システムの変更など、ノード自体で実行されているソフトウェアをインストールまたは変更する場合。
Linux sysctls の設定などによって、ノードシステム構成をカスタマイズする場合。
Autopilot によって制限されるアクション（たとえば、
kube-systemなどの GKE マネージド名前空間でのワークロードの実行）を実行する場合。これらの名前空間にはワークロードをデプロイしないようおすすめします。Cloud TPU など、Standard でのみ使用できる特定の GKE 機能を使用する場合。
オープンソースの Kubernetes でアルファ版機能をテストする場合。
未使用の容量をクラスタにプロビジョニングする場合。
このような特定の要件がある場合を除き、ワークロードで Autopilot を試すことをおすすめします。Autopilot クラスタを設定して hello-world アプリケーションを公開するインタラクティブなチュートリアルについては、Google Cloud コンソールの Autopilot チュートリアルをご覧ください。
次のステップ
- Autopilot と Standard の機能の詳細な比較をご覧ください。
- Autopilot クラスタを作成する。
- GKE クラスタのアーキテクチャについて学習する。
- Autopilot の詳細を学習する。