Amazon EKS Auto Mode を利用する際に気をつけるべきこと

こんにちは。クロスイノベーション本部クラウドイノベーションセンターの柴田です。

re:Invent 2024 で Amazon EKS Auto Mode の一般提供が発表されました。この記事では Auto Mode を利用する際に気をつけるべきことをご紹介します。

ℹ️ この記事の内容は 2025 年 2 月 22 日時点のものです。最新の情報は Amazon EKS の公式ドキュメント をご参照ください。

Amazon EKS Auto Mode とは

Amazon EKS Auto Mode では以下のアドオンに相当する機能がマネージドサービスとして提供されます。

• Amazon EBS CSI driver
• Amazon VPC CNI plugin
• AWS Load Balancer Controller
• CoreDNS
• Karpenter
• kube-proxy
• EKS Pod Identity Agent

これによりクラスタ管理者はこれらのアドオンの保守・運用から開放されます。

ℹ️ この記事では各アドオンの解説はしません。各アドオンの詳細はそれぞれの公式ドキュメントをご参照ください。

Amazon EBS CSI driver

OSS 版との主な違い

Auto Mode は Amazon EBS CSI driver と以下の違いがあります。¹

The block storage capability of EKS Auto Mode is different from the EBS CSI Driver.

• Static Provisioning
  • If you want to use externally-created EBS volumes with EKS Auto Mode, you need to manually add an AWS tag with the key eks:eks-cluster-name and the value of the cluster name.
• Node Startup Taint
  • You cannot use the node startup taint feature to prevent pod scheduling before storage capability readiness
• Custom Tags on Dynamically Provisioned Volumes
  • You cannot use the extra-tag CLI flag to configure custom tags on dynamically provisioned EBS volumes
  • You can use StorageClass tagging to add custom tags. EKS Auto Mode will add tags to the associated AWS resources. You will need to update the Cluster IAM Role for custom tags. For more information, see Custom AWS tags for EKS Auto resources.
• EBS Detailed Performance Metrics
  • You cannot access Prometheus metrics for EBS detailed performance

OSS 版と併用できる

Auto Mode と Amazon EBS CSI driver は併用できます。

OSS 版からリソースを移行できない

既存の PersistentVolume の管理を Amazon EBS CSI driver から Auto Mode へ移行できません。

Auto Mode のノード以外では利用できない

Auto Mode が管理する PersistentVolume を利用するためにはノードで Auto Mode の CSI driver の node plugin が動いている必要があります。そのため該当する PersistentVolume を利用する Pod は Auto Mode のノードで実行する必要があります。

同様に Amazon EBS CSI driver が管理する PersistentVolume を利用するためにはノードで Amazon EBS CSI driver の node plugin が動いている必要があります。Amazon EBS CSI driver の node plugin の DaemonSet は Auto Mode のノードでは実行されません。そのため該当の PersistentVolume を利用する Pod は Auto Mode 以外のノードで実行する必要があります。

Amazon VPC CNI plugin

OSS 版との主な違い

Auto Mode は Amazon VPC CNI plugin と以下の違いがあります。²

EKS Auto Mode does not support:

• Security Groups per Pod (SGPP).
• Custom Networking. The IP Addresses of Pods and Nodes must be from the same CIDR Block.
• Warm IP, warm prefix, and warm ENI configurations.
• Minimum IP targets configuration.
• Enabling or disabling prefix delegation.
• Other configurations supported by the open-source AWS CNI.
• Network Policy configurations such as conntrack timer customization (default is 300s).
• Exporting network event logs to CloudWatch.

AWS Load Balancer Controller

OSS 版との主な違い

設定項目が異なる

以下のリソースは AWS Load Balancer Controller と設定項目（フィールドや annotation）が異なります。

• Service
• Ingress
• IngressClassParam
• TargetGroupBinding

詳細は以下のドキュメントをご参照ください。

• Create an IngressClass to configure an Application Load Balancer - Amazon EKS
• Use Service Annotations to configure Network Load Balancers - Amazon EKS

OSS 版と併用できる

Auto Mode と AWS Load Balancer Controller は併用できます。

OSS 版からリソースを移行できない

既存の Service, Ingress の管理を AWS Load Balancer Controller から Auto Mode へ移行できません。

.spec.loadBalancerClass のデフォルト値が eks.amazonaws.com/nlb になる

Service の .spec.loadBalancerClass が未指定の場合、 Auto Mode は mutating webhook によってこの値を eks.amazonaws.com/nlb に設定します。これには以下の影響があります。

• AWS Load Balancer Controller にも 類似の mutating webhook があります。両者を有効にしている場合、正常に機能するのは片方のみです。
• .spec.loadBalancerClass を未指定のままにできないため、新規に CLB を作成できません。

補足：Service, Ingress がどの controller によって処理されるか

Service

• .spec.loadBalancerClass の値が eks.amazonaws.com/nlb の場合、 Auto Mode によって NLB が作られます。
• 以下のいずれかの場合、AWS Load Balancer Controller によって NLB が作られます。
  • .spec.loadBalancerClass の値が service.k8s.aws/nlb の場合。
  • service.beta.kubernetes.io/aws-load-balancer-type annotation の値が nlb-ip または external の場合。
• .spec.loadBalancerClass が未指定の場合、レガシークラウドプロバイダーによって CLB が作られます。³

※前提として .spec.type の値が LoadBalancer であるとします。

Ingress

• .spec.ingressClassName に指定した IngressClass の .spec.controller の値が eks.amazonaws.com/alb の場合、Auto Mode によって ALB が作られます。
• .spec.ingressClassName に指定した IngressClass の .spec.controller の値が ingress.k8s.aws/alb の場合、 AWS Load Balancer Controller によって ALB が作られます。

Karpenter

OSS 版との主な違い

設定項目が異なる

以下のリソースは AWS Load Balancer Controller と設定可能な項目が異なります。

• NodeClass
• NodePool

詳細は以下のドキュメントをご参照ください。

• Create a Node Class for Amazon EKS - Amazon EKS
• Create a Node Pool for EKS Auto Mode - Amazon EKS

具体的な設定項目は kubectl explain コマンドでも確認できます。

ノードの AMI は AWS によって管理される

Auto Mode では NodeClass の .spec.amiSelectorTerms （ノードの AMI に関するフィールド）を設定できません。Auto Mode のノードの AMI は AWS によって管理されます。

Auto Mode のノードの AMI には以下の特徴があります。

• Bottlerocket OS を採用。
• SSH や Session Manager によるノードへのログインは不可。
  • ただし kubectl debug node コマンドの実行は可能。

AWS が新しい AMI をリリースすると Karpenter がそれを検出して、 PodDisruptionBudget や NodeDirsuptionBudget を考慮しつつ、自動的に各ノードを新しいものに置換します。

トラブルシューティングの際は node monitoring agent を使ってノードのログを収集できます。詳しい方法は Retrieve node logs for a managed node using kubectl and S3 をご参照ください。

ノードは起動から最長 21 日経過すると終了する

Auto Mode では NodePool の

• spec.template.spec.expireAfter
• spec.template.spec.terminationGracePeriod

の合計は 504h 以下でなければなりません。つまり各ノードは起動から最長 21 日経過すると自動的に終了します。

Pod からノードのインスタンスメタデータやインスタンスプロファイルを利用できない

Auto Mode では NodeClass の spec.metadataOptions （ノードの MetadataOptions に関するフィールド）を設定できません。

Auto Mode のノードの MetadataOptions は以下のようになります。

"MetadataOptions": {
  "State": "applied",
  "HttpTokens": "required",
  "HttpPutResponseHopLimit": 1,
  "HttpEndpoint": "enabled",
  "HttpProtocolIpv6": "disabled",
  "InstanceMetadataTags": "disabled"
}

HttpPutResponseHopLimit が 1 なので Pod からノードのインスタンスメタデータやインスタンスプロファイルを利用できません。Pod に IAM role を割り当てる必要がある場合は代わりに以下のいずれかを利用する必要があります。

• EKS Pod Identity
• IAM roles for service accounts

その他

他にも Auto Mode は Karpenter と以下の違いがあります。⁴

• EKS limits the maximum number of pods on a node to 110. This limit is applied after the existing max pods calculation. For more information, see Choose an optimal Amazon EC2 node instance type.

• EKS Auto Mode automatically formats and configures NVMe local storage on supported instance types. For nodes with multiple NVMe drives, EKS sets up a RAID 0 array. This automation eliminates the need for manual formatting and RAID configuration of local NVMe storage in EKS clusters.

• Amazon EKS Auto Mode does not support AWS Fault Injection Service. For more information, see Managing Fault Injection Service experiments in the AWS Resilience Hub User Guide.
• You do not need to install the Neuron Device Plugin on EKS Auto Mode nodes.
  • If you have other types of nodes in your cluster, you need to configure the Neuron Device plugin to not run on auto mode nodes. For more information, see Control if a workload is deployed on EKS Auto Mode nodes.

他のコンピュートリソースと併用できる

Auto Mode は他のコンピュートリソース（ Managed Node Group や Fargate など）と併用できます。

組込みの NodeClass, NodePool は編集できない

Auto Mode には以下の組込みの NodeClass, NodePool があります。

• NodeClass
  • default
• NodePool
  • system
  • general-purpose

これらの設定は変更できません。異なる設定の NodeClass, NodePool を利用したい場合は独自の NodeClass, NodePool を作成する必要があります。

コスト

Auto Mode のノードに対して追加料金が発生します。金額は EC2 インスタンスの料金の約 12% 程度のようです。詳細は以下のドキュメントをご参照ください。

• Amazon EKS Pricing | Managed Kubernetes Service | Amazon Web Services

終わりに

この記事では Amazon EKS Auto Mode を利用する際に気をつけるべきことをご紹介しました。

Auto Mode を有効にすることでクラスタ管理者はいくつかのアドオンの保守・運用から開放されます。積極的に利用を検討したいですね。

最後までお読みいただき、ありがとうございました。

参考資料

• Automate cluster infrastructure with EKS Auto Mode - Amazon EKS
• EKS Auto Mode - Speaker Deck

私たちは一緒に働いてくれる仲間を募集しています！

電通総研 キャリア採用サイト 電通総研 新卒採用サイト

執筆：@shibata.takao、レビュー：@nagamatsu.yuji
（Shodoで執筆されました）

---

1. Create a storage class - Amazon EKS↩
2. Learn about VPC Networking and Load Balancing in EKS Auto Mode - Amazon EKS↩
3. 実際には Auto Mode の mutating webhook の影響で .spec.loadBalancerClass を未指定のままにすることはできません。↩
4. Create a Node Class for Amazon EKS - Amazon EKS, Create a Node Pool for EKS Auto Mode - Amazon EKS↩