はじめに
2024年12月1日 に EKS Auto Mode が GA されたので使ってみました！
使ってみた感想としては、実務で使えるかはまだまだ検証が必要ですが、今まで EKS クラスターを作成してから、導入に一手間が必要だった ALB Controller の管理やワーカーノードの管理をマネージドで行うことで、かなり運用するためのハードルが下がったと感じました。
EKS Auto Mode とは
EKS 自動モードを使用すると、新規または既存の EKS クラスターで Kubernetes 準拠のマネージドコンピューティング、ネットワーク、ストレージを利用できます。
...
EKS 自動モードは、AWS が制御するアクセスとライフサイクル管理を使用して、アカウント内の EC2 インスタンスをプロビジョニング、操作、保護、アップグレードします。OS のパッチと更新を処理し、エフェメラルコンピューティングでセキュリティリスクを制限し、デフォルトでセキュリティ体制を強化します。
このように書かれているように、今まで Kubernetes のバージョンアップ時に対応を行っていた、ワーカーノードや各種アドオンの更新作業をマネージドで行ってくれます。
また、EKS Auto Mode では以下のコンポーネントをマネージドで管理が行われるようです。
- CoreDNS
- KubeProxy
- AWS Load Balancer Controller
- Karpenter
- AWS EBS CSI Driver
クラスター構築
既存クラスターを Auto Mode に移行することも可能のようですが、今回は eksctl を用いて新規にクラスターを構築します。
$ eksctl create cluster --name=s-tanaka-dev-auto-cluster-01 --enable-auto-mode
※ eksctl で Auto Mode を有効化を行うには 0.195.0 以上のバージョンが必要です。
https://github.com/eksctl-io/eksctl/releases/tag/v0.195.0
上記コマンドを実行することで、EKS Auto Mode が有効となった EKS クラスターを新規で構築することができました。
構築した直後に Node を取得してもワーカーノードは存在せず、EC2 も作成されていませんでした。
~ ⎈ s-tanaka-dev-auto-cluster-01 ❯ kubectl get node ▼ 04:56:53 PM
No resources found
~ ⎈ s-tanaka-dev-auto-cluster-01 ❯
ただ、適当に Nginx の Deployment を apply すると以下のようにワーカーノードと c5a.large の EC2 が作成され Pod が Running となりました。
~ ⎈ s-tanaka-dev-auto-cluster-01 ❯ k apply -f nginx.yml
deployment.apps/nginx-deployment created
~ ⎈ s-tanaka-dev-auto-cluster-01 ❯ k get node -o wide
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
i-02603338ec9143f48 Ready <none> 2m43s v1.30.5-eks-baa6d11 192.168.105.2 <none> Bottlerocket (EKS Auto) 2024.11.25 (aws-k8s-1.30) 6.1.115 containerd://1.7.22+bottlerocket
~ ❯
~ ⎈ s-tanaka-dev-auto-cluster-01 ❯ k get po -A
NAMESPACE NAME READY STATUS RESTARTS AGE
default nginx-deployment-77d8468669-76wfj 1/1 Running 0 2m59s
default nginx-deployment-77d8468669-cchqk 1/1 Running 0 2m59s
default nginx-deployment-77d8468669-s4jcg 1/1 Running 0 2m59s
~ ⎈ s-tanaka-dev-auto-cluster-01 ❯
ロードバランサーを使用するワークロード
上述した通り、EKS Auto Mode では AWS Load Balancer Controller もマネージドで管理が行われます。
そのため、Ingress リソースを作成すると AWS Load Balancer Controller のセットアップをせずとも ELB がプロビジョニングされます。
今回は公式チュートリアルで用意されている以下のマニフェストを apply しました。
apiVersion: v1
kind: Namespace
metadata:
name: game-2048
---
apiVersion: apps/v1
kind: Deployment
metadata:
namespace: game-2048
name: deployment-2048
spec:
selector:
matchLabels:
app.kubernetes.io/name: app-2048
replicas: 5
template:
metadata:
labels:
app.kubernetes.io/name: app-2048
spec:
containers:
- image: public.ecr.aws/l6m2t8p7/docker-2048:latest
imagePullPolicy: Always
name: app-2048
ports:
- containerPort: 80
resources:
requests:
cpu: "0.5"
---
apiVersion: v1
kind: Service
metadata:
namespace: game-2048
name: service-2048
spec:
ports:
- port: 80
targetPort: 80
protocol: TCP
type: NodePort
selector:
app.kubernetes.io/name: app-2048
---
apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
namespace: game-2048
labels:
app.kubernetes.io/name: LoadBalancerController
name: alb
spec:
controller: eks.amazonaws.com/alb
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
namespace: game-2048
name: ingress-2048
annotations:
alb.ingress.kubernetes.io/scheme: internet-facing
alb.ingress.kubernetes.io/target-type: ip
spec:
ingressClassName: alb
rules:
- http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: service-2048
port:
number: 80
apply を行うと、以下のように ALB がプロビジョニングされていることが確認できました。
~ ⎈ s-tanaka-dev-auto-cluster-01 ❯ k apply -f game.yaml
namespace/game-2048 created
deployment.apps/deployment-2048 created
service/service-2048 created
ingressclass.networking.k8s.io/alb created
ingress.networking.k8s.io/ingress-2048 created
~ ❯
~ ⎈ s-tanaka-dev-auto-cluster-01 ❯ k get ingress -A
NAMESPACE NAME CLASS HOSTS ADDRESS PORTS AGE
game-2048 ingress-2048 alb * k8s-game2048-ingress2-xxxxxxxx-xxxxxxx.ap-northeast-1.elb.amazonaws.com 80 89s
~ ❯
加えて、このようにアクセスできることも確認できました。
永続ボリュームを使用するワークロード
AWS Load Balancer Controller 以外にも EBS CSI アドオンも対応をしているため、公式チュートリアルの内容を元に検証を行いました。
同様に公式チュートリアルで用意されている以下のマニフェストを apply しました。
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: auto-ebs-sc
annotations:
storageclass.kubernetes.io/is-default-class: "true"
provisioner: ebs.csi.eks.amazonaws.com
volumeBindingMode: WaitForFirstConsumer
parameters:
type: gp3
encrypted: "true"
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: auto-ebs-claim
spec:
accessModes:
- ReadWriteOnce
storageClassName: auto-ebs-sc
resources:
requests:
storage: 8Gi
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: inflate-stateful
spec:
replicas: 1
selector:
matchLabels:
app: inflate-stateful
template:
metadata:
labels:
app: inflate-stateful
spec:
terminationGracePeriodSeconds: 0
nodeSelector:
eks.amazonaws.com/compute-type: auto
containers:
- name: bash
image: public.ecr.aws/docker/library/bash:4.4
command: ["/usr/local/bin/bash"]
args: ["-c", "while true; do echo $(date -u) >> /data/out.txt; sleep 60; done"]
resources:
requests:
cpu: "1"
volumeMounts:
- name: persistent-storage
mountPath: /data
volumes:
- name: persistent-storage
persistentVolumeClaim:
claimName: auto-ebs-claim
上記のマニフェストを apply すると、Pod の中身までは確認しませんでしたが EBS が作成され問題なく Bound されていることを確認できました。
~ ⎈ s-tanaka-dev-auto-cluster-01 ❯ k apply -f storage.yaml
storageclass.storage.k8s.io/auto-ebs-sc created
persistentvolumeclaim/auto-ebs-claim created
deployment.apps/inflate-stateful created
~ ❯
~ ⎈ s-tanaka-dev-auto-cluster-01 ❯ k get pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS VOLUMEATTRIBUTESCLASS AGE
auto-ebs-claim Bound pvc-86c5f600-88bd-4992-b831-311e06864f4a 8Gi RWO auto-ebs-sc <unset> 91s
~ ❯
まとめ
作成されるインスタンスタイプなど制御が必要な部分は多いと思いますが、「はじめに」で記述した通り、導入に一手間必要だった ALB Controller を導入せずとも使うことができるのに加えて、学習コストが高い EKS を使うためのハードルが下がり使いやすくなったのではと感じています。
これを機に EKS を扱ってみてはいかがでしょうか。
参考
https://docs.aws.amazon.com/eks/latest/userguide/auto-elb-example.html
https://docs.aws.amazon.com/eks/latest/userguide/sample-storage-workload.html