はじめに (導入)
Google Cloud の Google Kubernetes Engine のクラスタモード について調べる機会があったため、
Autopilot モードと Standard モードの違いやユースケースについてまとめてみたいとおもいます。(2024年2月時点)
GKE の Autopilot モードと Standard モード について
ご存知の方も多いとおもいますが、Google Kubernetes Engine （以下、GKE と記載します）は Google Cloud で利用できる、コンテナオーケストレーションツールである Kubernetes (以下、k8s と記載します) のマネージドサービスです。
コンテナ化されたアプリケーションを実行するインフラ構成のためのプラットフォームとして適している他、コントロールプレーンなどの管理は Google Cloud 側で行ってくれるため、オンプレミス環境で一から k8s 環境を構築・運用するのに比べ、管理の手間がかからないなどのメリットがあります。
k8s ではアプリケーションを実行するノードの集合体としてクラスタを作成します。GKE ではクラスタの作成において、Autopilot モードと、Standard モードを選択できるようになっています。
Autopilot モードは 2021年にリリースされ、それによって、2つのモード選択が可能となりました。
Autopilot モードの概要としては、Standard モードと比べてマネージドな部分が多く、管理の手間がよりかからなくなっていることや、課金体系も異なっています。
トレードオフとして、クラスタ内のリソースに対する細かい設定ができなかったり、構成に対しての制約が存在します。
Autopilot と Standard の比較
簡易比較表
Autopilot モードと、Standard モード の違いを簡単に記載した表が以下です。
| 項目 | Autopilot | Standard |
|---|---|---|
| コントロールプレーン管理 | フルマネージド | フルマネージド |
| ノード管理 | フルマネージド | ユーザー管理 |
| バージョンアップ | コントロールプレーン: 自動 ノード: 自動 |
コントロールプレーン: 自動 ノード: 手動 or 自動 |
| 課金体系 | クラスタ管理手数料 + Pod 単位使用料 | クラスタ管理手数料 + ノード単位使用料 |
| ノードの OS | containerd を含む Container-Optimized OS | デフォルト: containerd を含む Container-Optimized OS オプション: Runtime, OS を選択可能 |
| ノードのプロビジョニングとスケーリング | クラスタ内の Pod に基づいてノードの数とサイズを自動的にスケーリング | デフォルト: 新しいノードを手動でプロビジョニング, ノードリソースを手動で指定 オプション: Pod自動スケーリング |
| 対応ロケーション | リージョン | リージョン or ゾーン |
| SLA | コントロールプレーンの SLA + Pod の SLA | コントロールプレーンの SLA + ノード(GCE) の SLA |
| セキュリティ | Workload Identity 連携など幾つかの項目が事前構成済み | 事前構成済みの項目はなし |
| ネットワーキング | VPC ネイティブ | VPC ネイティブ or ルートベース |
Autopilot モードの特徴
Standard モードと比較して、ノード管理もフルマネージドなため、保守運用の手間がかからないのが特徴と言えます。セキュリティに関しては、以下が事前構成により組み込まれています。
ノードあたりの稼働可能なPod数について、Standard と比較して少ない特徴があります。
- Workload Identity
- シールド付きノード
- セキュアブート
- GKE Sandbox
また、料金についてはクラスタ管理料と Pod単位での使用したリソースに対する課金となるため、ノードの余剰リソースについて課金されないことが特徴として挙げられるとおもいます。
Standard モード の特徴
Autopilot モードと比較してユーザーで管理が必要な部分が多いものの、ノードのサイジングやネットーワーク設定のカスタマイズ、コンテナランタイムやOSを選択可能であるなど、詳細な設定が可能となっています。セキュリティについては事前構成されているものはないため、必要なものをユーザーが設定する必要があります。
また、料金については、クラスタ管理料と稼働ノードに対して発生するため、ノードの余剰リソースがないように効率的に使用することが望ましいと言えます。
制約事項
Autopilot は管理の手間が省ける反面、制限事項があります。下記にいくつか記載します。詳細は公式ドキュメントをご参照ください。
- Privileged Pod が利用不可
- hostNetwork が利用不可
- hostPort のランダム割り当て
- /var/logへの読み取りのみ許可 (それ以外のすべての読み取りまたは書き込みアクセスを拒否)
- ノードへのSSHアクセス不可
Autopilot モードのユースケース
ここまでの内容をふまえると、Autopilot は以下のようなユースケースに適していそうです。
- 大量のトラフィックが発生しない、小規模なアプリケーション
- 大規模なスケーリングを必要としないアプリケーション
- PoC, 開発環境など、手早く環境を構築したい場合
- バッチ処理用
参考
まとめ
GKE の AutopilotモードとStandardモード についてみてきました。Autopilotモード は管理が簡単で Pod 単位の課金が特徴ですが、リソース設定のカスタマイズに制限があります。対して Standardモード はより細かい設定が可能でユーザーがノードを管理する必要があり、ノード単位での課金が行われます。Autopilotは小規模アプリケーションや開発環境に適しており、Standardは詳細設定が必要な場合や大規模アプリケーション向けとなっています。
