詳解: Amazon EKS Auto Mode

この記事は Under the hood: Amazon EKS Auto Mode (記事公開日: 2025 年 3 月 31 日) を翻訳したものです。

この記事は、EKS シニアプロダクトマネージャーの Alex Kestner、EKS シニアソフトウェアエンジニアの Todd Neal、EKS シニアソフトウェア開発マネージャーの Neelendra Bhandari、プリンシパルスペシャリストソリューションアーキテクトの Sai Vennam が共同執筆しました。

re:Invent 2024 で、Amazon Elastic Kubernetes Service (Amazon EKS) Auto Mode を発表しました。EKS Auto Mode は、すぐにワークロードをホストできる、Kubernetes 準拠の本番環境対応のクラスターを提供する新機能です。この記事では、EKS Auto Mode が Kubernetes ワークロードにとってどのような意味を持つのか、そして EKS Auto Mode クラスターの内部構造について詳しく説明します。

EKS Auto Mode の概要

EKS Auto Mode を利用するとアプリケーションをより効率的に運用できるようになります。Kubernetes コントロールプレーンとワーカーノードのセットアップ、スケーリング、メンテナンスを自動的に管理するため、基盤となるインフラストラクチャを気にする必要がありません。アプリケーションのデプロイに集中すれば、EKS Auto Mode が残りの部分を処理します。これは、複雑さを管理することなく Kubernetes を使用したいユーザーに最適です。

2017 年の re:Invent で、Kubernetes の運用を効率化する Amazon EKS をローンチしました。ローンチ時の Amazon EKS は、AWS Identity and Access Management (IAM) などの既存のサービスと統合された、マネージド Kubernetes コントロールプレーンを提供しました。私たちはそのコントロールプレーンの健全性とパッチ適用に責任を持ち、現在ユーザーは毎年数千万の EKS クラスターを実行しています。しかし、ワークロードが実行される Kubernetes クラスターのデータプレーンである Amazon Elastic Compute Cloud (Amazon EC2) ノードの運用はユーザーが責任を負っていました。マネージドノードグループや Karpenter などの機能を年々導入し、データプレーンの運用負荷を軽減してきましたが、ユーザーは依然として、適切な OS の選択、基盤となるノードのスケーリング、CNI や kube-proxy などのコアアドオンやコンポーネントの管理に責任を負っていました。

Figure 1: Shared Responsibility Model with Amazon EKS (without Auto Mode)

図 1: Amazon EKS (Auto Mode を含まない) の責任共有モデル

EKS Auto Mode は、2017 年に導入した運用モデルの進化版で、Kubernetes クラスターのデータプレーン部分の責任を AWS がより多く引き受け、マネージド型のコンピューティング、ネットワーキング、ストレージ機能を提供します。EKS Auto Mode を使用すると、ユーザーはクラスターを作成し、すぐに本番環境対応のワークロードをデプロイできます。EC2 インスタンスの設定、パッチ適用、健全性の管理は AWS が担当するため、ユーザーは VPC とクラスターの設定、および実行するアプリケーションコンテナにのみ注力できます。

Figure 2: Shared Responsibility Model with EKS Auto Mode

図 2: Amazon EKS (Auto Mode を含む) の責任共有モデル

EKS Auto Mode におけるデータプレーン

EKS Auto Mode クラスターのデータプレーンを構成する重要なコンポーネントがいくつかあります。

EC2 マネージドインスタンスは、AWS に運用管理が委任された標準的な EC2 インスタンスです。
Bottlerocket は、AWS がコンテナの実行を目的に構築したオープンソースのオペレーティングシステムです。
コア機能とアドオンは EKS Auto Mode が管理するノードに組み込まれており、ユーザーがこれらのコンポーネントを管理・維持する必要がありません。
ワーカーノード管理 (Karpenter) は、ワーカーノードの健全性を自動的に処理し、コスト効率を最適化するための理想的なインスタンスタイプでノードを削除および置き換えることができます。

EC2 マネージドインスタンス

最も基本的なレベルでは、EKS Auto Mode は re:Invent 2024 で発表された新機能である EC2 マネージドインスタンスを使用します。マネージドインスタンスは標準的な EC2 インスタンスですが、Amazon EKS のような AWS サービスに運用管理を委任している点が異なります。基本的に、EKS Auto Mode は運用のオーバーヘッドと一部の制御を手放すことで、セキュリティの向上を得ることができます。例えば、マネージドストレージ機能がワークロードに必要な EBS ボリュームのアタッチとデタッチを担当するため、EKS Auto Mode が管理するノードから Amazon Elastic Block Store (Amazon EBS) ボリュームを手動でデタッチする必要がなくなります。同様に、ノードに直接 SSH 接続することはできませんが、Amazon EKS サービスを通じてインスタンスの情報取得やトラブルシューティングを行う機能は常に維持されています。EKS クラスターの削除時にクラスターに関連付けられた EC2 マネージドインスタンスが強制的に終了されるため、EKS クラスターのクリーンアップがより直接的になります。

EC2 マネージドインスタンスにより、EKS Auto Mode は Kubernetes ワークロードのコンピューティングキャパシティをシームレスに管理できます。そのため、ノードの管理ではなく、アプリケーションのデプロイと実行に集中できます。ワークロードは、AWS Lambda や AWS Fargate のように、AWS がお客様に代わってワークロードを実行する場合と同じ基準で維持されます。既存ノードのキャパシティをワークロードが超過した場合、EKS Auto Mode は Karpenter (後述のワーカーノード管理セクションで詳しく説明) を使用して、高可用性とパフォーマンスを確保するために EC2 マネージドインスタンスを動的にプロビジョニングし、手動でのスケーリング調整の必要性を排除します。

EC2 マネージドインスタンスは、インフラストラクチャ管理の合理化だけでなく、コストの最適化にも役立ちます。リザーブドインスタンスや Savings Plans などの既存の AWS のコスト削減メカニズムを利用でき、予測可能な支出を維持しながら柔軟性を提供します。

EKS Auto Mode を通じて EC2 マネージドインスタンスを使用することで、AWS がインフラストラクチャを管理する完全マネージド型の Kubernetes をユーザーは利用でき、アプリケーションの開発とスケーリングに集中できます。

オペレーティングシステムとしての Bottlerocket の選択肢

EC2 マネージドインスタンスは、他の EC2 インスタンスと同様にオペレーティングシステムが必要です。EKS Auto Mode は、Bottlerocket を使用します。これは AWS がコンテナ実行を目的として開発したオープンソースのオペレーティングシステムです。Bottlerocket は、Kubernetes ワークロードを効率的かつ安全に実行するように設計されているため、EKS Auto Mode の理想的なベースオペレーティングシステムです。Bottlerocket には、コンテナの実行に必要なソフトウェアのみが含まれています。大規模な汎用オペレーティングシステムが約 50,000 のパッケージ定義を持つのに対し、Bottolerocket のオープンソースプロジェクトは約 100 のパッケージ定義を維持しています。これにより、不要な機能と依存関係がビルド時に無効化されます。さらに、コンテナのユースケースに不要なサービスを排除することで、潜在的な CVE の対象領域を減らすとともに、ワークロードにより多くのリソースを提供します。Bottlerocket は、ルートファイルシステムの暗号化整合性チェックと、SELinux などの強制アクセス制御を実施し、コンテナエスケープが発生した場合の攻撃対象領域を削減します。

EKS Auto Mode で利用する Amazon Machine Image (AMIs) は、Bottlerocket の新しい Out of Tree Build (OOTB) システムを使用するカスタム Bottlerocket バリアントです。OOTB は、カスタム Bottlerocket バリアントを作成するための合理化されたメカニズムです。OOTB はバリアントと Bottlerocketのコア部分との依存関係を疎結合に定義します。これにより、カスタムバリアントは独自の進化を遂げながらも、Bottlerocketのコアアップデートを安全に取り入れることができます。kernel kit と core kit は Bottlerocket のコアを形成し、EKS Auto Mode で利用する AMI はこれらを Bottlerocket プロジェクトから取り込むことで、セキュリティと慎重に選定された依存関係に焦点を当てた恩恵を受けています。

EKS Auto Mode 固有の新しいノード機能を提供するだけでなく、Auto Mode AMI は Bottlerocket の基本的な設定にもいくつかの変更を加えています。たとえば、標準の Bottlerocket は SSH やコンソールを介したインタラクティブなログインをサポートしていません。代わりに、アクセスを提供するためのホストコンテナと呼ばれる特別なタイプのコンテナを利用することができます。EKS Auto Mode は Bottlerocket ホストコンテナを完全に無効化し、代わりにノードログの取得や、ノードとの直接的なやり取りのための Kubernetes ネイティブなメカニズムを提供します。これには、ネットワーク接続がない場合のノードのトラブルシューティング情報の取得などが含まれます。また、EKS Auto Mode は、ブートストラップコマンドのような新しい Bottlerocket の機能を利用して、ローカルインスタンスストレージ (インスタンスタイプが対応している場合) を設定します。これにより、対応するインスタンスタイプに含まれる高速なエフェメラルローカルストレージが、コンテナイメージ、Pod のエフェメラルデータ、およびログに自動的に使用されます。

コアノードの機能

Kubernetes ノードには通常、ノードレベルの重要な機能を提供するための Pod を作成する DaemonSet が必要です。ユーザーからは、これらのコンポーネントの管理、パッチ適用、互換性の確保が困難で時間がかかるという声が多く寄せられていました。EKS Auto Mode の一環として、最も一般的に使用されるコンポーネントについて、この煩雑な作業を解消しました。まず、EKS クラスターの大多数で使用されているコアとなるノード機能を特定し、それらの機能を EKS Auto Mode ノードに直接組み込むように取り組みました。

ネットワーク:ノードのローカルネットワーク設定、DNS、および Network Policy の適用
ストレージ: Amazon EBS にバックアップされた Persistent Volume と、一時データ用のローカルインスタンスストレージの、オペレーティングシステムレベルの設定
アイデンティティ: Pod に IAM アイデンティティを設定できるようにします
専門ハードウェアのサポート
- AWS Neuron: Inferentia アクセラレータと Trainium アクセラレータを Pod で利用できるようにするドライバとデバイスプラグイン
- NVIDIA: NVIDIA GPU を Pod で使用できるようにするためのドライバーとデバイスプラグイン
- Elastic Fabric Adapter (EFA): EFA デバイスを Pod で使用できるようにするドライバーとデバイスプラグイン
ヘルス: ノードヘルスモニタリング。特定の障害モードのレポート作成と自動修復が可能

上記から、EKS Auto Mode を利用するクラスターでは Network Policy での適切なネットワーク設定、Pod Identity を使用した AWS サービスへのリクエスト、Persistent Volume を使用した EBS へのデータ保存を行う Pod を作成できます。NodePool がアクセラレーテッドインスタンスタイプをサポートしている場合、ノード上の Pod はリソースリクエストを通じて Neuron アクセラレータや NVIDIA GPU を使用することもできます。さらにユーザーの負担を軽減するため、組み込みのヘルスモニタリングは、Amazon EKS の運用を通じて特定してきた一連の問題や障害モードを定期的にチェックし、Kubernetes のイベントやコンディションを通じて報告します。応答しない kubelet やプロセス ID の枯渇などのエラーケースでは、EKS Auto Mode はノードを自動的に修復し、置き換えることでアプリケーションへの影響を最小限に抑えることができます。

ワーカーノードの管理

Karpenter を活用した EKS Auto Mode のコンピュート機能は、EC2 マネージドインスタンスと Bottlerocket ベースの EKS Auto Mode AMI を組み合わせて、EKS Auto Mode ノードを作成します。このコンピュート機能は、ワークロードの実行に必要なコンピュート容量を提供するために、必要に応じてノードを自動的に起動および終了します。これらのノードは、設定された NodePool とクラスター内のワークロード要件に基づいて、コスト効率を継続的に最適化します。

このプロセスは、ワークロード要件 (CPU、メモリ、または特殊なハードウェアのニーズなど) と Kubernetes のスケジューリング制約を満たす、最もコスト効率の高いインスタンスタイプを特定することから始まります。ワークロードや NodePool の要件を通じてインスタンスタイプの選択を正確に制御するか、より広範なインスタンスタイプを許可することで柔軟性を維持しコストを削減することができます。適切なインスタンスが特定されると、EKS Auto Mode は、それらの特定のインスタンスタイプに対応する Auto Mode AMI を使用して、必要な EC2 マネージドインスタンスを起動します。

時間の経過とともに、需要に合わせてスケールアップ / スケールダウンしたり、ワークロードがクラスターに追加 / 削除されたりすると、ワークロード要件が変化する可能性があります。EKS Auto Modeは、統合プロセスの一環としてクラスター全体を継続的に評価し、ワークロードをより費用対効果の高い方法で実行できるかどうかを判断します。大まかに言うと、次の 2 つの方法でこれを実現しています。

ノードの削除: クラスター内の他のノードの利用可能なキャパシティで、そのノードのすべての Pod が実行できる場合、そのノードは削除の対象となります。
ノードの置き換え: 既存のノードの利用可能なキャパシティと、より低コストの代替ノード 1 つの組み合わせで、そのノードのすべての Pod を再分配できる場合、そのノードは置き換えの対象となります。

迅速なノードプロビジョニングと継続的なコスト最適化のシームレスな統合により、EKS Auto Mode がノード管理タスクを処理する間、ユーザーはクラスター内のワークロードに集中できます。

ノードのライフサイクルとメンテナンス

EKS Auto Mode が登場する以前は、ノードレベルのコンポーネントと EKS クラスターコントロールプレーンの互換性の検証、それらのコンポーネントのデプロイ、パッチ適用と更新管理はユーザーの責任でした。Cluster Insights のような機能により、非互換性を表示することで負担は軽減されましたが、デプロイとパッチ適用はユーザーの責任のままでした。EKS Auto Mode では、すべてのコアノード機能を含むテスト済みの最新 AMI を、すべての EKS Auto Mode ノードで継続的に利用できるようにすることで、AWS がその責任を引き受けます。Auto Mode AMI のビルドとリリースプロセスは、以下を担当する継続的デプロイメントパイプラインによって駆動されます。

CVE スキャン
AMI のビルド
AMI の検証
- Kubernetes コンフォーマンステスト
- コンポーネントの機能テスト (例: Pod が EKS Pod Identity を通じて IAM 認証情報を取得できることの検証)
- セキュリティテスト
AMI のデプロイ

このパイプラインは、安全なハンズオフデプロイメントの自動化の標準的なベストプラクティスに従っています。このプロセスは、新しくテストされた AMI を単一のリージョン内の少数の EKS Auto Mode クラスターにデプロイすることから始まり、潜在的な問題を検出するための時間を設けています。AMI の安定性に対する信頼性が高まるにつれて、より多くのクラスターに段階的にロールアウトされ、より大規模な展開とより多くの AWS リージョンへの展開が行われ、デプロイメント間の時間も短縮されていきます。

EKS Auto Mode では、ユーザーがすべてのコントロールプレーンのアップグレードを制御およびトリガーすることができます。データプレーンの更新については、Pod Disruption Budget と Node Disruption Budget を使用して更新プロセスを管理できます。これらのツールは、 Pod とノードの両方のレベルで詳細な制御を提供します。

Pod Disruption Budgets は、特定のワークロード更新時に許可される中断の最大数を定義します。
Node Disruption Budgets は、メンテナンスウィンドウを指定し、同時に更新できるノード数を制御することができます。

AWS が新しいセキュリティパッチを適用した EKS Auto Mode AMI をリリースすると、EKS Auto Mode は Kubernetes のスケジューリング制約と設定された Disruption Budgets を考慮しながら、ワーカーノードを自動的にアップグレードできます。EKS のベストプラクティスドキュメントでは、アップデート中のアプリケーションの信頼性を維持するための具体的な推奨事項など、これらの制御を効果的に実装するための詳細なガイダンスを提供しています。

まとめ

Amazon EKS Auto Mode は、ユーザーが AWS 上で Kubernetes を実行する方法を大きく進化させたものです。セキュアなコンピュート管理のための Amazon EC2 マネージドインスタンス、コンテナ最適化オペレーティングシステムとしての Bottlerocket、そして重要な機能が組み込まれたノードを組み合わせることで、EKS Auto Mode はユーザーがインフラストラクチャ管理からアプリケーション開発へと注力できるようにします。ノードコンポーネントの設定、セキュリティパッチの管理、運用ツールのメンテナンスに時間を費やす代わりに、チームはビジネスにとって重要なアプリケーションのデプロイとスケーリングに集中できます。

EKS Auto Mode を使用してクラスターインフラストラクチャを自動化する準備はできましたか？ eksctl、AWS CLI、AWS マネジメントコンソール、EKS API、またはお好みの Infrastructure as Code ツールを使用して、新しい EKS Auto Mode クラスターをデプロイしたり、既存のクラスターで EKS Auto Mode を有効にしたりできます。ワークロードのデプロイと Auto Mode の機能を探索するハンズオンワークショップをお試しください。お客様自身の AWS アカウントで実行するか、AWS 主催のイベントに登録して参加できます。

翻訳はソリューションアーキテクトの加治が担当しました。原文はこちらです。

Amazon Web Services ブログ