EKS Auto Modeの検証
メディア統括本部 サービスリライアビリティグループ（SRG）の鈴木（@sZma5a）です。
#SRG（Service Reliability Group）は、主に弊社メディアサービスのインフラ周りを横断的にサポートしており、既存サービスの改善や新規立ち上げ、OSS貢献などを行っているグループです。
本記事は、EKSの運用自動化機能「EKS Auto Mode」の技術検証結果を共有し、そのメリットと、導入を見送る判断に至った技術的制約を具体的に解説する記事です。
はじめに
KubernetesのマネージドサービスであるAmazon EKSは、コンテナ化されたアプリケーションのデプロイや管理を簡素化しますが、アドオンのアップデートやノード管理など、依然として多くの運用コストが発生します。
これらの運用負荷をさらに軽減し、開発者がより本質的な作業に集中できる環境を目指すため、EKSの運用を大幅に自動化する新機能「EKS Auto Mode」の導入を検討しました。
本記事では、その技術検証の結果、得られたメリット、そして導入を見送る判断に至った理由について共有します。
EKS Auto Modeとは
EKS Auto Modeは、Amazon EKSの運用負荷を軽減するための機能です。
ノードのプロビジョニングやスケーリング、OSのパッチ適用といったノード管理や、特定の公式アドオンのアップデートといったミドルウェア管理をAWS側に移譲できます。これにより、クラスター運用の複雑さが抽象化され、インフラ管理の手間を大幅に削減されることが期待できます。
EKS Auto Modeでは、主に以下のコンポーネントがAWSによって管理されます。
- Amazon VPC CNI (コンテナネットワークインターフェース)
- AWS Load Balancer Controller (ロードバランサーコントローラー)
- CoreDNS (クラスターDNS)
- kube-proxy (ネットワークプロキシ)
- Karpenter (ノードプロビジョナー)
- AWS EBS CSI driver (EBS用コンテナストレージインターフェースドライバー)
導入による運用工数の削減
EKS Auto Modeを導入する最大のメリットは、運用工数の大幅な削減です。
これまで手動で行っていたEKS公式アドオンのアップデート作業が不要になります。
私たちの環境では、調査・検証を含め各アドオンのアップデートに約2週間ほどの工数がかかっていました。
これらの作業を合算し各アドオンの更新頻度を考慮すると、月あたり約26日〜30日もの工数がかかっている計算になります。EKS Auto Modeを導入すれば、これらのアドオンはAWSによって管理・検証された上でアップデートされるため、検証工数を大幅に削減できます。
また、セキュリティフィックスは自動で適用されるため、脆弱性対応の負荷が軽減される点も大きなメリットとしてあげられます。
コストに関するトレードオフ
運用工数を削減できる一方で、EKS Auto Modeの利用には追加の料金が発生します。
私たちの環境で試算したところ、導入によってAWS利用料全体に対して約3.5%の増加が見込まれました。
このコスト増と、前述の工数削減効果を天秤にかけ、導入の是非を判断する必要があります。私たちの環境では、作業工数と比較しこのコスト増は受け入れられる範囲だと判断しました。
EKS Auto Modeの適用方法
ダッシュボード上からEKS Auto Modeを有効化した際、まずAWSが管理するEKSのコントロールプレーンにKarpenterやAWS Load Balancer Controllerといったマネージドアドオンのコントローラーが追加されます。
併せて、Auto Modeに対応したノードを作成するためのNodeClassが提供され、これを用いてNode PoolをマネージドなKarpenterの管理下に置くと、該当プールに所属するノードがEKS Auto Modeの機能を利用できる形で自動的にプロビジョニングされます。
重要なのは、有効化しただけの段階ではカスタムリソースやコントローラーが用意されるものの、Node Poolの切り替えや追加を行わない限り、実運用上の機能的な差分は表面化しないという点です。課金についても、ノード単位で発生し、対象はマネージドKarpenter配下に属するノードとなります。
さらに、マネージドで提供されるアドオンはセルフ管理のものとAPIバージョンが異なるため、同一クラスター内での共存が可能であり、段階的な移行や一部ワークロードのみの採用といった柔軟な導入パターンを取りやすくなっています。
技術的な制限事項と課題
検証を進める中で、EKS Auto Modeにはいくつかの重要な技術的制限があることが分かりました。
アドオンのダウングレード不可
マネージドアドオンはクラスターバージョンと連動してアップデートされるため、バージョンを任意にダウングレードできません。
ネットワークインターフェースの固定
コンテナネットワークインターフェース(CNI)は、AWS VPC CNIに固定されます。
私たちの環境では元々AWS VPC CNIを使用していたため問題ありませんでしたが、他のCNIを利用している場合は移行が必要になります。
TargetGroupBindingの移行に関する注意点
既存のセルフマネージドなAWS Load Balancer ControllerからEKS Auto Modeに移行する際、同じターゲットグループを使い回すと競合が発生し、ダウンタイムにつながる可能性があります。
安全に移行するためには、新規にターゲットグループを作成し、トラフィックを移管する手順が必要となります。
ノードのライフサイクル
Auto Modeで管理されるノードは、アップデートの都合上、最長でも21日でローテーションされます。
Podに適切な を設定することで安全にシャットダウンできますが、長時間のバッチ処理などを実行するワークロードでは注意が必要です。私たちの環境ではすでにKarpenterを使用しており、永続的にノードを起動する想定でなかったため、特に問題になりませんでした。
ノードOSの固定
ノードのOSは、コンテナ実行に最適化されたLinuxディストリビューションである「Bottlerocket」に固定されます。そのため、OSレベルでのカスタマイズやカーネルレベルで監視するセキュリティツールなどをインストールしている場合、対応できなくなる可能性があります。
ドメインの名前解決不可
EKS Auto Mode環境では、Route 53のプライベートホストゾーンで サフィックスを使用していると、名前解決ができなくなる制約があります。
私たちの環境では内部通信に ドメインを利用していたため、これを別のドメインに置き換える大規模な改修が必要であることが判明しました。
Security Groups for Pods (SGP) の利用不可
検証時点で最も大きな課題となったのが、Pod単位で個別のセキュリティグループを割り当てる「Security Groups for Pods」機能が利用できない点です。
私たちの環境では、マルチテナントで運用されているためこの機能を広く利用しており、セキュリティ要件を満たすための代替手段の確保が困難であるという結論に至りました。
検証結果まとめと今後の展望
EKS Auto Modeは、アドオン管理の工数を月あたり最大30日も削減できる可能性を秘めた、非常に魅力的な機能です。
一方で、「.localドメインの利用不可」や「Security Groups for Podsの非対応」といった、私たちの環境では妥協できない技術的制約が存在することも明らかになりました。特に、セキュリティに関わるSecurity Groups for Podsが利用できない点は、導入を見送る決定的な要因となりました。
結論として、現時点でのEKS Auto Modeの導入は見送ることとしましたが、EKS Auto Mode自体がまだ新しく、今後このような点が解決されることが予想されます。そのため、チームとしても現状移行は難しいがこれらの制約条件が解消された際は、積極的に導入を進めていく方針を固めました。
そのため、特にSecurity Groups for Podsがサポートに関し注視し、解消された際は改めて導入を進めていきたいと考えています。
SRG では一緒に働く仲間を募集しています。
ご興味ありましたらぜひこちらからご連絡ください。