SREの篠原です。
弊社で開発しているモチベーションクラウドはこれまでAmazon ECSを基盤として利用していましたが、先日EKS Auto Modeに移行しました。

移行作業や多少の本番環境での運用を経て、よかった点やポイントなどをお伝えできればと思います。

EKS Auto Modeとは

EKS Auto Mode とは、2024年12月にリリースされた新しい機能です。
EKSのインフラ周りについて、AWS側で自動で管理されるようになります。

詳しい概要や機能については、公式のブログやスライドをみてください。

aws.amazon.com

speakerdeck.com

よかった点

一部のadd-onがマネージドになる

基本的には前評判通り、クラスター構築しPodを立ち上げるだけで動きます。
特にAWS Load Balancer Controllerがマネージドになるのがありがたかったです。

AWS Load Balancer Controller とはIngressの設定に応じて、ALBを構築してくれるコンポーネントです。

kubernetes-sigs.github.io

おそらく初めてEKSを触る人はほぼ確実にハマるところだと思うのですが (偏見)
ここがマネージドになって、ユーザはIngressの設定だけすれば良くなるのはとても便利です。

EKS on EC2で使用できる機能は基本的に使用できる

元々は EKS on Fargate 前提で移行検証を進めていました。
しかし EKS on Fargate の場合だと、利用できない機能がいくつかあります。(例: DaemonSet)
またログ設定など、Fargateだと設定方法が変わるものもあります。

docs.aws.amazon.com

そして世の中のEKS事例の多くは EKS on EC2 のため、Fargate用の情報がなかなか見つからないこともありました。
しかし EKS Auto Mode の場合は大体の EKS on EC2 の設定内容を踏襲できます。
なので EKS Auto Mode 自体の情報はあまりネット上になかったですが、情報不足で困ることは少なかったです。

※ 一部 EKS Auto Modeに未対応の機能もあります。公式の情報を参照してください。

気をつけるポイント

EC2 (Node) について、どこまでが自動管理対象か理解する必要がある

公式のブログの画像を見てみると、EC2については AWS管理とユーザ管理の比率が半々になっています。

引用元: https://aws.amazon.com/jp/blogs/news/getting-started-with-amazon-eks-auto-mode/

そのためどこまでがAWSに任せて良くて、逆にどこは自分で設定しないといけないかを確認する必要があります。

以下のような要素は基本的にマネージドになります。

AMIの設定、アップデート
Instance Typeの指定
使用リソースに合わせたインスタンスのスケールイン/アウト

逆に以下についてはユーザ側で設定する必要があります。

Node分散の設定 (Pod Topology Spread Constraints など)
Pod スケールイン/アウトの設定 (HorizontalPodAutoscaler など)
PodDisruptionBudget

誤解を恐れずざっくり分類すると、以下のようなイメージになるかと思います。
「インフラレイヤーから見た EC2 の管理はAWS管理だが、k8s レイヤーから見た Node に依存する設定はユーザ側で設定が必要となる。」
なので本番稼働させる際には、このような可用性周りの設定が必要です。

Karpenterとある程度仲良くなる必要がある

EKS Auto Mode の機能は基本的には Karpenter によって実現されています。
そのためKarpenterの基本的な知識や振る舞いについては、本番稼働する前には理解しておいた方がいいと思います。

karpenter.sh

特に Consolidation という機能があり、コスト効率がより良くなるように Node の交換や、Pod の再配置などを実施します。
コスト節約に役立つ機能ではあるのですが、Consolidationによって Pod が再起動される可能性があるため、その振る舞いを理解した上で運用する必要があります。
詳細な振る舞いについてはこちらが参考になります。

aws.amazon.com

Consolidation の振る舞いやその他EC2の設定は、Karpenter の NodePool を設定することでカスタマイズすることができます。

karpenter.sh

弊社のKarpenter関連の設定

参考までに、弊社環境では以下のような設定をしています。

scheduleおよびDuration を調整し、開発環境では日勤帯のConsolidationを無効化
- 開発環境では基本的に replica=1 で運用しているため、開発中のランダムなダウンタイムを防ぐためConsolidation を夜間のみ動かすようにしています。
一部再起動を避けたい Pod があるため、Deployment に karpenter.sh/do-not-disrupt: "true" のannotation 追加
- https://karpenter.sh/docs/concepts/disruption/#pod-level-controls

# NodePoolのdescribe結果の一部
Spec:
  Disruption:
    Budgets: # 日本時間 0時から1時のみ Pod が稼働している Node も Consolidation 対象とする設定
      Nodes:     1
      Duration:  23h
      Nodes:     0
      Reasons:
        Underutilized
      Schedule:            0 15 * * *
    Consolidate After:     5m
    Consolidation Policy:  WhenEmptyOrUnderutilized
  Template:
    Spec:
      Expire After:  336h
      Node Class Ref:
        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:       kubernetes.io/arch
        Operator:  In
        Values:
          amd64