GKE StandardクラスタでAutopilotノードが利用できるようになったので見てみよう
はじめに
こんにちは。間瀬です。自身のZennアカウントでは初投稿になります。
記念すべき最初の投稿では、2025年9月末にGKEで利用可能になったStandardクラスタでAutopilotノードを利用することができる機能について紹介したいと思います。
Standardクラスタ vs Autopilotクラスタ
既にこれらの違いを理解している方は読み飛ばしていただいて問題ありません。
Standardクラスタは従来から存在するクラスタモードで、ユーザーがノードの管理を担うことに対し、Autopilotクラスタは比較的新しいクラスタモードで、ノードの管理を Google Cloud が担うフルマネージドのクラスタモードです。
Standardクラスタではノードの構成やプロビジョニング、バージョンをユーザーが柔軟に管理することができるメリットがありますが、開発・運用するためのノウハウが要求され運用負荷が高くなる傾向にあります。
Autopilotクラスタはこれらユーザーの課題に応えるものになっていて、Google Cloud のベストプラクティスに基づいたノードの構成と管理を自動化してくれることで運用負荷を削減することができます。
また、課金体系にも違いがあり、Standardクラスタはノード（VM）単位でのCPU/メモリ/ディスクに対する課金であるのに対し、AutopilotクラスタはPod単位に対するCPU/メモリ/ディスク課金となります。
例えると、水を購入するときにバケツに対してお金を支払うか、水道料金のように水の使用量に対してお金を支払うかの違いになります。
| 比較項目 | Standardクラスタ | Autopilotクラスタ |
|---|---|---|
| ノードの管理責任 | ユーザー | Google Cloud |
| 課金体系 | ノード（VM）単位 | Pod単位 |
| カスタマイズによる自由度 | 高い | 低い |
詳細に触れませんが、課金体系の違いと同様にSLAも異なっています。
どちらのクラスタモードが必ず良いというわけではなく、ユースケースと柔軟性やコスト最適化のしやすさといった観点から選択することになります。
個人的な経験ではAutopilotクラスタを選択することが多く、ワークロードが実行できないなどの問題や特別な制約がない限りはAutopilotクラスタを選択することを推奨しています。
「StandardクラスタでAutopilotノードを利用する」とは？
今回のアップデートでStandardとして作成されたクラスタ上で、Autopilotクラスタを利用する際のノードと同等のノードを利用できるようになりました。
同等というのは、上記で記述したようなノードの管理責任や課金体系、カスタマイズ性が同じであることを指しています。
メリット
StandardクラスタでAutopilotノードを利用できることで、以下のようなメリットが得られます。
1. ハイブリッドな運用が可能に
同一のStandardクラスタ内で、ワークロードの特性に応じて最適なノードを選択できるようになります。
例えばノードバージョンのアップデートを慎重に行う必要があったり、常時稼働する安定したワークロードは従来のノード上で管理しつつ、それら以外のワークロードはAutopilotノードで管理することでアップデートにかかる時間や運用負荷を削減しつつ、コスト削減効果も期待することができます。
2. ワークロードを容易にAutopilotノードへ移行することができる
クラスタを一度作成するとモードの移行はできないため、既にStandardクラスタを利用していてAutopilotクラスタに移行したい場合、Autopilotクラスタを新たに作成して移行する必要がありましたが、本機能によって一つのクラスタの中で既存のノードからAutopilotノードへ容易に移行することができます。
ノードプール
以降の解説の内容を理解しやすくするため、GKEのノードプールの概念について簡単に触れたいと思います。既にノードプールの概念を理解されている方は読み飛ばしていただいて問題ありません。
GKEにノードを作成・追加したい場合、ノード（例：仮想マシン1台）という単位で構成することはなく、必ずノードプールというグループのような単位で構成・管理することになります。一つのノードプール上で生成されるノードの構成は全て同じものになります。
Autopilotノードを利用してみる
ここからはStandardクラスタでAutopilotノードプールを作成し、利用する方法を解説していきます。
というものの、利用するための手順はほとんどありません。前提条件が幾つかあるので公式ドキュメントを確認してください。
1. ワークロードをデプロイするためのマニフェストで ComputeClass "Autopilot" を指定する
今回のアップデートで、Autopilotノードを利用するための ComputeClass が追加されているのでこれをマニフェストで指定します。
デフォルトでは、autopilot と autopilot-spot の2つの ComputeClass が利用できます。
後者については Autopilotノードでスポットインスタンスを利用することができます。ワークロードの停止が許容できる開発環境やジョブで活用することでコストを削減することができます。
以下はマニフェストのサンプルになります。今回はComputeClassとしてautopilotを指定しています。
apiVersion: apps/v1
kind: Deployment
metadata:
name: sample-http-server
labels:
app: sample-http-server
spec:
replicas: 3
selector:
matchLabels:
app: sample-http-server
template:
metadata:
labels:
app: sample-http-server
spec:
nodeSelector:
# AutopilotノードプールのComputeClassを指定 autopilot or autopilot-spot
cloud.google.com/compute-class: autopilot
containers:
- name: sample-http-server
image: asia-northeast1-docker.pkg.dev/my-project/apps/sample-http-server
ports:
- containerPort: 8080
resources:
requests:
cpu: "50m"
memory: "52Mi"
2. デプロイ
kubectl apply -f k8s-deployment-autopilot.yaml ← 上記yamlファイル名
上記デプロイ前のGKEクラスタノードは以下の通りでした。
gke-cluster-standard-default-pool-ce8cf66f-fts9 Ready <none> 73m v1.34.1-gke.2037001
gke-cluster-standard-default-pool-ce8cf66f-klkb Ready <none> 73m v1.34.1-gke.2037001
デプロイコマンドの実行後にノードを確認すると、以下の通りAutopilotノードが追加されていることが分かります。
NAME STATUS ROLES AGE VERSION
gk3-cluster-standard-nap-e2-standard--101c5267-btb6 Ready <none> 32m v1.34.1-gke.2037001 ← Autopilotノード
gke-cluster-standard-default-pool-ce8cf66f-fts9 Ready <none> 73m v1.34.1-gke.2037001 ← Standardノード
gke-cluster-standard-default-pool-ce8cf66f-klkb Ready <none> 73m v1.34.1-gke.2037001 ← Standardノード
デプロイ後のワークロードの状態は以下の通りです。最も右の列より、Autopilotノード上で実行されていることが分かります。
NAME READY STATUS RESTARTS AGE IP NODE
sample-http-server-9b5b5b757-k7zg8 1/1 Running 0 13s 10.84.2.8 gk3-cluster-standard-nap-e2-standard--101c5267-btb6
sample-http-server-9b5b5b757-k95tz 1/1 Running 0 14s 10.84.2.6 gk3-cluster-standard-nap-e2-standard--101c5267-btb6
sample-http-server-9b5b5b757-v7hpn 1/1 Running 0 14s 10.84.2.7 gk3-cluster-standard-nap-e2-standard--101c5267-btb6
参考までにですが、Autopilotノードはコンソールからは視認できないようになっています。
この挙動はAutopilotクラスタを利用している場合と同様です。
ComputeClass
解説の中でいきなり出てきたComputeClassについて簡単に触れたいと思います。
既にノードプールの概念について説明しましたが、ComputeClassは複数のノードプールを利用する優先度や条件及び、構成を定義して管理できるようになります。
例えば、ワークロードの特性に合わせてComputeClassを作成しておくことで、最適なノードを使うことができたり、優先して使いたいノードが確保できなくても代替ノードを使うことができるようになります。
今回のAutopilotノードの追加にあわせて、自身で定義するカスタムComputeClassでもAutopilotノードを利用することができるようになっています。
StandardクラスタのノードからAutopilotノードへワークロードを移行してみる
次に既にStandardクラスタを利用している状況でAutopilotノードへワークロードを移行できるか試してみたいと思います。（そりゃできるだろうけど）
事前準備
まずはAutopilotを利用しないワークロードをデプロイしておきます。
NAME READY STATUS NODE
sample-http-server-migration-57794964f7-44f4w 1/1 Running gke-cluster-standard-default-pool-ce8cf66f-klkb
sample-http-server-migration-57794964f7-h6p7k 1/1 Running gke-cluster-standard-default-pool-ce8cf66f-fts9
sample-http-server-migration-57794964f7-lrjnt 1/1 Running gke-cluster-standard-default-pool-ce8cf66f-fts9
上記で紹介した解説と同様にこれらワークロードを管理するマニフェストにて、ComputeClassを指定して反映します。
# 省略
spec:
nodeSelector:
cloud.google.com/compute-class: autopilot
# 省略
kubectl apply -f k8s-deployment.yaml
反映結果のワークロードの遷移は以下のようになりました。
Deploymentのルール（今回は1台ずつ移行）に従ってワークロードがAutopilotノードへ順次移行されていることが分かります。
NAME READY STATUS RESTARTS AGE IP NODE
sample-http-server-migration-57794964f7-44f4w 1/1 Running 0 8m30s 10.84.0.14 gke-cluster-standard-default-pool-ce8cf66f-klkb
sample-http-server-migration-57794964f7-h6p7k 1/1 Running 0 8m30s 10.84.1.10 gke-cluster-standard-default-pool-ce8cf66f-fts9
sample-http-server-migration-57794964f7-lrjnt 1/1 Running 0 8m30s 10.84.1.11 gke-cluster-standard-default-pool-ce8cf66f-fts9
# 一台目の移行
sample-http-server-migration-9cc7cff5-hg648 0/1 Pending 0 10s <none> <none>
sample-http-server-migration-9cc7cff5-hg648 0/1 ContainerCreating 0 2m49s <none> gk3-cluster-standard-nap-e2-standard--101c5267-btb6
sample-http-server-migration-9cc7cff5-hg648 1/1 Running 0 3m1s 10.84.2.2 gk3-cluster-standard-nap-e2-standard--101c5267-btb6
# 古い一台目の削除
sample-http-server-migration-57794964f7-h6p7k 1/1 Terminating 0 11m 10.84.1.10 gke-cluster-standard-default-pool-ce8cf66f-fts9
# 二台目の移行
sample-http-server-migration-9cc7cff5-slw2d 0/1 Pending 0 0s <none> <none>
sample-http-server-migration-9cc7cff5-slw2d 0/1 ContainerCreating 0 0s <none> gk3-cluster-standard-nap-e2-standard--101c5267-btb6
sample-http-server-migration-9cc7cff5-slw2d 1/1 Running 0 5s 10.84.2.4 gk3-cluster-standard-nap-e2-standard--101c5267-btb6
# 古い二台目の削除
sample-http-server-migration-57794964f7-lrjnt 1/1 Terminating 0 11m 10.84.1.11 gke-cluster-standard-default-pool-ce8cf66f-fts9
# 三台目の移行
sample-http-server-migration-9cc7cff5-f5ddv 0/1 Pending 0 0s <none> <none>
sample-http-server-migration-9cc7cff5-f5ddv 0/1 ContainerCreating 0 0s <none> gk3-cluster-standard-nap-e2-standard--101c5267-btb6
sample-http-server-migration-9cc7cff5-f5ddv 1/1 Running 0 4s 10.84.2.5 gk3-cluster-standard-nap-e2-standard--101c5267-btb6
# 古い三台目の削除
sample-http-server-migration-57794964f7-44f4w 1/1 Terminating 0 11m 10.84.0.14 gke-cluster-standard-default-pool-ce8cf66f-klkb
移行完了後のワークロードの状態は以下の通りです。全てのワークロードがAutopilotノード上に配置されています。
NAME READY STATUS RESTARTS AGE IP NODE
sample-http-server-migration-9cc7cff5-f5ddv 1/1 Running 0 4m23s 10.84.2.5 gk3-cluster-standard-nap-e2-standard--101c5267-btb6
sample-http-server-migration-9cc7cff5-hg648 1/1 Running 0 7m30s 10.84.2.2 gk3-cluster-standard-nap-e2-standard--101c5267-btb6
sample-http-server-migration-9cc7cff5-slw2d 1/1 Running 0 4m28s 10.84.2.4 gk3-cluster-standard-nap-e2-standard--101c5267-btb6
さいごに
今回はStandardクラスタでAutopilotノードを利用する方法を紹介しました。
利用方法としては簡単ですが、利用条件は現時点でリリースチャンネルをrapidとして設定している必要があるため、すぐに本番環境に適用することは難しいかもしれません。今後regularやstableといったリリースチャンネルにも追加されることを待ちましょう。
昨今、GKEクラスタを複数台利用するマルチクラスタ構成も主流だと思いますが、クラスタ間の連携を実現しようとするとやや複雑な構成が必要になるので、今回のような1台のクラスタ内で一部のユースケースを完結できる機能は便利だと思います。
また、特にAutopilot使いたいけど、既にStandardクラスタ使ってしまっていて移行がしんどいというユーザーの方は多いのではないでしょうか。そのような方は今回紹介した機能が活用できるので移行を検討してみてはいかがでしょうか。
今回の記事は以上になります。ありがとうございました。
Discussion