EKS Auto Mode が出た

Voicy で SRE してます。

2024年の AWS re:Invent は、開催前の発表が多くて、イベントで新たに発表することあるのかな？というくらい事前の発表が多かったですね。その re:Invent 開催中に発表された中で、EKSの大きな発表がありましたので、少しそれについて書いてみたいと思います。

ちなみに、Voicyでは EKS を使用してシステムを構築しています。
システムアーキテクチャは Findy Tools に掲載されていますので、ご参照ください。

EKS Auto Mode

Google Cloud の GKE には Autopilot という Kubernetes を自動で運用するシステムがありましたが、AWS EKS は、結構素のまま Kubernetes が提供されていて、ノードの運用自動化などはされていませんでした
そこに、EKS Auto Mode が発表されたわけです。AWS がコンピュート、ストレージ、ネットワーキングを自動的にプロビジョニング、最適化、更新するので、ユーザーはアプリケーション開発に集中できますよ、というものになります

EKS Auto Mode の特徴

• Kubernetes クラスタ管理の簡素化：運用上のオーバーヘッドを最小限に抑え、深い EKS 知識がなくても、要求の厳しい動的なワークロードを確実に実行できる
• アプリケーションの可用性：ワークロードの要求に応じて、EKS クラスタ内のノードを動的に追加または削除を行う。これにより、手動によるキャパシティプランニングの必要性が最小限に抑えられ、アプリケーションの可用性が確保される
• 効率性: NodePool およびワークロードの要件で定義された柔軟性を維持しながら、計算コストを最適化する。また、未使用のインスタンスを終了し、ワークロードを他のノードに統合してコスト効率を向上させる
• セキュリティ: ノードには、変更不可として扱われる AMI が使用される。これらの AMI は、ロックダウンされたソフトウェアを適用し、SELinux により強制アクセス制御を有効にし、読み取り専用のルートファイルシステムを提供する。さらに、EKS Auto Mode によって起動されたノードの最大寿命は 21 日（短縮可能）で、その後は自動的に新しいノードに置き換えらる。このアプローチにより、ノードを定期的に交換することでセキュリティ体制が強化され、多くの顧客がすでに採用しているベストプラクティスに沿ったものとなる
• 自動アップグレード: 設定された Pod Disruption Budget (PDB) および NodePool Disruption Budget (NDB) を尊重しながら、Kubernetes クラスタ、ノード、および関連コンポーネントを最新の修正プログラムで最新の状態に保つ
• マネージドコンポーネント: Kubernetes および AWS クラウドの機能をコアコンポーネントとして含んでいる。これらは、そうでなければアドオンとして管理する必要がある。これには、Pod IP アドレス割り当て、Pod ネットワークポリシー、ローカル DNS サービス、GPU プラグイン、ヘルスチェッカー、EBS CSI ストレージの組み込みサポートが含まれる
• カスタマイズ可能な NodePool と NodeClass: ワークロードでストレージ、コンピュート、またはネットワーク構成の変更が必要な場合は、EKS Auto Mode を使用してカスタム NodePool と NodeClass を作成可能。デフォルトの NodePool と NodeClass は編集できないが、特定の要件を満たすために、デフォルトの構成に加えて新しいカスタム NodePool または NodeClass を追加可能

EKS Auto Mode の仕組み

EKS Auto Mode は、主要なインフラストラクチャコンポーネントを自動化することで、Amazon EKS クラスタの運用を合理化します。EKS Auto Mode を有効にすることで、EKS クラスタを管理するためのタスクがさらに削減されます。

自動化されるデータプレーンコンポーネントは以下のとおりです。

コンピュート

EKS Auto Mode を使用すると、EKS クラスタのコンピュートの多くの側面を意識する必要がなくなります。これらには以下が含まれます

• ノード：EKS Auto Mode ノードは、アプライアンスとして扱われるように設計されている。EKS Auto Mode は以下を行う
  　■　介入なしにワークロードを実行するために必要な多くのサービスで構成された適切な AMI を選択する
  　■　SELinux 強制モードと読み取り専用のルートファイルシステムを使用して、これらの機能をロックダウン
  　■　SSH または SSM アクセスを許可しないことで、ノードへの直接アクセスを防ぐ
  　■　NVIDIA および Neuron GPU 用の個別のカーネルドライバとプラグインを含め、高性能ワークロードを可能にする GPU サポートが含まれる
• 自動スケーリング: Karpenter 自動スケーリングに依存する EKS Auto Mode は、スケジュールできない Pod を監視し、これらの Pod を実行するために新しいノードをデプロイできるようにする。ワークロードが終了すると、EKS Auto Mode は不要になったノードを動的に中断して終了し、リソースの使用を最適化する
• アップグレード: ノードの制御を引き継ぐことで、EKS Auto Mode は必要に応じてセキュリティパッチ、オペレーティングシステム、およびコンポーネントのアップグレードを合理化できる。これらのアップグレードは、ワークロードの中断を最小限に抑えるように設計されている。EKS Auto Mode は、最新のソフトウェアと API を確保するために、21 日間の最大ノード寿命を強制する

負荷分散

EKS Auto Mode は、Amazon の Elastic Load Balancing サービスと統合することで負荷分散を合理化し、Kubernetes サービスと Ingress リソースのロードバランサーのプロビジョニングと構成を自動化します。Application Load Balancer と Network Load Balancer の両方の高度な機能をサポートし、ライフサイクルを管理し、クラスタの需要に合わせてスケーリングします。この統合により、AWS のベストプラクティスに従った本番環境に対応した負荷分散ソリューションが提供されるため、インフラストラクチャ管理ではなくアプリケーションに集中できます

ストレージ

EKS Auto Mode は、ノードの終了時にボリュームタイプ、ボリュームサイズ、暗号化ポリシー、削除ポリシーを設定することで、エフェメラルストレージを構成します

ネットワーク

EKS Auto Mode は、Pod とサービスの接続のための重要なネットワークタスクを自動化します。これには、IPv4/IPv6 のサポートと、IP アドレス空間を拡張するためのセカンダリ CIDR ブロックの使用が含まれます

Identity and Access Management

EKS Auto Mode クラスタに EKS Pod Identity Agent をインストールする必要はありません

EKS Auto Mode の構成

EKS Auto Mode はほとんどのデータプレーンサービスを介入なしで効果的に管理しますが、これらのサービスの動作を変更したい場合があります。EKS Auto Mode クラスタの構成は、以下の方法で変更できます

• Kubernetes DaemonSet: ノードにインストールされているサービスを変更するのではなく、Kubernetes デーモンセットを使用できる。デーモンセットは Kubernetes によって管理されるように設計されているが、クラスタ内のすべてのノードで実行される。このようにして、ノードの監視やその他の監視のための特別なサービスを追加できる
• カスタム NodePool と NodeClass: デフォルトの NodePool と NodeClass は EKS Auto Mode によって構成され、編集できない。ノードの動作をカスタマイズするには、以下のようなユースケースに追加の NodePool または NodeClass を作成できる
  　○ 特定のインスタンスタイプ（例: アクセラレーテッドプロセッサまたは EC2 スポットインスタンス）の選択
  　○ セキュリティまたはコスト追跡の目的でワークロードを分離する
  　○ IOPS、サイズ、スループットなどのエフェメラルストレージ設定の構成
• 負荷分散: EKS Auto Mode が Kubernetes オブジェクトとして実行する負荷分散などの一部のサービスは、EKS Auto Mode クラスタで直接構成できる

EKS Auto Mode クラスタの作成

EKS Auto Mode クラスタは、AWS CLI、AWS マネジメントコンソール、または eksctl コマンドラインツールを使用して作成できます
※EKS Auto Mode では Kubernetes バージョン 1.29 以降が必要

• AWS マネジメントコンソールは、EKS Auto Mode の機能について学習し、個々のクラスタを作成するのに理想的なビジュアルインターフェイスを提供
• AWS CLI は、特にクラスタの作成を既存のワークフローまたは CI/CD パイプラインに統合する場合に、スクリプトと自動化タスクに最適
• eksctl CLI は Kubernetes ネイティブのエクスペリエンスを提供し、Kubernetes ツールに精通していて、適切なデフォルト設定を使用したシンプルなコマンドライン操作を希望するユーザーにお勧め

既存の EKS クラスタで EKS Auto Mode を有効にする

既存の EKS クラスタで EKS Auto Mode を有効にすることもできます
※EKS Auto Mode では Kubernetes バージョン 1.29 以降が必要

AWS は、以下の移行をサポートしています

• Karpenter から EKS Auto Mode ノードへの移行
• EKS マネージドノードグループから EKS Auto Mode ノードへの移行
• EKS Fargate から EKS Auto Mode ノードへの移行

AWS は、以下の移行をサポートしていません

• EBS CSI コントローラから EKS Auto Mode ブロックストレージへのボリュームの移行
• AWS Load Balancer Controller から EKS Auto Mode へのロードバランサーの移行
• 代替 CNI またはその他のサポートされていないネットワーク構成を使用した EKS クラスタの移行

制限事項

EKS Auto Mode には、いくつかの制限事項があります

• EKS Auto Mode では Kubernetes バージョン 1.29 以降が必要
• EKS Auto Mode は、Windows ノードをサポートしていない
• EKS Auto Mode は、AWS Fault Injection Service をサポートしていない
• EKS Auto Mode は、代替 CNI プラグインまたはネットワークポリシープラグインをサポートしていない
• EKS Auto Mode は、Amazon Application Recovery Controller、ゾーンシフト、およびゾーンオートシフトをサポートしていない

参照

• Amazon EKS User Guide

あとがき

ノードを勝手に管理してくれるのは、すごく便利そうなのですが、どういうノードが選択されるかとかはAWS側お任せになってしまうので、そのあたりは運用がどうなっているかにもよりそうです。とはいえ、運用が面倒という EKS なので、そういう意味ではかなり運用が楽になる予感はあります。Voicyでも検討していきたいなとは思います。