翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# EKS データプレーン
高可用性で回復力のあるアプリケーションを運用するには、高可用性で回復力のあるデータプレーンが必要です。伸縮自在なデータプレーンにより、Kubernetes はアプリケーションを自動的にスケーリングして修復できます。回復力のあるデータプレーンは、2 つ以上のワーカーノードで構成され、ワークロードに合わせて増減し、障害から自動的に回復できます。
EKS を使用するワーカーノードには、[EKS Auto Mode マネージドノード](https://docs.aws.amazon.com/eks/latest/userguide/automode.html)、[EC2 インスタンス、Fargate ](https://docs.aws.amazon.com/eks/latest/userguide/worker.html)の複数の選択肢があります。 [https://docs.aws.amazon.com/eks/latest/userguide/fargate.html](https://docs.aws.amazon.com/eks/latest/userguide/fargate.html)
EKS Auto Mode は、回復力のあるデータプレーンへの最も簡単なパスを提供します。Auto Mode は、Kubernetes クラスターの AWS 管理をクラスター自体を超えて拡張し、AWS がワークロードのスムーズな運用を可能にするインフラストラクチャをセットアップおよび管理できるようにします。Auto Mode は、Kubernetes が Pod をスケーリングするにつれてデータプレーンを自動的にスケールアップまたはスケールダウンし、クラスター内のノードが現在実行中のワークロードに対して適切かつ費用対効果の高いサイズになるように継続的に機能します。
EC2 インスタンスを選択した場合は、ワーカーノードを自分で管理することも、[EKS マネージド型ノードグループ](https://docs.aws.amazon.com/eks/latest/userguide/managed-node-groups.html)を使用することもできます。Auto Mode、マネージドワーカーノード、セルフマネージドワーカーノード、Fargate を組み合わせたクラスターを持つことができます。
Fargate は、分離されたコンピューティング環境で各 Pod を実行します。Fargate で実行されている各 Pod は、独自のワーカーノードを取得します。Fargate は、Kubernetes がポッドをスケーリングするときにデータプレーンを自動的にスケーリングします。[水平ポッドオートスケーラー](https://docs.aws.amazon.com/eks/latest/userguide/horizontal-pod-autoscaler.html)を使用して、データプレーンとワークロードの両方をスケーリングできます。
EC2 ワーカーノードをスケールする (AWS によって自動的に実行される EKS Auto Mode を使用しない場合) 推奨方法は、[Karpenter](https://karpenter.sh/)、[Kubernetes Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md)、または [EC2 Auto Scaling グループ](https://docs.aws.amazon.com/autoscaling/ec2/userguide/AutoScalingGroup.html)を使用することです。
## 推奨事項
### ワーカーノードとワークロードを複数の AZs
ワーカーノードと Pod を複数の AZ で実行することで、個々の AZs の障害からワークロードを保護できます。ノードを作成するサブネットを使用して、ワーカーノードが作成される AZ を制御できます。
AZs 間でポッドを分散するための推奨方法は、[ポッドにトポロジースプレッド制約を使用することです](https://kubernetes.io/docs/concepts/workloads/pods/pod-topology-spread-constraints/#spread-constraints-for-pods)。EKS Auto Mode や Karpenter などの自動スケーリング機能はトポロジの分散制約を認識し、制約を満たすために正しい 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` は、それらのラベルを持つノードを介してのみトポロジドメインを認識します。上記のデプロイが 1 つのゾーンにのみノードを持つクラスターにデプロイされている場合、すべてのポッド`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 を認識し](https://kubernetes.io/docs/reference/kubernetes-api/labels-annotations-taints/#topologykubernetesiozone)、ボリュームと同じ AZ に EBS ボリュームを必要とするポッドを常にスケジュールします。ただし、ボリュームが配置されている AZ にワーカーノードがない場合は、Pod をスケジュールできません。
EKS Auto Mode または Karpenter を使用する場合は、NodeClass が各 AZ のサブネットを選択することを確認する必要があります。マネージド型ノードグループを使用する場合は、各 AZ にノードグループがあることを確認する必要があります。
EBS ストレージ機能は EKS Auto Mode に組み込まれていますが、Karpenter または Managed Node Groups を使用している場合は[、EBS CSI ](https://docs.aws.amazon.com/eks/latest/userguide/ebs-csi.html)もインストールする必要があります。
### EKS Auto Mode を使用してワーカーノードを管理する
EKS Auto Mode は、運用上のオーバーヘッドを最小限に抑えながら、本番環境対応のクラスターを提供することで、EKS 管理を合理化します。Auto Mode は、クラスターで実行されている Pod に応じて、ノードの数をスケールアップまたはスケールダウンします。ノードはソフトウェアパッチと修正によって自動的に最新の状態に保たれ、更新は設定された [NodePool](https://docs.aws.amazon.com/eks/latest/userguide/create-node-pool.html#_disruption) 中断設定と Pod Disruption Budgets に従って実行されます。
### ノードモニタリングエージェントを実行する
[Node Monitoring Agent](https://docs.aws.amazon.com/eks/latest/userguide/node-health.html) は、Kubernetes イベントを発行し、Node のステータス条件を更新することで、Node のヘルス問題を監視して対応します。Node Monitoring Agent は EKS Auto Mode ノードに含まれており、Auto Mode で管理されていないノードの EKS アドオンとしてインストールできます。
EKS Auto Mode、Managed Node Groups、Karpenter はすべて、Node Monitoring Agent によって報告された致命的なノード状態を検出し、それらの状態が発生したときにそれらのノードを自動的に修復できます。
### QoS の実装
重要なアプリケーションの場合は、Pod のコンテナに `requests`=`limits` を定義することを検討してください。これにより、別の Pod がリソースをリクエストした場合にコンテナが強制終了されることはありません。
ベストプラクティスとして、すべてのコンテナに CPU とメモリの制限を実装することをお勧めします。これにより、コンテナがシステムリソースを誤って消費し、他のコロケーションプロセスの可用性に影響を与えることが防止されます。
### すべてのワークロードのリソースリクエスト/制限を設定およびサイズ設定する
ワークロードのリソースリクエストと制限のサイズ設定には、いくつかの一般的なガイダンスを適用できます。
+ CPU のリソース制限を指定しないでください。制限がない場合、リクエストは[相対的な CPU 時間コンテナが取得する量の](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#how-pods-with-resource-limits-are-run)重みとして機能します。これにより、ワークロードは人為的な制限や飢餓なしに CPU 全体を使用できます。
+ CPU 以外のリソースの場合、 `requests`= `limits`を設定すると最も予測可能な動作が得られます。`requests`\$1= の場合`limits`、コンテナの [QOS](https://kubernetes.io/docs/tasks/configure-pod-container/quality-service-pod/#qos-classes) も保証済みからバースト可能に減るため、[ノードの圧力](https://kubernetes.io/docs/concepts/scheduling-eviction/node-pressure-eviction/)が発生した場合に削除される可能性が高くなります。
+ CPU 以外のリソースの場合、リクエストよりもはるかに大きい制限を指定しないでください。より大きいほど、 に対して設定`limits`され`requests`、ノードがオーバーコミットされる可能性が高くなり、ワークロードが中断される可能性が高くなります。
+ [Karpenter](https://aws.github.io/aws-eks-best-practices/karpenter/) や [Cluster AutoScaler](https://aws.github.io/aws-eks-best-practices/cluster-autoscaling/) などのノードの自動スケーリングソリューションを使用する場合、リクエストのサイズが正しいことが特に重要です。これらのツールは、ワークロードリクエストを調べて、プロビジョニングするノードの数とサイズを決定します。リクエストが小さすぎて制限が大きい場合、ノードに密集している場合、ワークロードが削除されたり、OOM が強制終了されたりすることがあります。
リソースリクエストの決定は難しい場合がありますが、[Vertical Pod Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler) などのツールは、実行時にコンテナリソースの使用状況を観察することで、リクエストを「適切なサイズ」にするのに役立ちます。リクエストサイズの決定に役立つその他のツールは次のとおりです。
+ [ゴールドロック](https://github.com/FairwindsOps/goldilocks)
+ [パーカ](https://www.parca.dev/)
+ [Prodfiler](https://prodfiler.com/)
+ [rsg](https://mhausenblas.info/right-size-guide/)
### 名前空間のリソースクォータを設定する
名前空間は、複数のチームまたはプロジェクト間に分散された多くのユーザーがいる環境での使用を対象としています。これらは名前の範囲を提供し、複数のチーム、プロジェクト、ワークロード間でクラスターリソースを分割する方法です。名前空間のリソース消費の集計を制限できます。[https://kubernetes.io/docs/concepts/policy/resource-quotas/](https://kubernetes.io/docs/concepts/policy/resource-quotas/) オブジェクトは、名前空間で作成できるオブジェクトの数量をタイプ別に制限できます。また、そのプロジェクトのリソースによって消費される可能性のあるコンピューティングリソースの合計量も制限できます。特定の名前空間でリクエストできるストレージやコンピューティング (CPU およびメモリ) リソースの合計を制限できます。
CPU やメモリなどのコンピューティングリソースの名前空間でリソースクォータが有効になっている場合、ユーザーはその名前空間内のコンテナごとにリクエストまたは制限を指定する必要があります。
名前空間ごとにクォータを設定することを検討してください。を使用して`LimitRanges`、名前空間内のコンテナに事前設定された制限を自動的に適用することを検討してください。
### 名前空間内のコンテナリソースの使用を制限する
Resource Quotas は、名前空間で使用できるリソースの量を制限するのに役立ちます。[`LimitRange` オブジェクト](https://kubernetes.io/docs/concepts/policy/limit-range/)は、コンテナがリクエストできる最小リソースと最大リソースの実装に役立ちます。`LimitRange` を使用すると、コンテナのデフォルトのリクエストと制限を設定できます。これは、コンピューティングリソースの制限を設定することが組織内の標準プラクティスではない場合に役立ちます。名前が示すように、 `LimitRange`は名前空間内の Pod またはコンテナあたりのコンピューティングリソース使用量の最小値と最大値を適用できます。また、名前空間で PersistentVolumeClaim ごとに最小ストレージリクエストと最大ストレージリクエストを適用します。
を `LimitRange`と組み合わせて使用`ResourceQuota`して、コンテナおよび名前空間レベルで制限を適用することを検討してください。これらの制限を設定すると、コンテナまたは名前空間がクラスター内の他のテナントが使用するリソースに影響を与えなくなります。
### NodeLocal DNSCache を使用する
[NodeLocal DNSCache を実行することで、クラスター DNS ](https://kubernetes.io/docs/tasks/administer-cluster/nodelocaldns/)のパフォーマンスを向上させることができます。この機能は、クラスターノードで DNS キャッシュエージェントを DaemonSet として実行します。すべてのポッドは、`kube-dns`サービスを使用する代わりに、ノードで実行されている DNS キャッシュエージェントを使用して名前を解決します。この機能は EKS Auto Mode に自動的に含まれます。
### 自動スケーリング CoreDNS を設定する
クラスター DNS のパフォーマンスを向上させるもう 1 つの方法は、[CoreDNS ポッドの組み込み自動スケーリング](https://docs.aws.amazon.com/eks/latest/userguide/coredns-autoscaling.html)を有効にすることです。
この機能は、ノード数や CPU コア数など、クラスターの状態を継続的にモニタリングします。この情報に基づいて、コントローラーは EKS クラスター内の CoreDNS デプロイのレプリカ数を動的に調整します。