EKS マネージドノードグループからEKS Auto Modeへ移行する

Posted at 2025-10-08

はじめに

Amazon EKSは、Kubernetesクラスターの管理を簡素化するマネージドサービスですが、従来はノードグループの管理、オートスケーリング、パッチの適用など、多くの運用タスクが必要でした。EKS Auto Modeは、これらの運用負荷を軽減し、よりシンプルなKubernetes運用を実現します。

このデモでは、従来のEKSクラスター・マネージドノードグループでアプリケーションを構築し、その後EKS Auto Modeに移行する手順を実践します。（二つのクラスターを作成するのではなく、インプレース移行します。）

移行プロセスを通じて、Auto Modeの利点と移行時の考慮事項を理解できます。

EKS Auto Modeとは

EKS Auto Modeは、Kubernetesクラスターの運用を大幅に自動化する新機能です。従来のEKSと比較して、以下の運用タスクが自動化されます。簡単に表すと、以下のような図の通りになり、従来のコントロールプレーンだけでなく、ワーカーノードの管理までAWSに任せることができるようになりました。

従来のEKSの管理範囲：

EKS Auto Modeの管理範囲：

従来のEKSの課題

従来のEKSでは、以下のような運用タスクが必要でした：

ノードグループの管理: インスタンスタイプの選択、スケーリング設定
セキュリティパッチ: ノードのOSアップデート
リソース最適化: CPU/メモリ使用率の監視と調整
アドオン管理: EBS CSI Driver、VPC CNI、CoreDNSなどの管理
ネットワーク設定: VPCCNIの設定、IPアドレス管理

EKS Auto Modeの利点

EKS Auto Modeは、これらの課題を解決します：

自動化される機能:

コンピュートの自動管理: ワークロードに応じた最適なインスタンスの自動選択
自動スケーリング: リソース使用量に基づく自動的なスケールアップ/ダウン
自動アップグレード: Kubernetesバージョンとノードの自動更新
アドオンの自動管理: EBS CSI Driver、VPC CNI、CoreDNSなどの自動更新
ネットワークの最適化: VPCCNIの自動設定と最適化

これにより、運用負荷が大幅に軽減され、より一層アプリケーション開発に集中できるようになります。

システム構成

今回のデモで構築するシステムは、AWS上でマネージドサービスを活用したシンプルなアーキテクチャを採用しています。アプリケーションをEKSクラスター上で動作させ、ALB経由でインターネットからアクセス可能な構成になっています。

EKS Auto Modeを利用したシステム構成図:

システムの主要コンポーネント:

EKS: マネージドKubernetesクラスター
ALB: インターネットからのアクセスを提供するロードバランサー
Target Group Binding: ALBとKubernetes Serviceを連携するコンポーネント
ECR: Dockerイメージの保存するレポジトリ
Karpenter（マネージド）: AWSがOSSとして開発している、Kubernetesクラスターのノード数とサイズを自動で調整するツール

プロジェクト構成

インフラストラクチャとアプリケーションが分離された構成になっています。infrastructure/フォルダにはAWSリソース（VPC、ALB、ECR等）とEKSクラスターの定義が含まれており、kubernetes-resource/フォルダにはStreamlitアプリケーションとKubernetesマニフェストが配置されています。

mig-to-automode/
├── infrastructure/             # インフラストラクチャ
│   ├── cloudformation/         # AWSリソース定義
│   └── eksctl/                 # EKSクラスター定義
│
├── application/                # アプリケーション
│   ├── app.py
│   ├── Dockerfile
│   └── requirements.txt
│
└── kubernetes-manifests/       # Kubernetesマニフェスト
    ├── manifest.yml
    ├── target-group-binding.yml
    └── target-group-binding-automode.yml

構築手順

システムのデプロイは段階的に進めていきます。まずインフラストラクチャを構築し、従来のEKSクラスターでアプリケーションをデプロイします。

Phase 1：従来のEKSクラスター構築

1. インフラストラクチャのデプロイ

AWSコンソールからCloudFormationを使用してインフラストラクチャをデプロイします。CloudFormationから、infrastructure/cloudformation/infrastructure.yamlファイルをアップロードします。このテンプレートには、VPC、サブネット、ALB、ECRなどの必要なAWSリソースが定義されています。

このデモではEC2での作業を想定しており、必要なツール（kubectl、eksctl、helm、docker）はUserDataで事前にインストール済みとします。

2. 従来のEKSクラスターの作成

まず、従来のEKSクラスター・マネージドノードグループを作成します。

# 従来のEKSクラスター作成
eksctl create cluster -f infrastructure/eksctl/create-cluster-managed-node-group.yaml

Target Group Bindingを使用する場合、Ingressリソースと異なりセキュリティグループが自動作成されません。ALBからノードへのアクセスを許可するため、クラスターのセキュリティグループに手動でインバウンドルールを追加する必要があります。

従来のEKS定義（抜粋）

# 従来のEKSクラスター設定
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig

metadata:
  name: test-eks-cluster
  region: us-west-2
  version: "1.33"

# 従来のノードグループ設定
managedNodeGroups:
  - name: test-ng-amazon-linux-2023
    instanceType: r5.xlarge
    amiFamily: AmazonLinux2023
    minSize: 2
    desiredCapacity: 2
    maxSize: 5
    volumeSize: 30
    volumeType: gp3
    volumeEncrypted: true
    privateNetworking: true

3. AWS Load Balancer Controllerのインストール

Target Group Bindingを使用するため、Load Balancer Controllerをインストールします。

# IAM OIDCプロバイダーの関連付け
eksctl utils associate-iam-oidc-provider --region=us-west-2 --cluster=test-eks-cluster --approve

# IAMロール作成
eksctl create iamserviceaccount \
  --cluster=test-eks-cluster \
  --namespace=kube-system \
  --name=aws-load-balancer-controller \
  --attach-policy-arn=arn:aws:iam::aws:policy/ElasticLoadBalancingFullAccess \
  --override-existing-serviceaccounts \
  --region us-west-2 \
  --approve
  
# Load Balancer Controllerをインストール
helm repo add eks https://aws.github.io/eks-charts

helm install aws-load-balancer-controller eks/aws-load-balancer-controller \
  -n kube-system \
  --set clusterName=test-eks-cluster \
  --set serviceAccount.create=false \
  --set serviceAccount.name=aws-load-balancer-controller

4. アプリケーションのデプロイ

DockerイメージをビルドしてECRにプッシュし、Kubernetesマニフェストをデプロイします。

# ECRにDockerイメージをプッシュ
aws ecr get-login-password --region us-west-2 | docker login --username AWS --password-stdin <ACCOUNT-ID>.dkr.ecr.us-west-2.amazonaws.com

# Dockerイメージのビルドとプッシュ
docker build -t test-ecr application/
docker tag test-ecr:latest <ACCOUNT-ID>.dkr.ecr.us-west-2.amazonaws.com/test-ecr:latest
docker push <ACCOUNT-ID>.dkr.ecr.us-west-2.amazonaws.com/test-ecr:latest

# Kubernetesマニフェストをデプロイ
kubectl apply -f kubernetes-manifests/manifest.yml

5. Target Group Bindingの設定

CloudFormationで作成したALBのTarget GroupとKubernetes Serviceを連携させます。

# Target Group Bindingを適用
kubectl apply -f kubernetes-manifests/target-group-binding.yml

Target Group Binding設定（従来のEKS用）

# Target Group Binding設定（従来のEKS用）
apiVersion: elbv2.k8s.aws/v1beta1
kind: TargetGroupBinding
metadata:
  name: streamlit-app-tgb
  namespace: demo-app
spec:
  serviceRef:
    name: streamlit-app-service
    port: 80
  targetGroupARN: arn:aws:elasticloadbalancing:us-west-2:ACCOUNT:targetgroup/test-tg/ID

6. アプリケーションの動作確認

従来のEKSクラスターでアプリケーションが正常に動作していることを確認します。

ALB DNS名を取得してブラウザでアクセスして、確認します。

Phase 2：EKS Auto Modeへの移行

従来のEKSクラスターでアプリケーションが正常に動作することを確認した後、EKS Auto Modeに移行します。

移行方式について:
新しいAuto Modeクラスターを作成し、Blue/Green方式でALBを切り替え、トラフィックを切り替える方法もありますが、今回はインプレース方式で移行を行います。既存のクラスターでAuto Modeを有効化し、従来のノードグループをドレインして移行します。

Auto Mode対応のクラスター設定ファイル（参照用）

実際のAuto Mode有効化はAWSコンソールから行いますが、新規作成の場合は、以下のようなeksctl設定ファイルを利用します。

EKS Auto Mode設定（eksctl）

# EKS Auto Mode クラスター設定
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig

metadata:
  name: test-eks-cluster-auto
  region: us-west-2
  version: "1.33"

iam:
  withOIDC: true
  # required for karpenter

computeConfig:
  enabled: true  # Auto Modeを有効化

1. EKS Auto Modeの有効化

AWSコンソールから既存のEKSクラスターでAuto Modeを有効化します。

IAMロールには、推奨ロールを作成をクリックして、流れに沿って新しいロールを作成して、それを選択してください。

NodePoolの選択:
Auto Mode有効化時に以下のオプションが表示されます。カスタムが必要な場合ぞ除き、両方を選択します：

general-purpose: ✅ アプリケーションワークロード用
system: ✅ システムコンポーネント用、CoreDNS、kube-proxyなど

有効化前にいくつかの前提があります。

IAMロールへの権限追加:
Auto Mode有効化前に、以下の権限を追加する必要があります。

クラスターロール：

AmazonEKSComputePolicy
AmazonEKSBlockStoragePolicy
AmazonEKSLoadBalancingPolicy
AmazonEKSNetworkingPolicy
AmazonEKSClusterPolicy
クラスターロールの信頼関係に sts:TagSession アクションの追加

※デモ時、AmazonEKSClusterPolicyと、sts:TagSession アクションがもともと追加されていた。

ノードロール（Auto Mode専用の新規作成推奨）：

AmazonEKSWorkerNodeMinimalPolicy
AmazonEC2ContainerRegistryPullOnly

既存のマネージドノードグループ用ロールは使用せず、Auto Mode専用の新しいロールを作成してください。

既存のノードグループ用IAMロールをAuto Mode用として指定すると以下のエラーが発生します：

AccessEntry for NodeRoleArn arn:aws:iam::ACCOUNT:role/eksctl-test-eks-cluster-nodegroup--NodeInstanceRole-xxx should either not exist or have type EC2

参考資料:

EKSアドオンの最低バージョン確認:
Auto Mode有効化前に、以下のアドオンが最低バージョンを満たしていることを確認します。EKSコンソールなどから確認できます。

Amazon VPC CNI: v1.19.0-eksbuild.1
Kube-proxy: v1.26.15-eksbuild.19, v1.27.16-eksbuild.14, v1.28.15-eksbuild.4, v1.29.10-eksbuild.3, v1.30.6-eksbuild.3, v1.31.2-eksbuild.3
Amazon EBS CSIドライバー: v1.37.0-eksbuild.1
CSIスナップショットコントローラー: v8.1.0-eksbuild.2
EKS Pod Identityエージェント: v1.3.4-eksbuild.1

参考資料:

既存のクラスターで EKS Auto Mode を有効にする

2. 従来のノードグループのドレイン

Auto Modeが有効化されたら、従来のノードグループをドレインします。

ドレインを開始する前に、以下についても確認します。

移行前の確認事項:

EKS Auto Modeが有効になっていること
EKS Auto ModeのNodePoolが作成済みであること
セルフマネージドKarpenterがインストールされていないこと

Auto Modeを有効化することで、Auto ModeのNodePoolが作成されます。

# NodePoolの確認
kubectl get nodepool -A

以下のような出力が表示されます：

NAME              NODECLASS   NODES   READY   AGE
general-purpose   default     0       True    12m
system            default     0       True    12m

参考資料:

EKS 自動モード

PodDisruptionBudget (PDB):
PodDisruptionBudgetを設定することで、ノードドレイン時のサービス継続を保つことができます。PDBは、ドレイン中に同時に停止できるPodの数を制限し、サービスの可用性を保護します。

例えば以下のような設定を加えることで、ドレイン中でも最低1つのPodが常に利用可能な状態を維持できます。なお、manifestにこの設定は含まれています。

# PDBの例
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: streamlit-app-pdb
  namespace: demo-app
spec:
  minAvailable: 1
  selector:
    matchLabels:
      app: streamlit-app

ドレイン手順:

# ノードの一覧確認
kubectl get nodes

# 従来のノードグループのノードをドレイン
kubectl drain <node-name> --ignore-daemonsets --delete-emptydir-data

ドレイン時の注意事項:
PDB により、streamlit-app や metrics-server が一時的に退去できず
Cannot evict pod as it would violate the pod's disruption budget.
という警告が表示されるのは正常です。
kubectl drain は内部でリトライし続け、最終的に PDB を満たしながら順次 Pod を退去させます。
出力の最後に
node/ip-10-0-3-241.us-west-2.compute.internal drained
と表示されていれば、正常にノードから全ての Pod が退去完了しています。

3. Auto ModeでのPodの確認

Auto Modeによって新しいノードが自動的にプロビジョニングされ、アプリケーションが正常に動作することを確認します。

ドレイン完了後、以下のような結果が表示されます：

# ノードの状態確認
kubectl get nodes

NAME                                       STATUS                     ROLES    AGE     VERSION
i-0b4623750202178a4                        Ready                      <none>   2m27s   v1.33.4-eks-e386d34
i-0d7da449949d82b55                        Ready                      <none>   2m24s   v1.33.4-eks-e386d34
ip-10-0-3-241.us-west-2.compute.internal   Ready,SchedulingDisabled   <none>   69m     v1.33.5-eks-113cf36
ip-10-0-4-77.us-west-2.compute.internal    Ready,SchedulingDisabled   <none>   69m     v1.33.5-eks-113cf36

# Podの状態確認
kubectl get pods -A

NAMESPACE     NAME                                            READY   STATUS             RESTARTS      AGE
demo-app      streamlit-app-dddc8ff5c-7bw8n                   1/1     Running            0             3m34s
demo-app      streamlit-app-dddc8ff5c-sdkgb                   1/1     Running            0             5m33s
kube-system   aws-load-balancer-controller-578499dc8b-jf5h8   0/1     CrashLoopBackOff   5 (77s ago)   5m33s
kube-system   aws-load-balancer-controller-578499dc8b-qfkfs   0/1     CrashLoopBackOff   5 (61s ago)   5m33s
kube-system   aws-node-4hsmb                                  2/2     Running            0             72m
kube-system   aws-node-9qqx9                                  2/2     Running            0             72m
kube-system   coredns-7bf648ff5d-4nwqs                        1/1     Running            0             4m52s
kube-system   coredns-7bf648ff5d-gfvss                        1/1     Running            0             5m33s
kube-system   kube-proxy-cc58c                                1/1     Running            0             72m
kube-system   kube-proxy-nf2cm                                1/1     Running            0             72m
kube-system   metrics-server-7fb96f5556-6rm7q                 1/1     Running            0             5m33s
kube-system   metrics-server-7fb96f5556-hkq5c                 1/1     Running            0             4m28s

確認ポイント:

新しいAuto Modeノード: i-0b4623750202178a4、i-0d7da449949d82b55 が作成された
従来ノード: SchedulingDisabled 状態で新しいPodのスケジュールが無効化
アプリケーションPod: streamlit-app が新しいノードで正常動作
Load Balancer Controller: CrashLoopBackOff 状態（次のステップでアンインストール）

4. Auto Mode対応のTarget Group Bindingの作成

Auto Modeへの移行後、Loadbalancer ControllerはAuto Modeで管理されるため、アンインストールします。（引き続き自分でインストールしたものも使えます。）

# AWS Load Balancer Controllerのアンインストール
helm uninstall aws-load-balancer-controller -n kube-system

# IAM ServiceAccountの削除
eksctl delete iamserviceaccount \
  --cluster=test-eks-cluster \
  --namespace=kube-system \
  --name=aws-load-balancer-controller \
  --region us-west-2

続いて、Auto Mode対応のTarget Group Bindingを作成します。

Target Group Binding設定（Auto Mode対応）

# Target Group Binding設定（Auto Mode用）
apiVersion: eks.amazonaws.com/v1
kind: TargetGroupBinding
metadata:
  name: streamlit-app-tgb
  namespace: demo-app
spec:
  targetType: ip  # Auto Modeでは必須
  serviceRef:
    name: streamlit-app-service
    port: 80
  targetGroupARN: arn:aws:elasticloadbalancing:us-west-2:ACCOUNT:targetgroup/test-tg/ID

Auto Modeでの変更点:

apiVersion: eks.amazonaws.com/v1 を使用
spec.targetType: ip の指定が必須
spec.networking.ingress.from: サポート対象外
Target Groupにタグ eks:eks-cluster-name が必要

Target Groupタグの設定:
AWSコンソールから、対象のTarget Groupを選択し、Tagsタブで以下のタグを追加します。

Key: eks:eks-cluster-name
Value: test-eks-cluster

# Auto Mode用のTarget Group Bindingを適用
kubectl apply -f kubernetes-manifests/target-group-binding-automode.yml

セルフマネージドコンポーネント・ネットワーク系アドオンの削除について

また、以下のコンポーネント・アドオンを削除します。Auto Modeにはこれらの機能が標準で備わっているため、これらは不要になります：

VPC CNI (aws-node): Auto Modeが自動管理するため
CoreDNS: Auto Modeが自動管理するため
kube-proxy: Auto Modeが自動管理するため
AWS Load Balancer Controller: 上記で削除済み
セルフマネージドKarpenter:今回は利用なし
EBS CSI Driver:今回は利用なし
EKS Pod Identityエージェント:今回は利用なし

# 現在のアドオン確認
aws eks list-addons --cluster-name test-eks-cluster --region us-west-2

# VPC CNI アドオンの削除
aws eks delete-addon --cluster-name test-eks-cluster --addon-name vpc-cni --region us-west-2

# CoreDNS アドオンの削除
aws eks delete-addon --cluster-name test-eks-cluster --addon-name coredns --region us-west-2

# kube-proxy アドオンの削除
aws eks delete-addon --cluster-name test-eks-cluster --addon-name kube-proxy --region us-west-2

アドオン削除後の状態:
ネットワーク系アドオンの削除により、管理対象のPodが大幅に削減され、リソース消費も軽減されます：

# 最終的なPod状態確認
kubectl get pods -A

NAMESPACE     NAME                              READY   STATUS    RESTARTS   AGE
demo-app      streamlit-app-dddc8ff5c-7bw8n     1/1     Running   0          30h
demo-app      streamlit-app-dddc8ff5c-sdkgb     1/1     Running   0          30h
kube-system   metrics-server-7fb96f5556-6rm7q   1/1     Running   0          30h
kube-system   metrics-server-7fb96f5556-hkq5c   1/1     Running   0          30h

参考資料:

5. アプリケーションの動作確認

デプロイが完了すると、StreamlitアプリケーションがALB経由でアクセス可能になります。

ALB DNS名を取得してブラウザでアクセスして、確認します。

従来のノードグループの削除

Auto Modeでの動作が確認できたら、従来のノードグループを削除します。

# ノードグループの削除
eksctl delete nodegroup --cluster=test-eks-cluster --name=test-ng-amazon-linux-2023 --region=us-west-2

移行時の注意事項（その他）

EKS Auto Modeへの移行を実行する前に、上記では記載していない、その他の注意事項いついても確認してください。

Kubernetesバージョンの互換性: 1.29以上が必要です
使用量ベースの課金: EC2の使用量に対して1割程度発生します。そのため大規模なクラスターでは注意が必要です
インスタンスタイプの自動選択: ワークロードに応じて最適なインスタンスが選択されます
OSレベル設定の制限: ノードがマネージドで管理されており、OSレベルの設定変更はできません
カスタムAMIの使用不可: 独自のAMIやユーザーデータスクリプトの使用はサポートされていません
ノードへのSSHアクセス制限: ノードはマネージドで管理されており、直接のSSHアクセスは推奨されません

まとめ

従来のEKSクラスターからEKS Auto Modeへの移行を実践しました。

EKS Auto Modeは、Kubernetesクラスターの運用を大幅に簡素化する革新的な機能です。このデモの移行手順が、同様の移行を検討する際の参考になれば幸いです。

ちなみに

Auto Mode利用時、VPCをまたいだALBの接続に関しては以下制約があります。このような要件はなかなかないと思いますが、備忘として記載します。

Auto Modeで管理されるLoad Balancer Controllerでは、Target Group Bindingによる、他VPCのALBとの接続はできない。（セルフマネージドのLBコントローラーであれば引き続き可能。）
Ingressも上記と同様

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up