翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
EKS データプレーン
高可用性で回復力のあるアプリケーションを運用するには、高可用性で回復力のあるデータプレーンが必要です。伸縮自在なデータプレーンにより、Kubernetes はアプリケーションを自動的にスケーリングして修復できます。回復力のあるデータプレーンは、2 つ以上のワーカーノードで構成され、ワークロードに合わせて増減し、障害から自動的に回復できます。
EKS を使用するワーカーノードには、EKS Auto Mode マネージドノード、EC2 インスタンス、Fargate の複数の選択肢があります。 https://docs.aws.amazon.com/eks/latest/userguide/fargate.html
EKS Auto Mode は、回復力のあるデータプレーンへの最も簡単なパスを提供します。Auto Mode は、Kubernetes クラスターの AWS 管理をクラスター自体を超えて拡張し、AWS がワークロードのスムーズな運用を可能にするインフラストラクチャをセットアップおよび管理できるようにします。Auto Mode は、Kubernetes が Pod をスケーリングするにつれてデータプレーンを自動的にスケールアップまたはスケールダウンし、クラスター内のノードが現在実行中のワークロードに対して適切かつ費用対効果の高いサイズになるように継続的に機能します。
EC2 インスタンスを選択した場合は、ワーカーノードを自分で管理することも、EKS マネージド型ノードグループを使用することもできます。Auto Mode、マネージドワーカーノード、セルフマネージドワーカーノード、Fargate が混在したクラスターを持つことができます。
Fargate は、分離されたコンピューティング環境で各 Pod を実行します。Fargate で実行されている各 Pod は、独自のワーカーノードを取得します。Fargate は、Kubernetes がポッドをスケーリングするときにデータプレーンを自動的にスケーリングします。水平ポッドオートスケーラーを使用して、データプレーンとワークロードの両方をスケールできます。
EC2 ワーカーノードをスケールする (AWS によって自動的に実行される EKS Auto Mode を使用しない場合) 推奨方法は、Karpenter
レコメンデーション
ワーカーノードとワークロードを複数の AZs
ワーカーノードと Pod を複数の AZ で実行することで、個々の AZs の障害からワークロードを保護できます。ノードを作成するサブネットを使用して、ワーカーノードが作成される AZ を制御できます。
AZs 間でポッドを分散するための推奨方法は、ポッドにトポロジースプレッド制約を使用することです
以下のデプロイでは、可能な場合はポッドを AZs に分散し、そうでない場合はとにかくポッドを実行できるようにします。
apiVersion: apps/v1 kind: Deployment metadata: name: web-server spec: replicas: 3 selector: matchLabels: app: web-server template: metadata: labels: app: web-server spec: topologySpreadConstraints: - maxSkew: 1 whenUnsatisfiable: ScheduleAnyway topologyKey: topology.kubernetes.io/zone labelSelector: matchLabels: app: web-server containers: - name: web-app image: nginx resources: requests: cpu: 1
注記
kube-scheduler は、それらのラベルを持つノードを介してのみトポロジドメインを認識します。上記のデプロイが単一ゾーンのノードのみを持つクラスターにデプロイされている場合、すべてのポッドkube-schedulerは他のゾーンを認識していないため、それらのノードでスケジュールされます。このトポロジがスケジューラで期待どおりに機能するには、ノードがすべてのゾーンに既に存在している必要があります。トポロジスプレッド制約の minDomainsプロパティは、この問題を回避するために実行中のノードがある場合でも、対象ドメインの数をスケジューラに通知するために使用されます。
警告
whenUnsatisfiable を に設定するとDoNotSchedule、トポロジの分散制約が満たされない場合、ポッドはスケジュールできなくなります。これは、トポロジの分散制約に違反するのではなく、ポッドを実行しない方が望ましい場合にのみ設定する必要があります。
古いバージョンの Kubernetes では、ポッドアンチアフィニティルールを使用して、複数の AZs 間でポッドをスケジュールできます。以下のマニフェストは、異なる AZ でポッドをスケジュールすることを Kubernetes スケジューラに指示します。 AZs
apiVersion: apps/v1 kind: Deployment metadata: name: web-server labels: app: web-server spec: replicas: 4 selector: matchLabels: app: web-server template: metadata: labels: app: web-server spec: affinity: podAntiAffinity: preferredDuringSchedulingIgnoredDuringExecution: - podAffinityTerm: labelSelector: matchExpressions: - key: app operator: In values: - web-server topologyKey: failure-domain.beta.kubernetes.io/zone weight: 100 containers: - name: web-app image: nginx
警告
異なる AZs 間でポッドをスケジュールする必要はありません。そうしないと、デプロイ内のポッドの数が AZs の数を超えることはありません。
EBS ボリュームを使用するときに、各 AZ でノードを起動する機能を確保する
Amazon EBS を使用して永続ボリュームを提供する場合は、ポッドと関連する EBS ボリュームが同じ AZ にあることを確認する必要があります。ポッドは、別の AZ にある EBS-backed 永続ボリュームにアクセスできません。Kubernetes スケジューラは、ノード上のラベルからワーカーノードが配置されている AZ を認識し
EKS Auto Mode または Karpenter を使用する場合は、NodeClass が各 AZ のサブネットを選択することを確認する必要があります。マネージド型ノードグループを使用する場合は、各 AZ にノードグループがあることを確認する必要があります。
EBS ストレージ機能は EKS Auto Mode に組み込まれていますが、Karpenter または Managed Node Groups を使用している場合は、EBS CSI もインストールする必要があります。
EKS Auto Mode を使用してワーカーノードを管理する
EKS Auto Mode は、運用上のオーバーヘッドを最小限に抑えながら、本番環境対応のクラスターを提供することで EKS 管理を合理化します。Auto Mode は、クラスターで実行されている Pod に応じて、ノードの数をスケールアップまたはスケールダウンします。ノードはソフトウェアパッチと修正によって自動的に最新の状態に保たれ、更新は設定された NodePool 中断設定と Pod Disruption Budgets に従って実行されます。
ノードモニタリングエージェントを実行する
Node Monitoring Agent は、Kubernetes イベントを公開し、ノードのステータス条件を更新することで、ノードのヘルス問題をモニタリングして対応します。Node Monitoring Agent は EKS Auto Mode ノードに含まれており、Auto Mode で管理されていないノードの EKS アドオンとしてインストールできます。
EKS Auto Mode、マネージドノードグループ、Karpenter はすべて、Node Monitoring Agent によって報告された致命的なノード状態を検出し、それらの状態が発生したときにそれらのノードを自動的に修復できます。
QoS の実装
重要なアプリケーションの場合は、Pod のコンテナに requests=limits を定義することを検討してください。これにより、別の Pod がリソースをリクエストした場合にコンテナが強制終了されることはありません。
ベストプラクティスとして、すべてのコンテナに CPU とメモリの制限を実装することをお勧めします。これにより、コンテナが誤ってシステムリソースを消費し、他のコロケーションプロセスの可用性に影響を与えることが防止されます。
すべてのワークロードのリソースリクエスト/制限を設定およびサイズ設定する
ワークロードのリソースリクエストと制限のサイズ設定には、いくつかの一般的なガイダンスを適用できます。
-
CPU のリソース制限を指定しないでください。制限がない場合、リクエストは相対的な CPU 時間コンテナが取得する量の
重みとして機能します。これにより、ワークロードは人為的な制限や飢餓なしに CPU 全体を使用できます。 -
CPU 以外のリソースの場合、
requests=limitsを設定すると最も予測可能な動作が得られます。requests!= の場合limits、コンテナの QOSも保証済みからバースト可能に減るため、ノードの圧力 が発生した場合に削除される可能性が高くなります。 -
CPU 以外のリソースの場合、リクエストよりもはるかに大きい制限を指定しないでください。より大きい
limitsが に対して設定されるとrequests、ノードがオーバーコミットされ、ワークロードが中断される可能性が高くなります。 -
Karpenter
や Cluster AutoScaler などのノードの自動スケーリングソリューションを使用する場合、リクエストのサイズが正しいことが特に重要です。これらのツールは、ワークロードリクエストを調べて、プロビジョニングするノードの数とサイズを決定します。リクエストが小さすぎて制限が大きい場合、ワークロードがノードに密集している場合、ワークロードが削除されたり、OOM が強制終了されたりすることがあります。
リソースリクエストの決定は難しい場合がありますが、Vertical Pod Autoscaler
名前空間のリソースクォータを設定する
名前空間は、複数のチームまたはプロジェクト間に分散された多くのユーザーがいる環境での使用を対象としています。これらは名前の範囲を提供し、複数のチーム、プロジェクト、ワークロード間でクラスターリソースを分割する方法です。名前空間のリソース消費の集計を制限できます。ResourceQuota
CPU やメモリなどのコンピューティングリソースの名前空間でリソースクォータが有効になっている場合、ユーザーはその名前空間内のコンテナごとにリクエストまたは制限を指定する必要があります。
名前空間ごとにクォータを設定することを検討してください。を使用してLimitRanges、名前空間内のコンテナに事前設定された制限を自動的に適用することを検討してください。
名前空間内のコンテナリソースの使用を制限する
Resource Quotas は、名前空間で使用できるリソースの量を制限するのに役立ちます。LimitRange オブジェクトLimitRange を使用すると、コンテナのデフォルトのリクエストと制限を設定できます。これは、コンピューティングリソースの制限を設定することが組織内の標準プラクティスではない場合に役立ちます。名前が示すように、 LimitRangeは名前空間内の Pod またはコンテナあたりのコンピューティングリソース使用量の最小値と最大値を適用できます。また、名前空間で PersistentVolumeClaim ごとに最小ストレージリクエストと最大ストレージリクエストを適用します。
を LimitRangeと組み合わせて使用ResourceQuotaして、コンテナレベルと名前空間レベルで制限を適用することを検討してください。これらの制限を設定すると、コンテナまたは名前空間がクラスター内の他のテナントが使用するリソースに影響を与えなくなります。
NodeLocal DNSCache を使用する
NodeLocal DNSCache を実行することで、クラスター DNS kube-dnsサービスを使用する代わりに、ノードで実行されている DNS キャッシュエージェントを使用して名前を解決します。この機能は EKS Auto Mode に自動的に含まれます。
自動スケーリング CoreDNS を設定する
クラスター DNS のパフォーマンスを向上させるもう 1 つの方法は、CoreDNS ポッドの組み込み自動スケーリングを有効にすることです。
この機能は、ノード数や CPU コア数など、クラスターの状態を継続的にモニタリングします。この情報に基づいて、コントローラーは EKS クラスター内の CoreDNS デプロイのレプリカ数を動的に調整します。
