Amazon EKS の高度な Kubernetes コントロールプレーン設定の紹介

この記事は Introducing advanced Kubernetes control plane configuration in Amazon EKS (記事公開日: 2026 年 8 月 12 日) を翻訳したものです。

大規模な Amazon Elastic Kubernetes Service (Amazon EKS) クラスターを運用するお客様は、リソースの使用率を高めてコンピューティングコストを下げるために、Pod の配置戦略を最適化したいと考えています。入れ替わりの激しいバッチ、継続的インテグレーションと継続的デリバリー (CI/CD)、AI と機械学習 (AI/ML) のワークロードを実行するチームは、etcd のストレージの逼迫を抑えるために、イベントの保持期間などのリソースのライフサイクル管理の設定をカスタマイズしたいと考えています。また、セルフマネージドの Kubernetes から移行するお客様は、長年調整してきたスケジューラの設定を引き継ぎたいと考えています。これまで、こうしたニーズの多くに応えるには独自の仕組みを構築して維持する必要があり、運用オーバーヘッドとメンテナンスの負担が増えていました。2026 年 8 月に、Amazon EKS は高度な Kubernetes コントロールプレーン設定の提供を開始しました。API サーバー、スケジューラ、コントローラーマネージャーのパラメータを、Amazon EKS で直接設定できるようになりました。Amazon EKS の可用性とパフォーマンス特性は、これまでと変わりません。

この記事では、この機能の概要とサポートされているパラメータを説明したうえで、2 つのウォークスルーで実際に試します。まず、MostAllocated スコアリング戦略を使って、デフォルトの分散配置よりもリソースの使用率を優先するように Pod の配置戦略を設定します。次に、デバッグのしやすさとストレージの効率のバランスを取るように、イベントの保持期間を設定します。

設定できる項目

スケジューラのカスタマイズでは、Pod の配置戦略を設定して、Pod のスケジューリングでノードをどのようにスコアリングするかを制御できます。デフォルトでは、Kubernetes スケジューラは LeastAllocated スコアリング戦略を使います。この戦略は、可用性を重視して、リソースの割り当てが少ないノードを優先します。MostAllocated スコアリング戦略は、すでに割り当てが多いノードを優先し、リソースの使用率を最適化します。MostAllocated 戦略では、使用率がすでに高いノードに Pod を詰め込むので、同じワークロードをより少ないノードで実行できます。その結果、コンピューティングコストが下がり、クラスター内で一部しか使われていないインスタンスが減ります。

コントローラーマネージャーの設定では、Horizontal Pod Autoscaler (HPA) がスケーリングを判断する頻度を制御できます。同期間隔を短くすると、HPA コントローラーがメトリクスを評価して対応する頻度が上がるので、負荷が増えてからワークロードがスケールアウトするまでの時間が短くなります。Amazon EKS Provisioned Control Plane のクラスターでは、最近の改善で HPA の同期の同時実行数が Kubernetes のデフォルト値の最大 40 倍に引き上げられていて (発表)、同期間隔の設定と組み合わせて使えます。同時実行数の引き上げと同期間隔の短縮によって、HPA コントローラーはより多くのスケーリングイベントを並列に処理し、ワークロードの需要の変化にすばやく対応できます。その結果、Pod のオートスケーリングが速くなり、需要の変化への応答性が高まります。

API サーバーでは、イベントの保持期間を設定して、デバッグのしやすさとストレージの効率のバランスを取れます。バッチパイプライン、CI/CD ランナー、AI/ML ジョブなど、Pod の入れ替わりが激しいクラスターでは、大量の Kubernetes イベントが生成されます。これらのイベントは etcd の領域を消費し、クラスターの動作に必要なオブジェクトと領域を奪い合います。保持期間を短くすると、こうした短期間しか使わない診断データが早く消去されるので、etcd のデータ量を抑え、list と watch のリクエストを速くできます。一方、保持期間を長くすると、チームがトラブルシューティングに使える履歴が増えます。また、NodePort タイプの Service に割り当てるポート番号の範囲を変更して、ポートの割り当てを組織のネットワークとファイアウォールのポリシーに合わせたり、NodePort タイプの Service を多数実行するクラスターで範囲をデフォルトより広げたりすることもできます。この設定は移行の際に役立ちます。レガシーアプリケーションとその呼び出し元のクライアントは、特定の固定ポートでサービスが提供されることを前提にしていることがよくあります。それらのポートが Kubernetes のデフォルトの範囲外にある場合、通常はアプリケーションを変更するか、アプリケーションの前に外部のプロキシを立てる必要があります。範囲をアプリケーションがすでに使っているポートに合わせれば、その作業が不要になり、アプリケーションを書き直したり、保守が必要なネットワークコンポーネントを追加したりせずに、ワークロードを Amazon EKS に移行できます。

提供開始時にサポートされるパラメータ

次の表に、提供開始時に使用できるパラメータをまとめます。サポートされている値と範囲を含む全一覧は、Amazon EKS のドキュメントをご覧ください。

コンポーネント	パラメータ	制御する内容
kube-scheduler	nodeResourcesFit.scoringStrategy	リソースの割り当てに基づいてノードをスコアリングし、Pod の配置戦略を設定します。MostAllocated はすでに割り当てが多いノードを、LeastAllocated は使用可能なリソースが多いノードを優先します。cpu、memory、アクセラレーター (nvidia.com/gpu、aws.amazon.com/neuron、aws.amazon.com/neuroncore) に、リソースごとの重み (1～100) を指定できます。
kube-controller-manager	horizontalPodAutoscalerControllerConfig.horizontalPodAutoscalerSyncPeriod	アプリケーションの要件に合わせて、HPA がメトリクスを評価してスケーリングを判断する頻度 (10～15 秒) を設定します。
kube-apiserver	eventTtl	デバッグのしやすさと etcd のストレージの効率のバランスを取るように、イベントの保持期間 (10～60 分) をカスタマイズします。
kube-apiserver	serviceNodePortRange	NodePort タイプの Service に割り当てるポート番号の範囲 (10260～32767) を定義します。アプリケーションを変更せずにレガシーシステムを移行できます。

注: horizontalPodAutoscalerSyncPeriod パラメータを使うには、Amazon EKS Provisioned Control Plane が必要です。Provisioned Control Plane は、負荷の高いワークロードに常に対応できるコントロールプレーンのキャパシティを事前に割り当て、追加の負荷を吸収できるサイズを確保します。

これらはクラスター全体の設定で、クラスターで実行されるワークロードに適用されます。前の表は、お客様の要望に基づいて選んだ、最初にサポートするパラメータの一覧です。他に設定したいパラメータがあれば、AWS Containers Roadmap でお知らせください。

前提条件

このウォークスルーを実施するには、次のものが必要です。

AWS アカウント
Kubernetes バージョン 1.31 以降を実行している Amazon EKS Auto Mode クラスター
手元のデバイスで設定済みの最新バージョンの AWS コマンドラインインターフェイス (AWS CLI)、または AWS CloudShell
クラスターと通信できるように設定した kubectl
Amazon EKS クラスターの情報の取得と更新、クラスターへのワークロードのデプロイを行うアクセス許可を持つ AWS Identity and Access Management (IAM) プリンシパル

まず、クラスター名と AWS リージョンを設定します。

export CLUSTER=my-eks-cluster
export AWS_REGION=us-west-2

ウォークスルー 1: MostAllocated スコアリング戦略による Pod の配置の最適化

このウォークスルーでは、既存のクラスターで MostAllocated スコアリング戦略を設定し、Kubernetes スケジューラが新しい Pod を、使用可能なリソースが多いノードではなく、すでに割り当てが多いノードに配置する様子を確認します。高度な Kubernetes コントロールプレーン設定を使えば、この戦略を Amazon EKS クラスターで直接設定できるので、カスタムスケジューラを維持する運用の負担がなくなります。

ステップ 1. ノードの使用率に偏りのあるクラスターを用意する

この例では、Pod の数に関係なく一定数のノードを維持するために、静的キャパシティのノードプールを設定した Amazon EKS Auto Mode クラスターを使います。静的キャパシティのノードプールは、予測可能なキャパシティやリザーブドインスタンスが必要なワークロードや、インフラストラクチャの規模を一定に保つことが求められるコンプライアンス要件のあるワークロードに役立ちます。ノードプールを作成します。

cat <<EOF | kubectl apply -f -
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: demo-static
spec:
  replicas: 2
  template:
    spec:
      nodeClassRef:
        group: eks.amazonaws.com
        kind: NodeClass
        name: default
      requirements:
        - key: "node.kubernetes.io/instance-type"
          operator: In
          values: ["m5.large"]
  limits:
    nodes: 2
EOF
kubectl wait --for=condition=Ready nodes --all --timeout=180s

両方のノードの準備ができたら、サイズの異なるワークロードをデプロイして、割り当てに偏りを作ります。

# 1 つのノードで重いワークロードを実行する (ノードのキャパシティの大半を使う)
cat <<EOF | kubectl apply -f -
apiVersion: apps/v1
kind: Deployment
metadata:
  name: heavy-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: heavy-app
  template:
    metadata:
      labels:
        app: heavy-app
    spec:
      nodeSelector:
        karpenter.sh/nodepool: demo-static
      containers:
        - name: pause
          image: registry.k8s.io/pause:3.9
          resources:
            requests:
              cpu: 1500m
              memory: 1Gi
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: light-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: light-app
  template:
    metadata:
      labels:
        app: light-app
    spec:
      nodeSelector:
        karpenter.sh/nodepool: demo-static
      containers:
        - name: pause
          image: registry.k8s.io/pause:3.9
          resources:
            requests:
              cpu: 500m
              memory: 512Mi
EOF
kubectl wait --for=condition=Ready pods --all --timeout=120s

次のコマンドで、各ノードのリソースの割り当てを確認します。スケジューラは、スコアリングの判断に (実際の使用量ではなく) リソースの要求量を使います。

kubectl get pods -o wide
kubectl describe nodes -l karpenter.sh/nodepool=demo-static | grep -A 5 "Allocated resources"

Node: i-0b3a5fb6f3823fd2f
Allocated resources:
  CPU Requests: 1500m (84%)
  Memory Requests: 1Gi (14%)
Node: i-08c2daa17b2fbe865
Allocated resources:
  CPU Requests: 500m (28%)
  Memory Requests: 512Mi (7%)

ノード A (i-0b3a5fb6f3823fd2f) は CPU の 84% が割り当てられています。ノード B (i-08c2daa17b2fbe865) は 28% だけです。kube-scheduler は、ノードをスコアリングするときに、この割り当ての差を使います。

ステップ 2. デフォルトの配置 (LeastAllocated) を確認する

新しい Pod をデプロイして、スケジューラがどのノードに配置するかを確認します。

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: test-pod
spec:
  nodeSelector:
    karpenter.sh/nodepool: demo-static
  containers:
    - name: pause
      image: registry.k8s.io/pause:3.9
      resources:
        requests:
          cpu: 200m
          memory: 128Mi
EOF
kubectl wait --for=condition=Ready pods --all --timeout=120s
kubectl get pods -o wide

NAME       READY   STATUS    NODE
test-pod   1/1     Running   i-08c2daa17b2fbe865

LeastAllocated では、スケジューラは使用可能なリソースが多いノードを優先し、Pod をノード B (CPU 28%、メモリ 7% が割り当て済み) に配置しました。先に進む前に、このテスト用の Pod を削除します。

kubectl delete pod test-pod

ステップ 3. MostAllocated スコアリング戦略を有効にする

既存のクラスターにスケジューラの設定を適用します。

aws eks update-cluster-config \
  --name "$CLUSTER" \
  --kube-scheduler-config '{
    "nodeResourcesFit": {
      "scoringStrategy": {
        "type": "MostAllocated"
      }
    }
  }'

注: 必要に応じて、カスタムの重みを指定した resources 配列を指定し、スコアリングの判断でどのリソースを重視するかを調整できます。サポートされているリソースは cpu、memory、nvidia.com/gpu、aws.amazon.com/neuron、aws.amazon.com/neuroncore で、重みは 1～100 です。

レスポンスとして、進行状況を追跡できる更新の情報が返されます。

{
  "update": {
    "id": "a1b2c3d4-5678-90ab-cdef-EXAMPLE11111",
    "status": "InProgress",
    "type": "ControlPlaneComponentConfigUpdate"
    ...
  }

Amazon EKS は、他のクラスターの更新と同様に、コントロールプレーンの設定の更新を非同期に適用します。更新が完了するまで待ちます。

aws eks wait cluster-active --name "$CLUSTER"

このコマンドは、クラスターが Active ステータスに戻るまで待機します。通常は数分以内に戻ります。

ステップ 4. 新しい配置 (MostAllocated) を確認する

これで、新しいスケジューリングの判断には MostAllocated が使われます。別のテスト用の Pod をデプロイして、どのノードに配置されるかを確認します。

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: test-pod
spec:
  nodeSelector:
    karpenter.sh/nodepool: demo-static
  containers:
    - name: pause
      image: registry.k8s.io/pause:3.9
      resources:
        requests:
          cpu: 200m
          memory: 128Mi
EOF
kubectl wait --for=condition=Ready pods --all --timeout=120s
kubectl get pods -o wide

NAME       READY   STATUS    NODE
test-pod   1/1     Running   i-0b3a5fb6f3823fd2f

MostAllocated では、スケジューラは、すでにリソースの割り当てが多いノード A (CPU 84%、メモリ 14% が割り当て済み) を優先するようになりました。ノードアフィニティ、Taint と Toleration、トポロジー分散制約など、独自のスケジューリング要件を指定した Pod では、引き続きその要件が優先され、スケジューラはそれに従います。この詰め込む動作によって、時間がたつにつれて、使用率の低いノードには新しいワークロードが配置されなくなり、統合 (consolidation) に対応したノードプールでは、それらのノードを統合できるようになります。ポイントは、カスタムスケジューラを使わずに、1 回の API コールでクラスター全体のスケジューリング戦略を変更できたことです。

ウォークスルー 2: eventTtl によるイベントの保持期間の設定

Kubernetes は、Pod のスケジューリングの判断、イメージのプル、ヘルスチェックの失敗、スケーリングのアクションなどのクラスターのアクティビティを記録するために、イベントを etcd データベースに保存します。アップストリームのデフォルトでは、イベントは 1 時間保持されます。大規模なバッチジョブ、機械学習 (ML) のトレーニング、CI/CD パイプライン、大規模な CronJob など、入れ替わりの激しいワークロードを実行するクラスターでは、数千のイベントがすぐに蓄積します。etcd 内のイベントが増えると、ストレージが逼迫し、API サーバーの list 処理が遅くなるおそれがあります。

高度な Kubernetes コントロールプレーン設定では、デバッグのしやすさとストレージの効率のバランスを取るように、イベントの保持期間を調整できます。このウォークスルーでは、eventTtl をデフォルトの 1 時間から 15 分に短縮します。

ステップ 1. eventTtl を 15 分に短縮する

API サーバーの設定を適用します。

aws eks update-cluster-config \
  --name "$CLUSTER" \
  --kube-api-server-config '{
    "eventTtl": "15m"
  }'

更新が完了するまで待ちます。

aws eks wait cluster-active --name "$CLUSTER"

ステップ 2. 短縮の効果を確認する

新しい eventTtl の設定は、設定の変更が反映された後に Kubernetes が作成するイベントに適用されます。既存のイベントは元の保持期間を維持し、その期間に従って期限切れになります。保持期間が短くなったことを確かめるために、新しい Pod を作成して、その Pod のイベントを確認します。

kubectl run ttl-test --image=registry.k8s.io/pause:3.9
kubectl get events --field-selector involvedObject.name=ttl-test

LAST SEEN   TYPE     REASON      OBJECT         MESSAGE
6s          Normal   Scheduled   pod/ttl-test   Successfully assigned default/ttl-test to i-0b3a5fb6f3823fd2f
3s          Normal   Pulled      pod/ttl-test   Container image "registry.k8s.io/pause:3.9" already present on machine
3s          Normal   Created     pod/ttl-test   Container created
3s          Normal   Started     pod/ttl-test   Container started

約 15 分後に、同じイベントを照会します。

kubectl get events --field-selector involvedObject.name=ttl-test

No resources found in default namespace.

Kubernetes が 15 分後にイベントをガベージコレクションで削除したことから、新しい保持期間が有効になっていることを確認できます。設定の変更前からあったイベントは、引き続き元の保持期間で期限切れになります。1 時間に数千のバッチジョブを実行するクラスターでは、この設定によって etcd の領域を大幅に空けられ、イベントを多く扱うクエリに対する API サーバーの応答時間を短縮できます。

イベントの保持期間を設定するタイミング

次のような場合は、eventTtl を短くするのが適しています。

クラスターで、大量のイベントを生成するバッチ、CI/CD、ML のトレーニング、CronJob のワークロードを実行している。
etcd のストレージが容量の上限に近づいている。
イベントを永続的に保存するために外部のオブザーバビリティシステム (Amazon CloudWatch Container Insights やログアグリゲーターなど) を利用していて、過去のイベントを調べるのに kubectl get events に頼っていない。

TTL を短くすると、kubectl describe pod と kubectl get events で表示される期間も短くなることに注意してください。ストレージの効率とデバッグの手順のバランスが取れる値を選んでください。

クリーンアップ

継続的な料金が発生しないように、AWS アカウントで作成した Amazon EKS クラスターのリソースを必ず削除してください。

kubectl delete deployment heavy-app light-app
kubectl delete pod test-pod
kubectl delete nodepool demo-static

Amazon EKS クラスターを削除するには、Amazon EKS のドキュメントの手順に従ってください。

考慮事項

高度な Kubernetes コントロールプレーン設定を適用する前に、次の点に留意してください。

既存の Amazon EKS API で管理: 高度な Kubernetes コントロールプレーン設定では、既存の CreateCluster API と UpdateClusterConfig API を新しいパラメータとともに使います。設定は、AWS マネジメントコンソール、AWS CLI、AWS CloudFormation で適用できます。eksctl、AWS Controllers for Kubernetes (ACK)、Terraform のサポートも予定されています。(訳注: eksctl は、2026 年 8 月 14 日にリリースされた v0.230.0 でサポートされました。)Amazon EKS は各設定を適用する前に検証し、監査できるように変更を AWS CloudTrail に記録します。
設定はクラスター全体に適用: サポートされている各パラメータは、クラスター全体と、クラスターで実行されるワークロードに適用されます。Kubernetes がすでに従っている Pod レベルの指定 (Pod 自身のリソースの要求量など) は、引き続き適用されます。クラスターの設定で変わるのはコントロールプレーンのデフォルトとスコアリングの動作で、現在利用している Kubernetes の優先順位のルールは変わりません。
スケジューラとノード管理は別のレイヤーで動作: MostAllocated スコアリング戦略が影響するのは、スケジューラが、条件を満たす既存のノードのどれに Pod を配置するかです。Amazon EKS Auto Mode や Karpenter がノードをプロビジョニングしたり削除したりする方法は変わりません。設定を更新する前に、ワークロードでスケジューラとノード管理を組み合わせた動作を検証することをお勧めします。
一部のパラメータには Provisioned Control Plane が必要: horizontalPodAutoscalerSyncPeriod など、コントロールプレーンのパフォーマンスやリソースの消費に影響しうるパラメータは、Provisioned Control Plane の階層を使うクラスターでのみ使用できます。
HPA の同期間隔とクラスターの規模: Provisioned Control Plane のクラスターでは、Amazon EKS は HPA の同期の同時実行数を Kubernetes のデフォルト値の最大 40 倍に引き上げています。同時実行数の引き上げと、HPA の同期間隔 (10～15 秒) を設定できることによって、HPA コントローラーはより多くのスケーリングイベントを並列に処理し、ワークロードの需要の変化にすばやく対応できます。HPA オブジェクトが多いクラスターでは、本番環境に適用する前に、選んだ同期間隔と HPA オブジェクトの数で期待どおりに動作するかを、お客様の環境で検証してください。
Kubernetes バージョンとリージョンのサポート: 高度な Kubernetes コントロールプレーン設定は、Kubernetes 1.31 以降を実行する新規および既存の Amazon EKS クラスターでサポートされています。Amazon EKS を利用できるすべての AWS 商用リージョン、AWS GovCloud (米国)、中国リージョンで、追加料金なしで利用できます。horizontalPodAutoscalerSyncPeriod を使うには Provisioned Control Plane が必要で、Provisioned Control Plane にはスケーリング階層に応じた時間料金がかかります。

まとめ

高度な Kubernetes コントロールプレーン設定により、クラスター管理者は Amazon EKS の可用性とパフォーマンス特性を維持したまま、スケジューリング、リソース管理、API サーバーの設定を直接制御できます。お客様は、デフォルトの Kubernetes スケジューラを改変したものを実行したり、回避策を実装したりする必要がなくなり、運用オーバーヘッドを減らしながら、リソースの使用率を高め、コストを下げられます。この記事では、MostAllocated のビンパッキングで Pod の配置を最適化してリソースの使用率を高め、イベントの保持期間を調整してデバッグのしやすさとストレージの効率のバランスを取りました。ぜひこの機能を使い始めて、AWS Containers Roadmap でフィードバックをお寄せください。

使い始めるには、次の情報をご覧ください。

Amazon EKS ユーザーガイドで、高度な Kubernetes コントロールプレーン設定について確認してください。
コントロールプレーンのキャパシティを事前に割り当てる必要があるパラメータについては、Amazon EKS Provisioned Control Plane の詳細をご覧ください。
ノードの管理を自動化してクラスターの運用を簡素化する Amazon EKS Auto Mode について、詳しくご覧ください。

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

Amazon Web Services ブログ