Amazon EKS Auto Mode を始めよう

この記事は Getting started with Amazon EKS Auto Mode (記事公開日: 2024 年 12 月 3 日) を翻訳したものです。

この記事は、Alex Kestner (Amazon EKS シニアプロダクトマネージャー) 、Ashley Ansari (シニアプロダクトマーケティングマネージャー) 、Robert Northard (コンテナプリンシパル GTM SSA) 、Sheetal Joshi (コンテナプリンシパルソリューションアーキテクト) の共著です。

はじめに

Kubernetes クラスターにおけるコンピューティング、ストレージ、ネットワーキングを効率的に管理する新機能、Amazon Elastic Kubernetes Service (Amazon EKS) Auto Mode の一般提供を発表しました。この機能により、クラスターを迅速に構築し、パフォーマンスを向上させ、管理の手間を減らすことができます。クラスター管理を AWS に任せることで、アプリケーションの構築に集中してイノベーションの推進に注力いただけます。

Amazon EKS Auto Mode は、インフラストラクチャの自動プロビジョニング、最適なコンピューティングインスタンスの選択、リソースの動的スケーリング、コスト最適化のために継続的なコンピューティングの最適化、オペレーティングシステム (OS) のパッチ適用、AWS セキュリティサービスとの統合により、Kubernetes クラスター管理を効率化します。有効にすると、EKS Auto Mode は AWS のベストプラクティスに基づいてクラスター機能を設定し、アプリケーションのデプロイに最適な状態でクラスターを準備します。

この記事では、EKS Auto Mode の高レベルアーキテクチャを紹介し、EKS Auto Mode を使用して高可用性かつ自動スケーリング機能を備えたサンプルアプリケーションをデプロイする手順を紹介します。

新機能の紹介

Amazon EKS は長らく、Kubernetes を実行するための安全な方法として信頼されてきました。EKS Auto Mode 以前は、マネージドのコントロールプレーンがあるにもかかわらず、本番環境相当の Kubernetes アプリケーションを実行するために必要なインフラストラクチャを管理するには、専門的な知識と継続的な労力が求められていました。具体的には、ユーザーはリソース効率とコストを最適化するための適切な Amazon Elastic Compute Cloud (Amazon EC2) インスタンスの選択とプロビジョニングから、プラグインのインストールとメンテナンスまで、継続的なメンテナンス活動を行わなければなりませんでした。以下の図に示すように、インフラのセキュリティと最新性を維持するため、クラスターのアップグレードや OS のパッチ適用も並行して管理しなければなりませんでした。

Before Auto Mode

EKS Auto Mode によるクラスター運用の完全自動化は、本番環境レベルの Kubernetes インフラ管理に必要な専門知識の依存度を大幅に低減し、ユーザーの時間と労力を大きく節約します。EC2 インスタンスの選定やプロビジョニング、リソースとコストの最適化、プラグインのメンテナンスといった作業にユーザーが時間とリソースを費やす必要がなくなりました。

EKS Auto Mode を有効にして新規に EKS クラスターを作成するか、既存のクラスターを更新すると、Amazon EKS は自動的に必要な処理を行います。具体的には、コンピューティング、ネットワーキング、ストレージ機能に必要なコントローラーを、Amazon EKS 専用の AWS アカウントと VPC 内にデプロイします。これはマネージドな Kubernetes コントロールプレーンと併せて実施されます。

アプリケーションのデプロイ時には、EKS Auto Mode が自動的に Bottlerocket OS ベースの EC2 インスタンスと Elastic Load Balancing (ELB) を起動し、ユーザーの AWSアカウントと指定された VPC 内に Amazon EBS ボリュームをプロビジョニングします。さらに、これらの EC2 インスタンスのライフサイクル管理、実行時のアプリケーション要件に応じたデータプレーンのスケーリングと最適化、不健全なノードの自動置換を行います。下図が示すように、EKS Auto Mode は、Amazon EC2 の豊富な機能や柔軟性を損なうことなく、管理されたインフラストラクチャを提供します。

After Auto Mode

EKS Auto Mode の導入により、これまで Kubernetes DaemonSet として動作していたノード管理機能が、AWS が管理するシステムプロセスとして実行できるようになりました。具体的には、サービスディスカバリー、ロードバランシング、Pod ネットワーキング、ブロックストレージ、認証情報の提供などの機能が含まれます。AWS がこれらのコンポーネントのライフサイクル管理を担当し、セキュリティ更新を行い、最新のコンポーネントを組み込んだ EKS Auto Mode 用の Amazon Machine Image (AMI) を定期的にリリースします。

また、EKS Auto Mode はクラスターのアップグレードと OS の更新を自動的に行います。この際、ユーザーが定義した Kubernetes のスケジューリング制約を考慮しながら、ノードを段階的に置き換えることで、インフラのセキュリティと最新性を維持します。これにより運用の負担が大幅に軽減され、開発チームはインフラ管理ではなく、アプリケーション開発に注力できるようになります。

はじめ方

EKS Auto Mode は、Kubernetes バージョン 1.29 以降を実行している新規および既存の EKS クラスターで利用可能になりました。EKS Auto Mode を始めるには、新しいコンソール機能 [Quick Configuration (クイック設定) ]が便利です。この機能を使えば、最適なデフォルト設定が予め構成されたクラスターをワンクリックで迅速に立ち上げることができます。あるいは、Amazon EKS API、AWS マネジメントコンソールのカスタム設定、 eksctl、お好みの Infrastructure as code (IaC) ツールを使用することも可能です。

このセクションでは、EKS Auto Mode が Amazon EKS 上でのアプリケーションデプロイをいかに簡素化するかを実際に示します。まず、EKS Auto Mode を有効にして EKS クラスターを作成し、その後サンプルの小売店アプリケーションをデプロイします。EKS Auto Mode が新しいノードを自動的に起動し、AWS Load Balancer をセットアップし、永続的なストレージ要件を管理し、アプリケーションの自動スケーリングニーズを処理する様子をご覧いただけます。

事前準備

本記事で紹介する手順を実行するには、以下の準備が必要です：

AWSアカウント：管理者権限を持つAWSアカウントをお持ちであることを前提としています。
以下のツールをインストールしてください：Helm 3.9+、kubectl、eksctl、AWS Command Line Interface (AWS CLI)

クラスターの作成

本記事では、EKS クラスターを簡単に作成できるコマンドラインツールである eksctl を使用します。以下に示す設定例では、eksctl を使ってクラスターインフラストラクチャとアプリケーションデプロイ用のサブネットを自動生成します。もしこのサンプル設定を使用しない場合は、Amazon EKS ユーザーガイドに記載されている前提条件を全て確認してください。特に、クラスター IAM ロールとノード IAM ロールの変更が必要となります。これらの変更により、EKS Auto Mode がユーザーのアカウント内で EC2 インスタンスを管理するための新しい権限が付与されます。

今回のセットアップでは、あらかじめ用意されている general-purpose (汎用) ワークロードとsystem (システム) ワークロード用のマネージドな NodePool を使用して EKS Auto Mode を有効化します。general-purpose NodePool は汎用的なワークロードの起動をサポートし、system NodePool はアドオンを処理します。両方とも、C、M、R ファミリーの amd64 アーキテクチャを持つオンデマンド EC2 インスタンス (第5世代以降) を使用します。マネージドな NodePool の詳細については、EKS Auto Mode ユーザーガイドを参照してください。

cat << EOF > cluster.yaml 
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
  name: eks-auto-mode-demo
  region: us-west-2
  version: "1.31"
  
addonsConfig:
  disableDefaultAddons: true

autoModeConfig:
  enabled: true
  nodePools: ["general-purpose", "system"]
  
EOF

eksctl create cluster -f cluster.yaml

クラスターの状態が Active になるまでお待ちください。

aws eks describe-cluster --name eks-auto-mode-demo --output json --query 'cluster.status'

これでクラスターの準備が整い、アプリケーションをデプロイできる状態になりました。次のセクションでは、EKS Auto Mode を使用することで、アプリケーションのデプロイがいかに簡素化されるかを実際に見ていきましょう。

アプリケーションのデプロイ

今回使用するサンプルアプリケーションは、オンラインショッピングの機能を模しています。ユーザーは商品カタログを閲覧し、商品をカートに追加し、チェックアウトプロセスを経て注文を完了することができます。このアプリケーションは、UI、カタログサービス、注文サービス、カートサービス、チェックアウトサービスなど、複数のコンポーネントで構成されています。また、永続的なストレージを必要とするバックエンドデータベースも含まれています。これらのコンポーネントは、Kubernetes の Deployment と StatefulSet を用いて実装されています。アプリケーションへのアクセスには、Kubernetes Ingress を使用してクラスター外からのアクセスを可能にします。また、カタログアプリケーションにはAmazon EBS 永続ストレージを使用するよう設定します。
EKS Auto Mode のパフォーマンス向上、スケーラビリティ、可用性の強化を実証するため、UI アプリケーションには特別な設定を行います。具体的には、Horizonal pod Autoscaling (HPA)、Pod Topology Spread Constraints、Pod Disruption Budgets (PDB) をサポートするよう構成します。これらの設定により、EKS Auto Mode がもたらす利点を具体的に示すことができます。

アプリケーションのデプロイに進む前に、まずはクラスターの状態を確認しておきましょう。

kubectl get nodes
kubectl get pods

現時点では、ノードと Pod のリストが空であることが確認できました。

アプリケーションのデプロイに進む前に、StorageClass とIngressClass を作成します。これらの設定は、後ほどデプロイするアプリケーションが必要とするストレージと Ingress の要件を満たすための基盤となります。一般的に、この作業はクラスター作成直後にプラットフォームチームが一度だけ実施するものです。この設定を行うことで、アプリケーションのデプロイがスムーズに進み、必要なリソースがすぐに利用可能になります。

cat >ingress.yaml <<EOF
---
apiVersion: eks.amazonaws.com/v1
kind: IngressClassParams
metadata:
  name: eks-auto-alb
spec:
  scheme: internet-facing
---
apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
  name: eks-auto-alb
spec:
  controller: eks.amazonaws.com/alb
  parameters:
    apiGroup: eks.amazonaws.com
    kind: IngressClassParams
    name: eks-auto-alb
EOF

kubectl apply -f ingress.yaml
cat >ebs-sc.yaml <<EOF
---
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: eks-auto-ebs-csi-sc
  annotations:
    storageclass.kubernetes.io/is-default-class: "true"
provisioner: ebs.csi.eks.amazonaws.com
volumeBindingMode: WaitForFirstConsumer
parameters:
  type: gp3
EOF
 
kubectl apply -f ebs-sc.yaml

アプリケーションのデプロイには Helm を使用します。まず、先ほど説明したアプリケーションの要件を指定するための values.yaml ファイルを作成しましょう。

cat >values.yaml <<EOF
catalog:
  mysql:
    secret:
      create: true
      name: catalog-db
      username: catalog
    persistentVolume:
      enabled: true
      accessMode:
        - ReadWriteOnce
      size: 30Gi
      storageClass: eks-auto-ebs-csi-sc

ui:
  endpoints:
    catalog: http://retail-store-app-catalog:80
    carts: http://retail-store-app-carts:80
    checkout: http://retail-store-app-checkout:80
    orders: http://retail-store-app-orders:80
    assets: http://retail-store-app-assets:80
  autoscaling:
    enabled: true
    minReplicas: 5
    maxReplicas: 10
    targetCPUUtilizationPercentage: 80
  topologySpreadConstraints:
  - maxSkew: 1
    topologyKey: topology.kubernetes.io/zone
    whenUnsatisfiable: ScheduleAnyway
    labelSelector:
      matchLabels:
        app: ui
  - maxSkew: 1
    topologyKey: kubernetes.io/hostname
    whenUnsatisfiable: ScheduleAnyway
    labelSelector:
      matchLabels:
        app: ui
  ingress:
    enabled: true
    className: eks-auto-alb
EOF

それでは、小売店アプリケーションのデプロイを行いましょう。デプロイを進める際は、values.yaml ファイルの設定内容に注意を払ってください。特に重要なのは、UI のエンドポイントの設定です。もし、デフォルトの retail-store-app とは異なるチャート名を使用している場合は、必ずエンドポイントの設定を適切に更新してください。

helm install -f values.yaml retail-store-app oci://public.ecr.aws/aws-containers/retail-store-sample-chart --version 0.8.3

EKS Auto Mode は、デプロイされた Pod のリソース要求を分析し、アプリケーションの実行に最適なコンピューティングリソースを判断します。この過程で、ユーザーが設定したスケジューリング制約 (トポロジー分散制約を含む) が考慮されます。EKS Auto Mode は general-purpose のマネージド NodePool を利用してノードを起動します。ノードがReadyになるまで待ちます。

kubectl wait --for=condition=Ready nodes --all

別のターミナルで、アプリケーションが使用可能な状態になるのを監視します。

kubectl wait --for=condition=available deployments --all

小売店アプリケーションのコンポーネントは実行中の状態になっているはずです。

catalog-mysql-ebs StatefulSetを調べると、EKS Auto Mode が 30 GiB の PersistentVolumeClaim を作成し、storageClassName が eks-auto-ebs-csi-sc であることがわかります。

kubectl get statefulset retail-store-app-catalog-mysql \
  -o jsonpath='{.spec.volumeClaimTemplates}' | jq .
  
Output:
[
  {
    "apiVersion": "v1",
    "kind": "PersistentVolumeClaim",
    "metadata": {
      "creationTimestamp": null,
      "name": "data"
    },
    "spec": {
      "accessModes": [
        "ReadWriteOnce"
      ],
      "resources": {
        "requests": {
          "storage": "30Gi"
        }
      },
      "storageClassName": "eks-auto-ebs-csi-sc",
      "volumeMode": "Filesystem"
    }
  }
]

EKS Auto Mode は UI アプリケーション用に Application Load Balancer (ALB) を自動的に作成しました。以下のコマンドで ALB 名を確認できます。ALB の準備ができたら、ウェブブラウザでそのリンクにアクセスできます。小売店のホームページが表示されるはずです。

kubectl get ingress retail-store-app-ui -o jsonpath="{.status.loadBalancer.ingress[*].hostname}{'\n'}"

Output:
k8s-ui-uinlb-1111111111.elb.us-west-2.amazonaws.com

アプリケーションのスケーリング

アプリケーションのデプロイが完了したので、次は EKS Auto Mode によるスケーリング機能を見ていきましょう。EKS Auto Mode は HorizontalPodAutoscaler(HPA) と metrics-server を活用して、アプリケーションの需要に応じてクラスターのリソースを自動的に調整します。Kubernetes では、HPA は観測されたメトリクスに基づいて Deployment のレプリカ数を自動的に調整します。Metrics server は kubelet から CPU とメモリ使用量を収集し、Kubernetes API サーバーを通じて HPA に公開します。HPA はこれらのメトリクスを継続的に監視し、指定されたターゲットに一致するようにレプリカ数を調整します。

まず、Kubernetes metrics-server をデプロイします。

kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml

この例では、UI サービスを使用し、CPU 使用率 (80 %) に基づいてスケーリングし、maxReplicas を 10 に設定します。なお、HPA の設定はアプリケーションのインストール時にすでに適用されています。具体的な設定内容は、 values.yaml ファイルの AutoScaling セクションで確認できます。現在の AutoScaling ポリシーは、以下のコマンドで確認することができます。

kubectl get hpa retail-store-app-ui

次に、設定した AutoScaling ポリシーがどのように機能するかを確認するため、負荷をかけてみましょう。これにより、EKS Auto Mode がクラスターのインフラストラクチャをどのようにスケールアウトするかを実際に観察できます。

kubectl run load-generator \
--image=public.ecr.aws/amazonlinux/amazonlinux:2023 \
--restart=Never -- /bin/sh -c "while sleep 0.01; do curl http://retail-store-app-ui/home; done"

アプリケーションに対してリクエストが発生しているので、この負荷に応じて EKS Auto Mode がどのように対応するか観察しましょう。新しいノードが起動し、UI Pod の数が増加する様子を確認できるはずです。

kubectl get nodes --watch

Output:
NAME STATUS ROLES AGE VERSION
i-00018eaec7a3d5370 Ready <none> 155m v1.31.0-eks-672e808
i-043c71a371a8514a1 Ready <none> 155m v1.31.0-eks-672e808

HPA リソースを監視して、その進行状況を追跡できます。

kubectl get hpa retail-store-app-ui --watch


Output:
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
retail-store-app-ui Deployment/retail-store-app-ui cpu: 158%/80% 3 10 5 16m
retail-store-app-ui Deployment/retail-store-app-ui cpu: 161%/80% 3 10 6 16m
retail-store-app-ui Deployment/retail-store-app-ui cpu: 148%/80% 3 10 9 16m

ご覧の通り、EKS Auto Mode はアプリケーションの需要に基づいてクラスターインフラストラクチャを完全に管理し、動的にスケーリングします。Pod を終了させることで、負荷テストを停止できます。負荷生成の Pod が終了すると、HPAは設定に基づいてレプリカ数を徐々に最小数まで減らしていきます。

kubectl delete pod load-generator

主要な考慮事項

Amazon EKS Auto Mode でワークロードを展開する際に考慮すべき主なポイントは以下の通りです：

Pod Disruption Budgets を設定し、自発的な中断からワークロードを保護する：EKS Auto Mode が使用率の低いノードを停止させるような自発的な中断時に、Pod Disruption Budgets は Deployment のレプリカが中断される割合を制御し、一定のワークロード容量を維持してサービスの継続性を確保します。
高可用性を実現するため、レプリカをノードとアベイラビリティーゾーン間に分散させる：Pod トポロジー分散制約を使用してワークロードをノード間に分散させ、同じノード上で Deployment の複数のレプリカが実行される可能性を最小限に抑えます。
適切なリソース要求と制限を設定する：EKS Auto Mode はワークロードの vCPU とメモリ要求に基づいて EC2 インスタンスを起動します。リソースの過剰プロビジョニングを避けるため、リソース要求は慎重に設定する必要があります。EKS Auto Mode はリソース制限や実際の使用量を考慮しないことに注意してください。
アプリケーションは正常なシャットダウン処理を実装する：自発的な中断の間に作業の損失やユーザー体験の中断を防ぐため、アプリケーションは SIGTERM シグナルを適切に処理して正常にシャットダウンできる必要があります。Kubernetesが Pod の退避を決定すると、退避対象 Pod の各コンテナのメインプロセスに SIGTERM シグナルが送信されます。その後、SIGKILL が送信されるまでの猶予期間 (デフォルトは 30 秒) が設けられます。この猶予期間は Pod 仕様の terminationGracePeriodSeconds で変更可能です。
コンピューティングリソースの選択に過度な制約を設けない：general-purpose の NodePool は、c、m、r 系の EC2 インスタンスを様々なサイズで利用し、ワークロードに最適なインスタンスを選択する柔軟性を確保しています。特定のコンピューティング要件がある場合は、 Kubernetes の well-known Label を使用して、特定のインスタンスタイプやアーキテクチャなどの属性を指定できます。

アプリケーションのベストプラクティスについて詳しく知りたい場合は、Amazon EKS ベストプラクティスガイドの信頼性セクションを参照してください。

リソースの削除

不要な料金が発生しないよう、この記事で作成したリソースを以下の手順で削除してください：

kubectl delete deploy -n kube-system metrics-server

helm uninstall retail-store-app

kubectl delete pvc/data-retail-store-app-catalog-mysql-0

eksctl delete cluster —name eks-auto-mode-demo

結論

Amazon EKS Auto Mode は、コンピューティング、ストレージ、ネットワーキングの機能をすぐに利用できる形で提供し、アプリケーションデプロイの複雑さを大幅に軽減します。新規クラスターの作成時でも既存クラスターの更新時でも、EKS Auto Mode は効率的な体験を提供します。クラスターインフラの管理だけでなく、Kubernetes の標準に準拠しながら、核となるクラスター機能も提供します。

EKS Auto Mode は、既存の Amazon EKS サービスを補完し、多様なワークロードに対応する柔軟性を提供します。特定の要件がある場合、ユーザーは従来の Amazon EKS コンピューティングオプションを引き続き利用できます。これにより、Kubernetes クラスターのカスタム設定、クラスターインフラの手動プロビジョニングと管理、Kubernetes 環境の詳細な制御が可能です。Auto Mode と従来のオプションの両方をサポートすることで、Amazon EKS は幅広いニーズに対応します。簡素化と運用負荷の軽減を求めるユースケースから、Kubernetes 環境のカスタマイズや詳細な制御が必要なケースまで、様々な要求に応えることができます。

EKS Auto Mode の機能について詳しくは、Amazon EKS のドキュメントをご覧ください。EKS Auto Mode の実際の動作を確認し、AWS の専門家に質問する機会を得るには、今後のウェビナーシリーズ「Simplifying Kubernetes operations with Amazon EKS Auto Mode」にご登録ください。

翻訳はクラウドサポートエンジニアの桐生が担当しました。原文はこちらです。

Amazon Web Services ブログ