EKS Auto Mode で運用負荷を最小化したKubernetesクラスターを構築する

はじめに

Kubernetes を本番運用する上で、ノードのスケーリングやアップグレードは避けて通れない運用負荷だ。EKS では Karpenter や Cluster Autoscaler で自動化してきたが、それでもノードグループの設計やライフサイクル管理は利用者の責務だった。

2024年末に登場した EKS Auto Mode は、このノード管理を EKS 側に完全に委譲する仕組みだ。この記事では、eksctl を使って Auto Mode を有効にした EKS クラスターを構築する手順と、従来方式との設計思想の違いを整理する。

EKS Auto Mode とは

EKS Auto Mode は、コンピュート（EC2 インスタンス）、ネットワーキング、ストレージといったクラスターのインフラ管理を EKS が自動で行う機能だ。従来の EKS では以下のような作業が必要だった。

ノードグループの設計 — インスタンスタイプ、最小/最大台数の決定
スケーリング設定 — Karpenter や Cluster Autoscaler の導入・チューニング
ノードのアップグレード — AMI 更新やローリングアップデートの実施
セキュリティパッチ — OS レベルのパッチ適用

Auto Mode ではこれらがすべて EKS 側で管理される。利用者はワークロード（Pod）をデプロイするだけで、必要なノードが自動的にプロビジョニングされる。

従来方式との比較

項目	マネージドノードグループ	Auto Mode
ノード管理	利用者	EKS
スケーリング	Karpenter / CA が必要	自動
インスタンスタイプ選択	利用者が指定	ワークロードに応じて自動選択
OS パッチ適用	利用者	EKS
料金モデル	EC2 料金 + EKS 料金	EKS Auto Mode 料金

つまり Auto Mode は「Kubernetes を使いたいが、インフラの運用は最小限にしたい」というユースケースに最適だ。

構築手順

前提条件

AWS CLI が設定済みであること
eksctl がインストールされていること（brew install eksctl で導入可能）
適切な IAM 権限があること

クラスター作成

Auto Mode での EKS クラスター作成は驚くほどシンプルだ。--enable-auto-mode フラグを付けるだけでよい。

eksctl create cluster \
  --name sandbox \
  --region ap-northeast-1 \
  --version 1.32 \
  --enable-auto-mode

このコマンド一発で以下が自動作成される。

VPC — パブリック/プライベートサブネットを持つ新規 VPC
EKS クラスター — Kubernetes 1.32、Auto Mode 有効
IAM ロール — クラスターおよびノード用のロール
セキュリティグループ — クラスター通信に必要なルール

作成には15〜20分ほどかかる。進捗は eksctl のログでリアルタイムに確認できる。

作成されるリソースの詳細

コマンド一発とはいえ、裏では CloudFormation を通じて多数のリソースが作成される。中身を理解しておくことで、トラブルシュート時や本番環境への適用時に役立つ。

VPC とネットワーク

eksctl は 192.168.0.0/16 の CIDR を持つ VPC を新規作成し、3つの AZ にパブリック・プライベートサブネットを1つずつ配置する。

サブネット	AZ	CIDR	パブリック IP 自動割当
Public 1d	ap-northeast-1d	192.168.0.0/19	あり
Public 1c	ap-northeast-1c	192.168.32.0/19	あり
Public 1a	ap-northeast-1a	192.168.64.0/19	あり
Private 1d	ap-northeast-1d	192.168.96.0/19	なし
Private 1c	ap-northeast-1c	192.168.128.0/19	なし
Private 1a	ap-northeast-1a	192.168.160.0/19	なし

パブリックサブネットはインターネットゲートウェイ経由で外部と通信し、プライベートサブネットは NAT ゲートウェイ（1台、EIP 付き）を経由する。ノードはプライベートサブネットに配置されるため、直接インターネットに晒されることはない。

IAM ロール

Auto Mode では2つの IAM ロールが作成される。

クラスターサービスロール（ServiceRole） — EKS コントロールプレーンが使用するロールで、eks.amazonaws.com が AssumeRole する。従来方式と比べて Auto Mode 固有のポリシーが追加されている点が特徴的だ。

AmazonEKSClusterPolicy — クラスター管理の基本権限
AmazonEKSComputePolicy — Auto Mode のコンピュート管理
AmazonEKSNetworkingPolicy — Auto Mode のネットワーク管理
AmazonEKSBlockStoragePolicy — Auto Mode のストレージ管理
AmazonEKSLoadBalancingPolicy — ロードバランサー管理
AmazonEKSVPCResourceController — VPC リソース制御

従来方式では AmazonEKSClusterPolicy と AmazonEKSVPCResourceController の2つだけだが、Auto Mode ではコンピュート・ネットワーク・ストレージの管理権限が追加される。これが「EKS がインフラを自動管理する」仕組みの正体だ。

Auto Mode ノードロール（AutoModeNodeRole） — ノード（EC2 インスタンス）に割り当てられるロールで、ec2.amazonaws.com が AssumeRole する。

AmazonEKSWorkerNodeMinimalPolicy — ノード動作に必要な最小権限
AmazonEC2ContainerRegistryPullOnly — ECR からのイメージ Pull 権限

ノード側のポリシーは最小権限に絞られている。従来方式で必要だった AmazonEKSWorkerNodePolicy や AmazonEKS_CNI_Policy よりもシンプルだ。

セキュリティグループ

2つのセキュリティグループが作成され、3つのイングレスルールで通信を制御する。

ControlPlaneSecurityGroup — コントロールプレーンとノード間の通信用。イングレスルールなし、アウトバウンドは全許可。

ClusterSharedNodeSecurityGroup — ノード間の通信用。自身のセキュリティグループとコントロールプレーンからの全トラフィックを許可し、ノード間通信を制限なく可能にしている。

この構成により、コントロールプレーン↔ノード、ノード↔ノードの通信が確保される。

従来方式との作成コマンドの違い

従来のマネージドノードグループ方式では、以下のようにノード構成を明示的に指定する必要があった。

# 従来方式（マネージドノードグループ）
eksctl create cluster \
  --name sandbox \
  --region ap-northeast-1 \
  --version 1.32 \
  --nodegroup-name sandbox-nodes \
  --node-type t3.medium \
  --nodes 2 \
  --nodes-min 1 \
  --nodes-max 3 \
  --managed

Auto Mode ではノードグループの指定が一切不要だ。インスタンスタイプや台数はワークロードの要求に応じて EKS が判断する。

動作確認

クラスターの状態確認

クラスター作成完了後、まずコントロールプレーンとノードの状態を確認する。

kubectl cluster-info

Kubernetes control plane is running at https://xxxxx.gr7.ap-northeast-1.eks.amazonaws.com

kubectl get nodes

NAME                  STATUS   ROLES    AGE   VERSION
i-0a3b6967393de6f9d   Ready    <none>   18s   v1.32.11-eks-ac2d5a0
i-0bc928a12acfe91a2   Ready    <none>   18s   v1.32.11-eks-ac2d5a0

クラスター作成直後の時点で、Auto Mode が2台のノードを自動的にプロビジョニングしている。インスタンスタイプやノード数はこちらで一切指定していない点がポイントだ。

サンプルワークロードのデプロイ

Auto Mode の真価はワークロードに応じた動的なノードプロビジョニングにある。nginx を3レプリカでデプロイして動作を確認する。

kubectl create deployment nginx --image=nginx:latest --replicas=3

デプロイ直後は Pod が Pending 状態になるが、約30秒後に再確認すると全 Pod が Running になっている。

kubectl get pods -o wide

NAME                     READY   STATUS    RESTARTS   AGE   IP                NODE
nginx-54c98b4f84-7sc9x   1/1     Running   0          54s   192.168.163.242   i-04012a4d55813e76a
nginx-54c98b4f84-8kp22   1/1     Running   0          54s   192.168.163.240   i-04012a4d55813e76a
nginx-54c98b4f84-mc9lw   1/1     Running   0          54s   192.168.163.241   i-04012a4d55813e76a

ノード一覧を再確認すると、3台目のノード（i-04012a4d55813e76a）が自動で追加されていることがわかる。

kubectl get nodes

NAME                  STATUS   ROLES    AGE   VERSION
i-04012a4d55813e76a   Ready    <none>   35s   v1.32.11-eks-ac2d5a0
i-0a3b6967393de6f9d   Ready    <none>   81s   v1.32.11-eks-ac2d5a0
i-0bc928a12acfe91a2   Ready    <none>   81s   v1.32.11-eks-ac2d5a0

ワークロードの要求に応じて Auto Mode がノードを自動追加する動作を確認できた。Karpenter や Cluster Autoscaler の設定は一切不要だ。

ワークロード削除とスケールダウン

スケールアップだけでなく、スケールダウンも確認しておこう。先ほどデプロイした nginx を削除する。

kubectl delete deployment nginx

削除後にノード一覧を確認すると、ワークロード用に追加された3台目のノードが自動的に除去され、2台に戻っていた。

kubectl get nodes

NAME                  STATUS   ROLES    AGE   VERSION
i-0bc928a12acfe91a2   Ready    <none>   79m   v1.32.11-eks-ac2d5a0
i-04012a4d55813e76a   Ready    <none>   78m   v1.32.11-eks-ac2d5a0

スケールアップ・スケールダウンの両方が Auto Mode によって自動管理されることを確認できた。従来方式では Karpenter の consolidationPolicy や Cluster Autoscaler の scale-down-unneeded-time といったパラメータを調整する必要があったが、Auto Mode ではこれらの設定も不要だ。

Auto Mode を選ぶべきケース

Auto Mode は万能ではない。以下の基準で判断するとよい。

Auto Mode が適しているケース:

開発・検証用クラスターで、インフラ管理に時間をかけたくない
チームに Kubernetes のインフラ運用経験が少ない
ワークロードが標準的で、特殊なインスタンスタイプを必要としない

従来方式が適しているケース:

GPU インスタンスなど、特定のハードウェアが必要
コスト最適化のためにスポットインスタンスを細かく制御したい
ノードの OS レベルでカスタマイズが必要

まとめ

--enable-auto-mode の一行でインフラ管理が不要に — ノードグループの設計・スケーリング設定・パッチ適用がすべて EKS 側に委譲されるため、ワークロード開発に集中できる。
eksctl との組み合わせで構築の敷居が下がった — VPC やIAM ロールも含めてコマンド一発で環境が揃うため、検証環境の立ち上げが格段に速くなる。
「どこまで自分で管理するか」の設計判断が重要 — Auto Mode は運用を楽にする反面、細かい制御はできない。ユースケースに応じて従来方式と使い分ける視点が必要だ。