View a markdown version of this page

高度な Kubernetes コントロールプレーン設定 - Amazon EKS
概要サポートされている Kubernetes コントロールプレーンパラメータ考慮事項次のステップ

このページの改善にご協力ください

このユーザーガイドに貢献するには、すべてのページの右側のペインにある「GitHub でこのページを編集する」リンクを選択してください。

高度な Kubernetes コントロールプレーン設定

概要

Amazon EKS は、API サーバー、スケジューラー、コントローラーマネージャーを含む、クラスターの Kubernetes コントロールプレーンを管理します。EKS はこれらのコンポーネントを、大半のワークロードで適切に機能するデフォルトのアップストリーム Kubernetes 設定で実行しており、ほとんどのクラスターでは変更する必要はありません。ただし、ワークロードによっては別のコントロールプレーン設定が有利になる場合があります。コンピューティングコストを削減するためにスケジューラーでポッドをより少ないノードに詰め込みたい、クラスターデータベース (etcd) の増大を抑えるために Kubernetes イベントの保持期間を短くしたい、または自動スケーリングの判断をより頻繁に評価したいと考える場合があります。

高度な Kubernetes コントロールプレーン設定では、これらのパラメータをクラスターに直接設定します。EKS はそれらをコントロールプレーンに適用し、クラスターは同じ可用性とパフォーマンス特性で動作を継続します。

これらは高度な設定です。各設定パラメータは、クラスターで実行されるワークロードに対して Kubernetes コントロールプレーンのコアコンポーネントの動作を変更するものであり、適切な値はワークロードによって異なります。パラメータを変更する前に、以下のセクションでその考慮事項を読み、非本番クラスターで変更をテストしてください。

高度なコントロールプレーン設定パラメータは、クラスターの作成時に設定することも、既存のクラスターでいつでも更新することもできます。この機能では、既存の CreateCluster および UpdateClusterConfig オペレーションを新しいパラメータとともに使用するため、AWS マネジメントコンソール、AWS CLI、AWS SDK、または AWS CloudFormation を通じて設定できます。EKS は適用前に各設定を検証し、変更を AWS CloudTrail に記録します。

高度なコントロールプレーンパラメータは、クラスター全体およびそこで実行されるすべてのワークロードに適用されます。これらを個々の名前空間やワークロードに限定することはできません。EKS は各パラメータを検証済みの範囲に制限します。各パラメータでサポートされる値は、以下のセクションでそのパラメータとともに示されています。

サポートされている Kubernetes コントロールプレーンパラメータ

Amazon EKS は以下のパラメータをサポートしています。各パラメータはコントロールプレーンコンポーネントに属し、そのコンポーネントの設定フィールド (kubeSchedulerConfig、kubeControllerManagerConfig、または kubeApiServerConfig) を通じて設定します。

コンポーネント パラメータ サポートされる値 デフォルト プロビジョンドコントロールプレーンが必要

kube-scheduler

nodeResourcesFit.scoringStrategy

LeastAllocated, MostAllocated

LeastAllocated (cpu: 1 および memory: 1 を含む)

いいえ

kube-controller-manager

horizontalPodAutoscalerControllerConfig.horizontalPodAutoscalerSyncPeriod

10s～15s

15s (秒)

はい

kube-controller-manager

podGcControllerConfig.terminatedPodGcThreshold

10000～12500

12500

はい

kube-apiserver

eventTtl

10m～60m

60m (分)

いいえ

kube-apiserver

serviceNodePortRange

minPort および maxPort(10260～32767 の間)

minPort: 30000, maxPort: 32767

いいえ

このトピックのデフォルト値およびサポートされている値は、公開時点で利用可能な Kubernetes バージョン (EKS v1.31 以降) に適用され、後のバージョンで変更される可能性があります。DescribeClusterVersions オペレーションは、各パラメータおよび Kubernetes バージョンの現在のデフォルト値とサポートされている値を報告するため、複数のバージョンにまたがってクラスターを管理する場合やクラスター設定を自動化する場合は、これを信頼できる情報源として使用してください。詳細については、「高度な Kubernetes コントロールプレーンパラメータを設定する」を参照してください。

以下のセクションでは、各パラメータ、それを変更するタイミング、および変更前に考慮すべき事項について説明します。

スケジューラー: ノードリソースの適合

スケジューラーは 2 つのフェーズでポッドをノードに割り当てます。最初にポッドを実行できるノードをフィルタリングし、次に残った候補をスコアリングして、最もスコアの高いノードにポッドを配置します。nodeResourcesFit プラグインは、ノードにポッドが要求するリソースがあるかどうかを確認し、スコアリング戦略に従ってノードをスコアリングします。

フィールド 説明 サポートされる値 デフォルト

nodeResourcesFit.scoringStrategy.type

リソース割り当てによってノードをスコアリングするために使用される戦略。

LeastAllocated, MostAllocated

LeastAllocated

nodeResourcesFit.scoringStrategy.resources

スコアリング時に考慮されるリソース。それぞれに相対的な重みが付きます。

cpu、memory、nvidia.com/gpu、aws.amazon.com/neuron、aws.amazon.com/neuroncore。重みは 1～100 の範囲です。

cpu: 1, memory: 1

LeastAllocated はリソース割り当ての少ないノードを優先し、クラスター内のノード全体にポッドを分散させ、各ノードに余裕を残します。これは Kubernetes のデフォルトの動作であり、既存のポッドの増加を吸収できる容量をすべてのノードで利用可能にしたい場合に適した選択です。

MostAllocated はリソース割り当てが既に多いノードを優先し、より少ないノードにポッドを詰め込みます。ワークロードが占有する合計容量が少なくなるため、より少ない数のノードで実行でき、コンピューティング費用を削減できます。時間の経過とともに、この詰め込み動作により使用率の低いノードに新しいワークロードが割り当てられなくなるため、統合をサポートするノードプールはそれらを削除できます。

EKS は LeastAllocated および MostAllocated 戦略をサポートしています。アップストリーム Kubernetes の RequestedToCapacityRatio 戦略はサポートされていません。

リソースの重み

必要に応じて、スコアリングの判断でどのリソースを最も重視するかに影響を与えるカスタム重みを持つ resources 配列を指定できます。これは、特定のリソースがクラスターの制約となっている場合に役立ちます。例えば、アクセラレーター (GPU) が不足しているリソースであるクラスターでは、nvidia.com/gpu の重みを CPU やメモリよりも高くすると、アクセラレーターを要求するポッドが、既に部分的に使用されているノードに集中します。

重みは絶対的ではなく相対的です。cpu: 100 と memory: 1 を設定しても、スケジューラーがメモリを無視するわけではありません。スコアリング式において、CPU をメモリより 100 倍重く評価します。すべての候補ノードの CPU 可用性が同一であれば、CPU ではそれらを区別できなくなり、スコアリングは事実上メモリに移ります。

リソースを省略することは、低い重みを付けることとは異なります。resources 配列を指定すると、リストしたリソースのみがスコアリングされます。除外したリソースは、計算から完全に除外されます。例えば、cpu: 100 に memory のエントリがない場合、CPU のみでノードをスコアリングし、メモリの可用性は結果に影響しません。リソースを計算に含めたまま影響を減らすには、省略するのではなく、低い重みを付けてリストします。

nvidia.com/gpu などのアクセラレーターリソースに重みを付けると、そのリソースに対して実際に resources.requests を宣言しているポッドのスコアリングにのみ影響します。アクセラレーターを要求しないポッドは、アクセラレーターの重みの影響を受けません。

3 つのアクセラレーターリソースは Kubernetes の拡張リソースであり、組み込みではなく、プラグインによって Kubernetes にアドバタイズされるノードレベルのリソースです。これらは、デバイスプラグインがデバイスプラグイン API を通じて kubelet にアドバタイズした場合にのみスコアリングされます。デバイスドライバーだけによってノードで利用可能になったリソースは、nodeResourcesFit プラグインからは認識されず、スコアリングされません。Dynamic Resource Allocation (DRA) を通じて管理されるリソースは、別のプラグインによってスケジュールされ、nodeResourcesFit のスコアリングには含まれないため、DRA を有効にしてもこのパラメータの動作は変わりません。NVIDIA デバイスプラグインの設定の詳細については、「NVIDIA DRA とデバイスプラグイン」を参照してください。Neuron デバイスの設定の詳細については、「Neuron デバイス管理」を参照してください。

スコアリング戦略は、スケジューラーが各ノードのスコアを計算するために使用する複数の入力の 1 つです。スケジューラーがノードをフィルタリングおよびスコアリングする方法の詳細については、Kubernetes ドキュメントの「スケジューリングフレームワーク」を参照してください。

スコアリング戦略に関する考慮事項

  • 実行中のポッドは移動されません。Kubernetes スケジューラーは、既に実行中のポッドを再配置することはありません。スコアリング戦略の変更は今後のスケジューリング判断にのみ影響し、既存のポッドの配置は永続的です。既に実行中のポッドのバランスを再調整するには、ポッドをエビクションまたは再起動します。

  • フィルタリング動作は変わりません。スコアリング戦略は、スケジューラーが選好度に応じてノードをランク付けするスコアリングフェーズにのみ影響します。ポッドがノードで実行できるかどうかを判断するフィルタリングフェーズは変更されません。ノードに適合しないポッドは、どちらの戦略でもそのノードにスケジュールされません。

  • MostAllocated は障害の影響範囲を集中させます。ワークロードをより少ないノードに詰め込むと、ノードが異常になった場合、インスタンスが廃止された場合、またはアベイラビリティーゾーンが中断された場合に、一度に影響を受けるポッドが増えます。ポッドの入れ替わりが激しい状況では、高密度に詰め込まれたノードもより早くいっぱいになり、新しい容量がプロビジョニングされる間、ポッドが Pending 状態のままになる可能性があります。

  • スケジューラーとノード管理は異なるレイヤーで動作します。スコアリング戦略は、既にポッドを実行できるノードの間でポッドがどこに配置されるかに影響します。EKS Auto Mode または Karpenter がノードをプロビジョニングまたは削除する方法は変わりません。設定を変更する前に、ワークロードの組み合わせた動作を検証してください。

コントローラーマネージャー: Horizontal Pod Autoscaler の同期期間

コントローラーマネージャーは、Horizontal Pod Autoscaler (HPA) コントローラーを含む、クラスターの状態を望ましい状態に近づける Kubernetes コントローラーを実行します。各サイクルで、HPA コントローラーは各 HorizontalPodAutoscaler オブジェクトのメトリクスを取得し、望ましいレプリカ数を計算し、数が変更されていればターゲットワークロードを更新します。

フィールド 説明 サポートされる値 デフォルト

horizontalPodAutoscalerControllerConfig.horizontalPodAutoscalerSyncPeriod

HPA コントローラーがスケーリングの判断を評価する頻度。

10s～15s

15s

同期期間を短縮すると、負荷の増加後に容量を追加するまで 1 サイクル全体を待つのではなく、ワークロードがより早くスケールします。

このパラメータを設定するには、クラスターが Amazon EKS プロビジョンドコントロールプレーン上にある必要があります。間隔を短縮すると、HPA コントローラーがクラスター内のすべての HorizontalPodAutoscaler オブジェクトを調整する頻度が高まり、より多くの API リクエストが生成されます。各調整では少なくとも 1 つの API リクエストを消費し、レプリカ数を変更する調整ではさらに 2 つ消費します。プロビジョンドコントロールプレーンクラスターは、要求の厳しいワークロードに常に備えたコントロールプレーン容量を事前に割り当てるため、その追加負荷を吸収できるようにサイズ設定されています。詳細については、「Amazon EKS プロビジョンドコントロールプレーン」を参照してください。

クラスターがサポートする HPA オブジェクトの数への影響

  • 同期期間を短縮すると、同じキューを処理する時間が短くなるため、コントロールプレーンがスケジュールどおりに調整できる HorizontalPodAutoscaler オブジェクトの数が減少します。期間を 15s から 10s に短縮すると、サポートされるオブジェクト数がおよそ 3 分の 1 減少します。同期期間を短縮する前に、クラスター内の HorizontalPodAutoscaler オブジェクトを数え、短縮後の期間でもスケーリング階層でその数がサポートされることを確認してください:

    kubectl get hpa --all-namespaces --no-headers | wc -l

  • EKS は、HPA オブジェクト数に対して同期期間を検証しません。クラスターに短縮後の期間でサポートされる数より多くの HorizontalPodAutoscaler オブジェクトが既にある場合でも、設定変更は成功します。変更を行う前に、自分で数を確認してください。

  • サポートされる数を超えると、自動スケーリングが通知なしに低下します。コントローラーが期間内にすべてのオブジェクトを処理できない場合、一部のオブジェクトはスケジュールどおりに調整されません。EKS はこの状態に対してアラームや Kubernetes イベントを発行せず、自動スケーリングの応答に予想より時間がかかるようになります。これは意図した効果とは逆です。同期期間を短縮した後にスケーリングの遅延が発生した場合は、パラメータをデフォルトの 15s に戻してください。

  • 同期期間はクラスター内のすべての HPA オブジェクトに適用されます。オブジェクトや名前空間ごとに異なる同期期間を設定することはできません。

コントローラーマネージャー: 終了したポッドのガベージコレクションしきい値

コントローラーマネージャーは、終了したポッドのガベージコレクター (ポッド GC コントローラー) を実行します。このコントローラーは、クラスター内の終了したポッドの数がしきい値を超えると、終了したポッド (Succeeded または Failed フェーズのポッド) を削除します。terminatedPodGcThreshold パラメータがそのしきい値を設定します。

フィールド 説明 サポートされる値 デフォルト

podGcControllerConfig.terminatedPodGcThreshold

終了したポッドのガベージコレクターが終了したポッドの削除を開始する前に存在できる、終了したポッドの数。

10000～12500

12500

ガベージコレクターは 20 秒の固定サイクルで実行されます。しきい値を下げると、コレクターは次のサイクルで、数が新しいしきい値に達するまで、最も古い終了ポッドの強制削除を開始します。

このパラメータを設定するには、クラスターが Amazon EKS プロビジョンドコントロールプレーン上にある必要があります。しきい値を下げると、コントローラーがクラスターデータベース (etcd) に対して実行するガベージコレクションの作業が増加します。各コレクションパスで、より多くの終了したポッドをクエリ、処理、削除できるようになります。プロビジョンドコントロールプレーンクラスターは、要求の厳しいワークロードに常に備えたコントロールプレーン容量を事前に割り当てるため、その追加負荷を吸収できます。詳細については、「Amazon EKS プロビジョンドコントロールプレーン」を参照してください。

終了したポッドのガベージコレクションしきい値に関する考慮事項

  • しきい値を下げると、余分な終了ポッドが直ちに削除されます。しきい値を下げると (例えば、12500 から 10000 に)、ガベージコレクションコントローラーは次のサイクルで最も古い終了ポッドの強制削除を開始します。コントローラーは、終了ポッド数が新しいしきい値に達するまで続行します。削減は段階的ではありません。

  • しきい値は、所有者に関係なくすべての終了ポッドに適用されます。これは、Job、CronJob、または Deployment に所有されているか、スタンドアロンであるかに関係なく、Succeeded または Failed フェーズのポッドに影響します。実際には、Job および CronJob のポッドが、終了ポッド数の最も一般的な要因です。

  • しきい値を下げると、デバッグの時間枠が短くなります。完了したポッドと失敗したポッドは、kubectl get pods と kubectl logs からより早く消えます。完了した Job ポッドの終了コードやログを検査するオートメーションは、動作できる時間枠が小さくなります。

  • しきい値はクラスター全体の設定です。名前空間ごとまたは Job ごとに設定することはできません。個々の Job のポッドのライフサイクルを制御するには、その Job で ttlSecondsAfterFinished を使用します。

API サーバー: イベントの保持

API サーバーは Kubernetes コントロールプレーンのフロントエンドです。Kubernetes API を提供し、クラスターの状態をクラスターデータベース (etcd) に永続化します。Kubernetes は、ポッドのスケジューリング判断、イメージのプル、ヘルスチェックの失敗、スケーリングアクションなど、クラスターで発生していることを説明するイベントを記録します。

フィールド 説明 サポートされる値 デフォルト

eventTtl

API サーバーが Kubernetes イベントを削除する前に保持する期間。

10m～60m

60m

大規模なバッチジョブ、AI ワークロード、CI/CD パイプライン、頻繁な CronJob など、入れ替わりの激しいワークロードを実行するクラスターは、数千のイベントを急速に蓄積します。保持されるすべてのイベントは、クラスターの実行に必要なオブジェクトと競合するクラスターデータベース領域を消費し、イベントコレクションが大きくなると、API サーバーのリスト操作の処理コストが高くなります。

イベントの保持期間を短縮すると、この短命な診断データがより早く消去され、クラスターデータベースのストレージ負荷が軽減され、イベントの多いクエリに対する API サーバーの応答時間が改善されます。

保持期間を短くすることが適しているのは、次の場合です:

  • クラスターが、大量のイベントを生成するバッチ、CI/CD、AI、または CronJob ワークロードを実行している場合。

  • クラスターデータベースのストレージが限界に向けて増加しているのを確認した場合。

  • イベントを永続的にキャプチャするために外部システムに依存しており、履歴デバッグに kubectl get events を利用していない場合。

イベントの保持に関する考慮事項

  • 変更は新しいイベントにのみ適用されます。Kubernetes は、イベントの作成時にその有効期限を設定します。既に存在するイベントは、作成時に有効だった保持期間を維持し、そのスケジュールで期限切れになります。eventTtl を短縮しても、クラスターデータベースに既にあるイベントの有効期間は短くならないため、ストレージの削減は既存のイベントが期限切れになるにつれて徐々に効果を発揮します。

  • 削除されたイベントは復元できません。Kubernetes がイベントを削除すると、そのイベントは永久に失われます。意図した以上に保持期間を短縮してイベント履歴を失った場合、それを復元する方法はありません。この値を短縮する前に、トラブルシューティングで依存している情報がクラスター外で収集されていることを確認してください。

  • イベントは設定された期間をわずかに超えて保持されることがあります。状況によっては、コントロールプレーンのリーダー選出中に発生する可能性のある etcd リースの更新により、イベントの有効期限が設定した値を超えて延長されることがあります。

  • デバッグウィンドウの短縮。保持期間を短くすると、kubectl get events と kubectl describe に表示されるウィンドウが狭くなります。クラスターからイベントを収集するモニタリングツールで利用できるデータが少なくなります。ストレージ効率とデバッグワークフローのバランスが取れる値を選択してください。

  • この設定はクラスター全体に適用されます。保持期間は、ポッドのスケジューリング、ノードの状態、スケーリングイベントなど、すべての名前空間のすべてのイベントに適用されます。名前空間ごとに異なる保持期間を設定することはできません。

API サーバー: サービスノードポート範囲

Kubernetes は、ポートを必要とする各サービスのために、この範囲からすべてのノード上にポートを割り当てます。これにはタイプ NodePort のサービスが含まれ、デフォルトではタイプ LoadBalancer のサービスも含まれます。

フィールド 説明 サポートされる値 デフォルト

serviceNodePortRange.minPort

範囲内の最小ポート。

10260～32767

30000

serviceNodePortRange.maxPort

範囲内の最大ポート。

10260～32767

32767

minPort は maxPort 以下である必要があります。Amazon EKS は、minPort が maxPort より大きい設定を拒否します。

範囲を変更することで、ノードポートの割り当てを組織が既に適用しているネットワークポリシーやファイアウォールポリシーに合わせることができます。範囲を広げると、1 つのクラスターでサポートできるサービスの数も増えます。このパラメータは、移行時に特に役立ちます。Amazon EKS に移行するアプリケーションと、それらを呼び出すクライアントは、特定の固定ポートでサービスが提供されることを期待していることがよくあります。それらのポートがデフォルト範囲外にある場合、通常の選択肢は、アプリケーションを変更するか、その前にプロキシを配置することです。範囲をアプリケーションが既に使用しているポートに合わせることで、その作業が不要になり、アプリケーションを書き換えたり、維持するネットワークコンポーネントを追加したりすることなく、ワークロードを EKS に移行できます。

範囲が 10260 と 32767 で制限されている理由

10260 の下限により、NodePort の割り当ては、ノード上の Kubernetes システムコンポーネントが既に使用しているポート (kubelet ヘルスポート (10248) や kube-proxy ヘルスチェックポート (10256) など) を回避できます。

32767 の上限により、範囲は、通常 32768 から始まる Linux のエフェメラルポート範囲を回避できます。NodePort がエフェメラル範囲内にある場合、カーネルがノードからの送信接続用にそのポートを選択し、サービスと競合する可能性があります。

サービスノードのポート範囲に関する考慮事項

  • 既存のサービスは割り当てられたポートを保持します。範囲を狭めた場合、新しい範囲外のポートを既に保持しているサービスは引き続き機能し、kube-proxy は引き続きそれらにトラフィックをルーティングします。Amazon EKS は、範囲が変更されても既存のサービスのポートを再割り当てしません。

  • サービスを再作成すると、そのポートが再割り当てされます。範囲外のポートを保持しているサービスが削除されて再作成された場合、そのポートは割り当てられなくなります。特に、デプロイプロセスがサービスを更新するのではなく再作成する場合、既存のサービスが依存している範囲を狭める前に、これに備えて計画してください。

  • 範囲外の新しい割り当ては拒否されます。設定された範囲外のポートを必要とするサービスを作成または更新すると、API サーバーからの検証エラーで失敗します。

  • 明示的に指定されたポートも検証されます。サービスが Kubernetes に割り当てさせるのではなく、nodePort 値を直接指定する場合、そのポートは設定された範囲内にある必要があります。範囲外の静的ポートリクエストは、以前に設定していた現在の範囲より広い範囲では同じポートが有効だったとしても、拒否されます。

  • 範囲はクラスター全体に適用されます。名前空間ごとに異なる範囲を設定することはできません。

このパラメータを変更する前に、セキュリティグループとネットワーク ACL が新しい範囲のトラフィックを許可していること、および範囲がノード上の他のソフトウェアで使用されているポートと競合しないことを確認してください。

考慮事項

高度なコントロールプレーンパラメータを設定する前に、以下を確認してください。

  • クラスター全体のスコープ – コントロールプレーンパラメータは、クラスター全体とそこで実行されているすべてのワークロードに適用されます。これらを個々の名前空間やワークロードに限定することはできません。本番環境に適用する前に、非本番クラスターでパラメータ変更をテストしてください。

  • Horizontal Pod Autoscaler の同期期間と終了したポッドのガベージコレクションしきい値にはプロビジョンドコントロールプレーンが必要 – horizontalPodAutoscalerSyncPeriod および terminatedPodGcThreshold パラメータは、Amazon EKS プロビジョンドコントロールプレーンを使用するクラスターでのみ使用できます。Amazon EKS は、コントロールプレーンのリソース消費を大幅に増加させるパラメータを、コントロールプレーン容量が事前に割り当てられたクラスターに限定します。標準コントロールプレーンモードのクラスターでいずれかのパラメータを設定すると失敗します。これらを使用するには、まずクラスターをプロビジョンドコントロールプレーンスケーリング階層に移行します。詳細については、「Amazon EKS プロビジョンドコントロールプレーン」を参照してください。

  • Horizontal Pod Autoscaler の同期期間と終了したポッドのガベージコレクションしきい値の終了制限 – horizontalPodAutoscalerSyncPeriod または terminatedPodGcThreshold がデフォルト以外の値に設定されている場合、クラスターのコントロールプレーンをプロビジョンドモードから標準モードに戻すことはできません。標準モードに戻すには、まず両方のパラメータをデフォルト (15s と 12500) に戻し、次にコントロールプレーンのスケーリング階層を standard に変更します。

  • デフォルト値への戻し – Amazon EKS は専用のリセット操作を提供しておらず、更新でフィールドを省略すると、そのフィールドはクリアされずに現在の値が保持されます。パラメータをデフォルトに戻すには、明示的にデフォルト値に設定します。クラスターが実行している Kubernetes バージョンのデフォルト値は、DescribeClusterVersions で取得します。詳細については、「高度な Kubernetes コントロールプレーンパラメータを設定する」を参照してください。

  • 更新のセマンティクス – 更新は既存の設定とマージされます。指定したフィールドのみが変更され、省略したフィールドは現在の値を保持します。これは、コンポーネント間および単一コンポーネント内の両方に適用されます。例えば、スケジューラ設定のみを指定した更新では、コントローラーマネージャーと API サーバーの設定は変更されません。

  • 現在の設定の表示 – describe-cluster 操作は、カスタマイズしていないパラメータとそのデフォルト値を含め、コントロールプレーンで実行されている完全な設定を返します。

  • デフォルト値とサポートされる値は Kubernetes バージョン間で変わる可能性があります – このトピックに記載されている値は、公開時に利用可能な Kubernetes バージョンに適用されます。DescribeClusterVersions を使用して、各パラメータおよび Kubernetes バージョンの現在のデフォルト値とサポートされる値を取得します。「高度な Kubernetes コントロールプレーンパラメータを設定する」を参照してください。

  • 既存のクラスターは変更されません – Amazon EKS は既存のクラスターの動作を変更しません。明示的にパラメータを設定するまで、すべてのクラスターはデフォルトのパラメータ値で実行され続けます。

  • 変更は即座に適用されません – UpdateClusterConfig が戻った時点では、設定変更は有効になっていません。Amazon EKS はコントロールプレーンのローリング更新を通じて新しい設定を適用するため、変更が完全に有効になるまで数分かかります。更新が完了すると、クラスターは ACTIVE ステータスに戻ります。DescribeUpdate 操作を使用して進行状況を追跡するか、aws eks wait cluster-active を使用して変更が完了するまでブロックできます。

  • 監査可能性 – Amazon EKS は適用前に各設定を検証し、設定変更を AWS CloudTrail に記録します。

  • ツールのサポート – 高度な Kubernetes コントロールプレーン設定は、リリース時に AWS マネジメントコンソール、eksctl、AWS CLI、Amazon EKS API、AWS CloudFormation、AWS CDK を通じて利用できます。AWS Controllers for Kubernetes (ACK) および Terraform のサポートは近日提供予定です。

  • Kubernetes バージョンのサポート – 高度な Kubernetes コントロールプレーン設定は、Kubernetes バージョン 1.31 以降を実行している新規および既存のクラスターでサポートされています。

  • AWS リージョンのサポート – 高度な Kubernetes コントロールプレーン設定は、Amazon EKS が利用可能なすべての AWS 商用リージョン、AWS GovCloud (US) リージョン、および AWS 中国リージョンで利用できます。

  • 料金 – コントロールプレーンパラメータの設定に追加料金はかかりません。horizontalPodAutoscalerSyncPeriod を使用するにはプロビジョンドコントロールプレーンが必要で、スケーリング階層の時間単位の料金で請求されます。詳細については、「Amazon EKS の料金」を参照してください。

次のステップ