[メモ]Amazon EKS Auto Modeの所感
今回はAmazon EKSで発表されたAuto Modeについて簡単に調査・検証したので、概要と所感を記載します。
EKS Auto Modeとは
EKS Auto Modeは、Amazon EKSの運用周りの一部機能をAWS側が管理し、利用者の運用負荷やコスト管理を軽減してくれる機能です。具体的にはデータプレーンノードのオートスケール、Add-onによる関連コンポーネントの管理、クラスターアップグレード時の自動更新などを含みます。
AWSの公式アナウンスでは以下のように紹介しています。
本日 re:Invent において、AWS は Amazon Elastic Kubernetes Service (Amazon EKS) の Auto Mode を発表しました。これは、Kubernetes クラスターのコンピューティング、ストレージ、およびネットワーキングの管理を完全に自動化する新機能です。Amazon EKS Auto Mode は、クラスターの運用を AWS にオフロードすることで Kubernetes の実行を簡素化し、アプリケーションのパフォーマンスとセキュリティを向上させ、コンピューティングコストを最適化するのに役立ちます。
所感
Auto Modeの調査や検証を踏まえての所感を記載します。
クラスター作成
クラスター作成はAWSマネジメントコンソール / AWS CLI / eksctlで実行できます。今回はマネジメントコンソールから作成してみましたが、クラスター作成で必要になるIAMロールの作成が簡単にできるのはありがたかったです。具体的にはIAMロール作成画面に移動すると、ユースケースに EKS - Auto Cluster EKS - Auto Node というユースケースが用意されており、これを選択してロールを作成するだけで完了しました。
コンピューティング
Auto ModeはPodが作成されるまでData planeノードを起動しません。そのため初回Podが作成されるときは通常のEC2 Data planeより多少起動まで時間がかかります。この辺りはEKS on Fargateを使っているときと似た感覚がありました。
[cloudshell-user@ip-10-130-62-92 ~]$ kubectl run nginx --image=nginx
pod/nginx created
[cloudshell-user@ip-10-130-62-92 ~]$ kubectl get pods -w
NAME READY STATUS RESTARTS AGE
nginx 0/1 Pending 0 6s
nginx 0/1 Pending 0 25s
nginx 0/1 ContainerCreating 0 25s
nginx 1/1 Running 0 46s
[cloudshell-user@ip-10-130-62-92 ~]$ kubectl get nodes
NAME STATUS ROLES AGE VERSION
i-0e519abc4dcad7e54 Ready <none> 66s v1.31.1-eks-1b3e656
ただしFargateと違うのは、一度ノードが起動すれば (キャパシティ等の影響で新しいノードが立ち上がらない限り) ノード上にコンテナイメージのキャッシュが残るため、次回以降のPodの起動が高速になる点です。またFargateはGPUなどには対応していないため、Auto Modeのほうが対応できるケースは多いと思われます。
[cloudshell-user@ip-10-130-62-92 ~]$ kubectl run nginx2 --image=nginx
pod/nginx2 created
[cloudshell-user@ip-10-130-62-92 ~]$ kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx 1/1 Running 0 15m
nginx2 1/1 Running 0 6s
[cloudshell-user@ip-10-130-62-92 ~]$
また、デフォルトの状態で使うと、上記のようにNginx Podを立ち上げたときは c5a.large のインスタンスが立ち上がりました。東京リージョンではこのサイズの時間単価は $0.096 + $0.01152 = $0.10752 であり、同じスペックであれば別のインスタンスタイプで安価なものもあります。
※EKS Auto Modeを利用するときは通常のインスタンス料金に追加料金が発生します。
例えば開発環境やテスト環境のためにAuto Modeを採用したい場合、EKSのコストを抑えたいという要望が出ると思います。そのため利用者は必要に応じてカスタムなNodePoolを作成する必要があります。
なおAuto ModeはAWSの管理するKarpenterを採用しており、クラスター作成時点でNodeClass / NodePoolが作成されます。デフォルトの設定は以下の通りです。
[cloudshell-user@ip-10-134-5-103 ~]$ kubectl get nodepool
NAME NODECLASS NODES READY AGE
general-purpose default 0 True 13m
system default 0 True 13m
[cloudshell-user@ip-10-134-5-103 ~]$ kubectl get nodeclass
NAME ROLE READY AGE
default AmazonEKSAutoNodeRole True 13m
[cloudshell-user@ip-10-134-5-103 ~]$ kubectl get nodepool general-purpose -oyaml
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
annotations:
karpenter.sh/nodepool-hash: "4012513481623584108"
karpenter.sh/nodepool-hash-version: v3
creationTimestamp: "2024-12-26T06:15:51Z"
generation: 1
labels:
app.kubernetes.io/managed-by: eks
name: general-purpose
resourceVersion: "1057"
uid: 4bfa573a-e334-4b3e-b99c-d1743eac5f0d
spec:
disruption:
budgets:
- nodes: 10%
consolidateAfter: 30s
consolidationPolicy: WhenEmptyOrUnderutilized
template:
metadata: {}
spec:
expireAfter: 336h
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
requirements:
- key: karpenter.sh/capacity-type
operator: In
values:
- on-demand
- key: eks.amazonaws.com/instance-category
operator: In
values:
- c
- m
- r
- key: eks.amazonaws.com/instance-generation
operator: Gt
values:
- "4"
- key: kubernetes.io/arch
operator: In
values:
- amd64
- key: kubernetes.io/os
operator: In
values:
- linux
terminationGracePeriod: 24h0m0s
status:
conditions:
- lastTransitionTime: "2024-12-26T06:16:07Z"
message: ""
observedGeneration: 1
reason: ValidationSucceeded
status: "True"
type: ValidationSucceeded
- lastTransitionTime: "2024-12-26T06:16:09Z"
message: ""
observedGeneration: 1
reason: NodeClassReady
status: "True"
type: NodeClassReady
- lastTransitionTime: "2024-12-26T06:16:09Z"
message: ""
observedGeneration: 1
reason: Ready
status: "True"
type: Ready
resources:
cpu: "0"
ephemeral-storage: "0"
memory: "0"
nodes: "0"
pods: "0"
[cloudshell-user@ip-10-134-5-103 ~]$ kubectl get nodeclass default -oyaml
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
annotations:
eks.amazonaws.com/nodeclass-hash: "3809868827326149578"
eks.amazonaws.com/nodeclass-hash-version: v1
creationTimestamp: "2024-12-26T06:15:51Z"
finalizers:
- eks.amazonaws.com/termination
generation: 1
labels:
app.kubernetes.io/managed-by: eks
name: default
resourceVersion: "4199"
uid: 5ad682f3-90fc-4773-9966-ff1148333c4d
spec:
ephemeralStorage:
iops: 3000
size: 80Gi
throughput: 125
networkPolicy: DefaultAllow
networkPolicyEventLogs: Disabled
role: AmazonEKSAutoNodeRole
securityGroupSelectorTerms:
- id: sg-06d04b074a304cfd6
snatPolicy: Random
subnetSelectorTerms:
- id: subnet-00d0e5348f6bfb294
- id: subnet-027c2c4266a3bb9c7
status:
conditions:
- lastTransitionTime: "2024-12-26T06:16:09Z"
message: ""
observedGeneration: 1
reason: SubnetsReady
status: "True"
type: SubnetsReady
- lastTransitionTime: "2024-12-26T06:16:09Z"
message: ""
observedGeneration: 1
reason: SecurityGroupsReady
status: "True"
type: SecurityGroupsReady
- lastTransitionTime: "2024-12-26T06:16:09Z"
message: ""
observedGeneration: 1
reason: InstanceProfileReady
status: "True"
type: InstanceProfileReady
- lastTransitionTime: "2024-12-26T06:16:09Z"
message: ""
observedGeneration: 1
reason: Ready
status: "True"
type: Ready
instanceProfile: eks-ap-northeast-1-exciting-synth-sheepdog-2537443890950714400
securityGroups:
- id: sg-06d04b074a304cfd6
name: eks-cluster-sg-exciting-synth-sheepdog-1547813176
subnets:
- id: subnet-00d0e5348f6bfb294
zone: ap-northeast-1c
zoneID: apne1-az1
- id: subnet-027c2c4266a3bb9c7
zone: ap-northeast-1a
zoneID: apne1-az4
[cloudshell-user@ip-10-134-5-103 ~]$
また、Pod自体のオートスケールを管理する機能はなさそうなので、metrics-serverなどを別途導入する必要がありそうです。
アップグレード
Auto Modeクラスターのアップデートを開始すると、クラスター内のNodeの入れ替えを行います。また以下のコンポーネントは利用者が更新する必要がなく、自動的に更新されます。
- CoreDNS
- kube-proxy
- AWS Load Balancer Controller
- Karpenter
- AWS EBS CSI Driver
個人的にAuto Modeで一番うれしいのは、クラスターアップデートの簡易化です。アップデート作業をして面倒なのは、クラスターのバージョンに合わせてAPIが非推奨になっていないかをチェックしたり、必要に応じてクラスター上のコンポーネントを前もって更新する必要がある点です。自作のコントローラーやOSS等を組み合わせてシステムを構築する場合は確認対象のコンポーネントも多くなり、運用負荷が高い作業でした。
APIの廃止についてはUpgrade Insightsの登場でかなり楽になりましたが、更新作業が必要な場合は利用者が行わなければなりません。その点で、CoreDNS/kube-proxy/Load Balancer Controllerあたりの更新もAWSがやってくれるのは、かなりありがたいと感じます。
ただし、当然ながら自前で導入したものは管理しないといけません。またアップデート自体は人がトリガーしないといけません。特にクラスター自体を大量に管理している場合は、スクリプトを組むなどの対応が必要でしょう (ここは自動更新してもよかったのでは、と思ったりしました。例えばUpgrade Insightsと組み合わせて、APIの問題がなければクラスターを更新してくれる、とか) 。
ストレージ
Auto Modeはクラスター作成時点でEBS CSI Driverを利用可能で、適切なStorageClassを作成すれば、リクエストに応じて自動的にEBSをプロビジョニングします。
従来はクラスター作成後にEBS/EFS CSI Driverを利用者が導入する必要があったので、この辺りも楽になりました。ただしEFSは未対応なので、EFSを利用するには別途作業が必要となります。
ネットワーク
Auto ModeはAWS Load Balancer Controllerを利用可能です。そのため IngressClass TargetGroupBinding といったリソースを通じてネットワークを構築できます。
その他
Auto Modeがリリースして2週間後にNode Auto-Repairという機能がリリースされました。
この機能はAuto Modeにも備わっています。今後はAuto Modeの機能拡張もいろいろ入ってくると思うので、楽しみです。
参考ドキュメント
- AWSブログ - 新しい Amazon EKS Auto Mode で Kubernetes クラスター管理を効率化
- DevelopersIO - [アップデート] EKS で Auto Mode が追加されたので試してみた #AWSreInvent
- DevelopersIO - eksctlでAuto ModeのEKSクラスターを作成してみた #AWSreInvent
- DevelopersIO - Auto ModeのEKSでEBSを扱ってみた #AWSreInvent
- DevelopersIO - EKS Auto Mode で Network Policy を利用してみる #AWSreInvent
- DevelopersIO - EKS Auto Mode のクラスターをバージョンアップグレードしてみた#AWSreInvent
- DevelopersIO - EKS Auto Mode で独自の NodePool を作成して利用してみた
- Serverworks Blog - Amazon EKS Auto Mode を試してみました
- Qiita - EKS Auto ModeとEKS on Fargateの違いを調べてみた
- Amazon EKS Auto Mode vs Azure AKS Automatic: The Better Managed Kubernetes Solution?
- EKS Auto Mode launched recently - is it worth the hype?
Discussion