**このページの改善にご協力ください**
このユーザーガイドに貢献するには、すべてのページの右側のペインにある「**GitHub でこのページを編集する**」リンクを選択してください。
# EKS Auto Mode の仕組みの説明
この章では、Amazon EKS Auto Mode クラスターのコンポーネントの仕組みについて説明します。
**Topics**
+ [Amazon EKS 自動モードl マネージドインスタンスについての説明](automode-learn-instances.md)
+ [EKS Auto Mode での ID とアクセスについての説明](auto-learn-iam.md)
+ [EKS 自動モードl での VPC ネットワーキングとロードバランシングの説明](auto-networking.md)
# Amazon EKS 自動モードl マネージドインスタンスについての説明
このトピックではAmazon EKS 自動モードl が EKS クラスター内の Amazon EC2 インスタンスを管理する方法について説明します。EKS 自動モードl を有効にすると、クラスターのコンピューティングリソースが EKS によって自動的にプロビジョニングおよび管理され、クラスター内のノードとして機能する EC2 インスタンスの操作方法が変わります。
Amazon EKS 自動モードl がインスタンスを管理する方法を理解することはワークロードのデプロイ戦略と運用手順を計画するのに不可欠です。従来の EC2 インスタンスやマネージドノードグループとは異なり、これらのインスタンスは特定のタイプのアクセスとカスタマイズを制限しながら、EKS が多くの運用面に対して責任を負う別のライフサイクルモデルに従います。
Amazon EKS 自動モードl は新しい EC2 インスタンスを作成するためのルーチンタスクを自動化し、それらをノードとして EKS クラスターにアタッチします。EKS 自動モードl はワークロードが既存のノードに収まらない状況を検出し、新しい EC2 インスタンスを作成します。
Amazon EKS 自動モードl はEC2 インスタンスの作成、削除、パッチ適用を担います。インスタンスにデプロイされたコンテナとポッドについてはユーザーの責任となります。
EKS 自動モードl によって作成された EC2 インスタンスは他の EC2 インスタンスとは異なり、マネージドインスタンスです。このマネージドインスタンスは EKS によって所有され、制限が厳しくなっています。EKS 自動モードl によって管理されているインスタンスに直接アクセスしたりソフトウェアをインストールしたりすることはできません。
AWS ではEKS 自動モードl またはセルフマネージド Karpenter の実行をお勧めします。移行中でも高度な設定においてでもインストールが可能です。両方がインストールされている場合はワークロードが Karpenter または EKS 自動モードl に関連付けられるようにノードプールを設定します。
詳細については「Amazon EC2 ユーザーガイド」の「[Amazon EC2 管理されたインスタンス](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/amazon-ec2-managed-instances.html)」を参照してください。
## 比較表
| スタンダード EC2 インスタンス | EKS 自動モードl マネージドインスタンス |
| --- | --- |
| インスタンスのパッチ適用と更新はユーザーの責任となります。 | AWS で自動的にインスタンスのパッチ適用と更新が行われます。 |
| EKS はインスタンス上のソフトウェアに関与しません。 | EKS は`kubelet`、コンテナランタイム、オペレーティングシステムなど、インスタンス上の特定のソフトウェアに関与します。 |
| EC2 API を使用して EC2 インスタンスを削除できます。 | EKS によりアカウントにデプロイされたインスタンスの数が決定されます。ワークロードを削除すると、EKS によりアカウント内のインスタンスの数が減ります。 |
| SSH を使用して EC2 インスタンスにアクセスできます。 | ポッドとコンテナをマネージドインスタンスにデプロイできます。 |
| ユーザーがオペレーティングシステムとイメージ (AMI) を決定します。 | AWS によりオペレーティングシステムとイメージが決定されます。 |
| Windows または Ubuntu の機能に依存するワークロードをデプロイできます。 | Linux に基づいてコンテナをデプロイできますが、特定の OS 依存関係はありません。 |
| ユーザーが起動するインスタンスタイプとファミリーを決定します。 | AWS により起動するインスタンスタイプとファミリーが決定されます。ノードプールを使用して、EKS 自動モードl が選択するインスタンスタイプを制限できます。 |
次の機能はマネージドインスタンスとスタンダード EC2 インスタンスの両方で機能します：
+ インスタンスは AWS コンソールで表示できます。
+ インスタンスストレージはワークロードのエフェメラルストレージとして使用できます。
### AMI サポート
EKS Auto Mode では、AWS がコンピューティングノードに使用されるイメージ (AMI) を決定します。AWS は新しい EKS Auto Mode AMI バージョンのロールアウトをモニタリングします。AMI バージョンに関連するワークロードの問題が発生した場合は、サポートケースを作成します。詳細については、「AWS サポートユーザーガイド」の「[Creating support cases and case management](https://docs.aws.amazon.com/awssupport/latest/user/case-management.html)」を参照してください。
EKS の場合、通常、CVE とセキュリティ修正を含む新しい AMI が毎週リリースされます。
## EKS Auto Mode でサポートされているインスタンスリファレンス
EKS Auto Mode は、サポートされているタイプの、最小サイズ要件を満たしたインスタンスのみを作成します。
EKS 自動モードl では次のインスタンスタイプがサポートされています：
| ファミリー | インスタンスタイプ |
| --- | --- |
| コンピューティングの最適化 (C ) | c8i、c8i-flex、c8gd、c8gn、c8g、c7a、c7g、c7gn、c7gd、c7i、c7i-flex、c6a、c6g、c6i、c6gn、c6id、c6in、c6gd、c5、c5a、c5d、c5ad、c5n、c4 |
| 汎用 (M) | m8i、m8i-flex、m8a、m8gn、m8gb、m8gd、m8g、m7i、m7a、m7g、m7gd、m7i-flex、m6a、m6i、m6in、m6g、m6idn、m6id、m6gd、m5、m5a、m5ad、m5n、m5dn、m5d、m5zn、m4 |
| メモリ最適化 (R ) | r8i、r8i-flex、r8gn、r8gb、r8gd、r8g、r7a、r7iz、r7gd、r7i、r7g、r6a、r6i、r6id、r6in、r6idn、r6g、r6gd、r5、r5n、r5a、r5dn、r5b、r5ad、r5d、r4 |
| バースト可能 (T) | t4g、t3、t3a、t2 |
| ハイメモリ (Z/X) | z1d、x8g、x2gd |
| ストレージ最適化 (I/D) | i8ge、i7i、i8g、i7ie、i4g、i4i、i3、i3en、is4gen、d3、d3en、im4gn |
| 高速コンピューティング (P/G/Inf/Trn) | p5、p4d、p4de、p3、p3dn、gr6、g6、g6e、g5g、g5、g4dn、inf2、inf1、trn1、trn1n |
| ハイパフォーマンスコンピューティング (X2) | x2iezn、x2iedn、x2idn |
さらに、EKS Auto Mode は、次の要件を満たす EC2 インスタンスのみを作成します。
+ 複数の CPU
+ インスタンスサイズがナノ、マイクロ、スモールではない
詳細については、「[Amazon EC2 インスタンスタイプの命名規則](https://docs.aws.amazon.com/ec2/latest/instancetypes/instance-type-names.html)」を参照してください。
## インスタンスメタデータサービス
+ EKS Auto Mode では、デフォルトでホップ制限が 1 の IMDSv2 が実施され、AWS セキュリティのベストプラクティスに準拠します。
+ このデフォルト設定は自動モードでは変更できません。
+ 通常は IMDS アクセスが必要なアドオンの場合、IMDS ルックアップを避けるため、インストール中にパラメータ (AWS リージョンなど) を指定します。詳細については、「[Amazon EKS アドオンのためにカスタマイズできるフィールドを決定する](kubernetes-field-management.md)」を参照してください。
+ 自動モードで実行するときにポッドが IMDS アクセスを絶対に必要とする場合は、ポッドを で実行するように設定する必要があります`hostNetwork: true`。ポッドがインスタンスメタデータサービスに直接アクセスできるようになります。
+ ポッドにインスタンスメタデータへのアクセスを付与する場合、セキュリティ上の影響などを配慮してください。
Amazon EC2 インスタンスメタデータサービス (IMDS) に関する詳細については、「*Amazon EC2 ユーザーガイド*」の「[インスタンスメタデータサービスのオプション設定](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-options.html)」を参照してください。
## 考慮事項
+ NodeClass で設定されたエフェメラルストレージがインスタンスの NVMe ローカルストレージよりも小さい場合、EKS Auto Mode は次のアクションを自動的に実行することで、手動設定の必要性を排除します。
+ より小さい (20 GiB) Amazon EBS データボリュームを使用し、コストを削減します。
+ エフェメラルデータ用に NVMe ローカルストレージをフォーマットして設定します。複数の NVMe ドライブがある場合、これには RAID 0 アレイの設定が含まれます。
+ `ephemeralStorage.size` がローカルの NVMe 容量と等しいかそれより大きい場合、以下のアクションが実行されます。
+ Auto Mode では、容量の少ない EBS ボリュームはスキップされます。
+ NVMe ドライブは、ワークロードに直接公開されます。
+ Amazon EKS 自動モードは、以下の AWS Fault Injection Service アクションをサポートしていません。
+ `ec2:RebootInstances`
+ `ec2:SendSpotInstanceInterruptions`
+ `ec2:StartInstances`
+ `ec2:StopInstances`
+ `ec2:TerminateInstances`
+ `ec2:PauseVolumeIO`
+ Amazon EKS 自動モードは、AWS Fault Injection Service EKS ポッドアクションをサポートしています。詳細については「AWS レジリエンスハブユーザーガイド」の「[Fault Injection Service の実験管理](https://docs.aws.amazon.com/resilience-hub/latest/userguide/testing.html)」と「[AWS FIS aws:eks:pod アクション](https://docs.aws.amazon.com/fis/latest/userguide/eks-pod-actions.html#configure-service-account)」を参照してください。
+ EKS 自動モードl ノードに `Neuron Device Plugin` をインストールする必要はありません。
クラスター内に他のタイプのノードがある場合、自動モードのノードで実行されないように Neuron Device プラグインを設定する必要があります。詳細については「[ワークロードが EKS Auto Mode ノードにデプロイされるかどうかを制御する](associate-workload.md)」を参照してください。
# EKS Auto Mode での ID とアクセスについての説明
このトピックでは、EKS Auto Mode を使用するのに必要な Identity and Access Management (IAM) ロールとアクセス許可について説明します。EKS Auto Mode は、クラスター IAM ロールとノード IAM ロールという 2 つのプライマリ IAM ロールを使用します。これらのロールは、EKS Pod Identity および EKS アクセスエントリと連携して動作し、EKS クラスターの包括的なアクセス管理を提供します。
EKS Auto Mode を設定するときには、AWS サービスがクラスターリソースとやり取りできるようにする特定のアクセス許可を持つこれらの IAM ロールを設定する必要があります。これには、コンピューティングリソース、ストレージボリューム、ロードバランサー、ネットワーキングコンポーネントを管理するためのアクセス許可が含まれます。これらのロール設定を理解することは、適切なクラスターオペレーションおよびセキュリティに不可欠です。
EKS Auto Mode では、AWS IAM ロールは EKS アクセスエントリを介して Kubernetes アクセス許可に自動的にマッピングされるため、`aws-auth` ConfigMaps またはカスタムバインディングを手動で設定する必要はありません。新しい Auto Mode クラスターを作成すると、EKS はアクセスエントリを使用して対応する Kubernetes アクセス許可を自動的に作成し、AWS サービスとクラスターコンポーネントが AWS と Kubernetes の両方の認証システムで適切なアクセスレベルになるようにします。この自動統合により、設定の複雑さが軽減され、EKS クラスターの管理時によく発生するアクセス許可関連の問題を防ぐことができます。
## クラスター IAM ロール
クラスター IAM ロールは、Kubernetes クラスターのアクセス許可を管理するために Amazon EKS が使用する AWS Identity and Access Management (IAM) ロールです。このロールは、クラスターに代わって他の AWS サービスとやり取りするのに必要なアクセス許可を Amazon EKS に付与し、EKS アクセスエントリにより Kubernetes アクセス許可が付与されて自動的に設定されます。
+ AWS IAM ポリシーをこのロールにアタッチする必要があります。
+ EKS Auto Mode は、EKS アクセスエントリを使用して、このロールに Kubernetes アクセス許可を自動的にアタッチします。
+ EKS Auto Mode を使用する場合、AWS では AWS アカウントごとに 1 つのクラスター IAM ロールを作成することをお勧めします。
+ AWS では、このロールの名前を `AmazonEKSAutoClusterRole` とすることをお勧めします。
+ このロールには、EBS ボリューム、Elastic Load Balancer、EC2 インスタンスなどのリソースを管理するために、複数の AWS サービスに対するアクセス許可が必要です。
+ このロールの推奨設定には、EKS Auto Mode のさまざまな機能に関連する複数の AWS マネージド IAM ポリシーが含まれます。
+ `AmazonEKSComputePolicy`
+ `AmazonEKSBlockStoragePolicy`
+ `AmazonEKSLoadBalancingPolicy`
+ `AmazonEKSNetworkingPolicy`
+ `AmazonEKSClusterPolicy`
クラスター IAM ロールと AWS マネージド IAM ポリシーの詳細については、次を参照してください。
+ [Amazon Elastic Kubernetes Service に関する AWS 管理ポリシー](security-iam-awsmanpol.md)
+ [Amazon EKS クラスター の IAM ロール](cluster-iam-role.md)
Kubernetes アクセスの詳細については、次を参照してください。
+ [アクセスポリシーアクセス許可を確認する](access-policy-permissions.md)
## ノード の IAM ロール
ノード IAM ロールは、Kubernetes クラスター内のワーカーノードのアクセス許可を管理するために Amazon EKS が使用する AWS Identity and Access Management (IAM) ロールです。このロールは、Kubernetes ノードとして実行されている EC2 インスタンスに、AWS サービスおよびリソースを操作するのに必要なアクセス許可を付与し、EKS アクセスエントリにより Kubernetes RBAC アクセス許可が付与されて自動的に設定されます。
+ AWS IAM ポリシーをこのロールにアタッチする必要があります。
+ EKS Auto Mode は、EKS アクセスエントリを使用して、このロールに Kubernetes RBAC アクセス許可を自動的にアタッチします。
+ AWS では、このロールの名前を `AmazonEKSAutoNodeRole` とすることをお勧めします。
+ EKS Auto Mode を使用する場合、AWS では AWS アカウントごとに 1 つのノード IAM ロールを作成することをお勧めします。
+ このロールには制限されたアクセス許可があります。その主なアクセス許可には、Pod Identity ロールの引き受け、ECR からのイメージのプルなどがあります。
+ AWS では、以下の AWS マネージド IAM ポリシーをお勧めします。
+ `AmazonEKSWorkerNodeMinimalPolicy`
+ `AmazonEC2ContainerRegistryPullOnly`
クラスター IAM ロールと AWS マネージド IAM ポリシーの詳細については、次を参照してください。
+ [Amazon Elastic Kubernetes Service に関する AWS 管理ポリシー](security-iam-awsmanpol.md)
+ [Amazon EKS ノードの IAM ロール](create-node-role.md)
Kubernetes アクセスの詳細については、次を参照してください。
+ [アクセスポリシーアクセス許可を確認する](access-policy-permissions.md)
## サービスリンクロール
Amazon EKS は、特定のオペレーションにサービスリンクロール (SLR) を使用します。サービスにリンクされた役割はAmazon EKS に直接リンクされた一意のタイプの IAM 役割です。サービスにリンクされた役割はAmazon EKS で事前定義されています。この役割にはサービスがユーザーに代わって他の AWS のサービスを呼び出すために必要な、すべてのアクセス許可が付与されています。
AWS では SLR が自動的に作成および設定されます。先に関連リソースを削除した後にのみ、SLR を削除できます。これにより、リソースへのアクセス許可を不用意に削除することが防止され、Amazon EKS リソースが保護されます。
SLR ポリシーは、EC2 リソース (インスタンス、ネットワークインターフェイス、セキュリティグループ)、ELB リソース (ロードバランサー、ターゲットグループ)、CloudWatch 機能 (ログ記録とメトリクス)、「eks」というプレフィックスが付いた IAM ロールなどのコアインフラストラクチャコンポーネントを監視および削除する Amazon EKS アクセス許可を付与します。また、VPC/ホストゾーンの関連付けによるプライベートエンドポイントネットワーキングを有効にし、EKS タグ付きリソースの EventBridge モニタリングとクリーンアップのためのアクセス許可を備えています。
詳細については、以下を参照してください。
+ [AWS 管理ポリシー: AmazonEKSServiceRolePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-amazoneksservicerolepolicy)
+ [アマゾン EKS でのサービスにリンクされた役割のアクセス許可](using-service-linked-roles-eks.md#service-linked-role-permissions-eks)
## EKS Auto リソースのカスタム AWS タグ
デフォルトでは、EKS Auto Mode に関連するマネージドポリシーでは、ユーザー定義タグを Auto Mode でプロビジョニングされた AWS リソースに適用することはできません。ユーザー定義タグを AWS リソースに適用する場合は、AWS リソースのタグを作成および変更するのに十分なアクセス許可を持つクラスター IAM ロールに追加のアクセス許可をアタッチする必要があります。以下は、無制限のタグ付けアクセスを許可するポリシーの例です。
### カスタムタグポリシーの例を表示する
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "Compute",
"Effect": "Allow",
"Action": [
"ec2:CreateFleet",
"ec2:RunInstances",
"ec2:CreateLaunchTemplate"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:RequestTag/eks:eks-cluster-name": "${aws:PrincipalTag/eks:eks-cluster-name}"
},
"StringLike": {
"aws:RequestTag/eks:kubernetes-node-class-name": "*",
"aws:RequestTag/eks:kubernetes-node-pool-name": "*"
}
}
},
{
"Sid": "Storage",
"Effect": "Allow",
"Action": [
"ec2:CreateVolume",
"ec2:CreateSnapshot"
],
"Resource": [
"arn:aws:ec2:*:*:volume/*",
"arn:aws:ec2:*:*:snapshot/*"
],
"Condition": {
"StringEquals": {
"aws:RequestTag/eks:eks-cluster-name": "${aws:PrincipalTag/eks:eks-cluster-name}"
}
}
},
{
"Sid": "Networking",
"Effect": "Allow",
"Action": "ec2:CreateNetworkInterface",
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:RequestTag/eks:eks-cluster-name": "${aws:PrincipalTag/eks:eks-cluster-name}"
},
"StringLike": {
"aws:RequestTag/eks:kubernetes-cni-node-name": "*"
}
}
},
{
"Sid": "LoadBalancer",
"Effect": "Allow",
"Action": [
"elasticloadbalancing:CreateLoadBalancer",
"elasticloadbalancing:CreateTargetGroup",
"elasticloadbalancing:CreateListener",
"elasticloadbalancing:CreateRule",
"ec2:CreateSecurityGroup"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:RequestTag/eks:eks-cluster-name": "${aws:PrincipalTag/eks:eks-cluster-name}"
}
}
},
{
"Sid": "ShieldProtection",
"Effect": "Allow",
"Action": [
"shield:CreateProtection"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:RequestTag/eks:eks-cluster-name": "${aws:PrincipalTag/eks:eks-cluster-name}"
}
}
},
{
"Sid": "ShieldTagResource",
"Effect": "Allow",
"Action": [
"shield:TagResource"
],
"Resource": "arn:aws:shield::*:protection/*",
"Condition": {
"StringEquals": {
"aws:RequestTag/eks:eks-cluster-name": "${aws:PrincipalTag/eks:eks-cluster-name}"
}
}
}
]
}
```
## アクセスポリシーのリファレンス
EKS Auto Mode で使用される Kubernetes アクセス許可の詳細については、「[アクセスポリシーアクセス許可を確認する](access-policy-permissions.md)」を参照してください。
# EKS 自動モードl での VPC ネットワーキングとロードバランシングの説明
このトピックではEKS 自動モードl で Virtual Private クラウド (VPC ネットワーキングおよびロードバランシング機能を設定する方法について説明します。EKS Auto Mode はほとんどのネットワークコンポーネントを自動的に管理しますが、`NodeClass` リソースとロードバランサーの注釈を使用してクラスターのネットワーキング設定の特定の側面をカスタマイズできます。
EKS 自動モードl を使用すると、AWS でクラスターの VPC Container Network Interface (CNI 設定とロードバランサーのプロビジョニングが管理されます。`NodeClass` オブジェクトを定義し、サービスリソースとイングレスリソースに特定の注釈を適用することで、EKS Auto Mode が提供する自動運用モデルを維持しながら、ネットワーキング動作に関与することができます。
## ネットワーク機能
EKS Auto Mode には、ノードとポッドのネットワークを処理する新しいネットワーク機能があります。この機能は、`NodeClass` Kubernetes オブジェクトを作成することで設定できます。
以前の AWS VPC CNI の設定オプションは EKS Auto Mode には適用されません。
### `NodeClass` を使用したネットワークの設定
EKS Auto Mode の `NodeClass` リソースを使用すると、ネットワーク機能の特定の側面をカスタマイズできます。`NodeClass` を使用すると、セキュリティグループ選択の指定、VPC サブネット間のノード配置の制御、SNAT ポリシーの設定、ネットワークポリシーの設定、ネットワークイベントのログ記録の有効化を行うことができます。このアプローチはEKS 自動モードl の自動運用モデルを維持しながら、ネットワークのカスタマイズで柔軟性が得られます。
`NodeClass` を使用して以下のことができます。
+ ノードのセキュリティグループを選択する
+ VPC サブネットにノードを配置する方法を制御する
+ ノード SNAT ポリシーを `random` または `disabled` に設定する
+ 以下を含む Kubernetes *ネットワークポリシー*を有効にする。
+ ネットワークポリシーを「デフォルトで拒否」または「デフォルトで許可」に設定する
+ ファイルへのネットワークイベントのログ記録を有効にする。
+ 異なるサブネットにポッドをアタッチして、ノードトラフィックからポッドトラフィックを分離する。
[Amazon EKS ノードクラス の作成](create-node-class.md)方法を参照してください。
### 考慮事項
EKS 自動モードl は以下をサポートしています：
+ EKS ネットワークポリシー。
+ Kubernetes ポッドの `HostPort` および `HostNetwork` オプション。
+ パブリックサブネットまたはプライベートサブネットのノードとポッド。
+ ノードでの DNS クエリキャッシュ。
EKS 自動モードl は以下をサポート**していません**：
+ ポッドあたりのセキュリティグループ (SGPP)。Auto Mode で個別のセキュリティグループをポッドトラフィックに適用するには、代わりに `NodeClass` で `podSecurityGroupSelectorTerms` を使用します。詳細については、「[ポッドのサブネットとセキュリティグループを分離する](create-node-class.md#pod-subnet-selector)」を参照してください。
+ `ENIConfig` のカスタムネットワーキング。ポッドを複数のサブネットに配置することも、[ポッドのサブネットとセキュリティグループを分離する](create-node-class.md#pod-subnet-selector) を使用してノードトラフィックから排他的に分離することもできます。
+ ウォーム IP、ウォームプレフィックス、ウォーム ENI 設定。
+ 最小 IP ターゲット設定。
+ オープンソース AWS VPC CNI でサポートされているその他の設定。
+ conntrack タイマーのカスタマイズなどのネットワークポリシー設定 (デフォルトは 300 秒)。
+ CloudWatch へのネットワークイベントログのエクスポート。
### ネットワークリソース管理
EKS Auto Mode では、NodeClass リソースのネットワーク設定をモニタリングすることで、プレフィックス、IP アドレス指定、ネットワークインターフェイス管理を処理します。このサービスでは、次のいくつかの主要なオペレーションが自動的に実行されます。
**プレフィックスの委任**
EKS 自動モードは、デフォルトでポッドネットワークにプレフィックス委任 (/28 プレフィックス) を使用し、IP リソースのウォームプールを事前定義されたとおりに維持し、スケジュールされたポッドの数に基づいてスケールします。ポッドサブネットの断片化が検出されると、自動モードはセカンダリ IP アドレス (/32) をプロビジョニングします。このデフォルトのポッドネットワークアルゴリズムにより、自動モードはインスタンスタイプごとにサポートされている ENI と IP の数に基づいてノードあたりの最大ポッド数を計算します (断片化の最悪のケースを想定)。インスタンスタイプあたりの ENI と IP の最大数の詳細については、「EC2 ユーザーガイド」の「[ネットワークインターフェイスあたりの最大 IP アドレス数](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AvailableIpPerENI.html)」を参照してください。新世代 (Nitro v6 以降) のインスタンスファミリーでは通常、インスタンスタイプあたりの ENI と IP の数が増加しており、自動モードはそれに応じて最大ポッド数の計算を調整します。
IPv6 クラスターの場合、プレフィックス委任のみが使用され、自動モードは常にノードあたりのポッド数を最大 110 に制限しています。
**クールダウン管理**
このサービスでは、使用されなくなったプレフィックスまたはセカンダリ IPv4 アドレスのクールダウンプールを実装します。クールダウン期間が終了すると、これらのリソースは VPC に解放されます。ただし、こうしたリソースは、クールダウン期間にポッドで再利用されると、クールダウンプールから復元されます。
**IPv6 のサポート**
IPv6 クラスターの EKS Auto Mode では、プライマリネットワークインターフェイスのノードごとに `/80` IPv6 プレフィックスをプロビジョニングします。`podSubnetSelectorTerms` を使用する場合、プレフィックスは代わりにポッドサブネットのセカンダリネットワークインターフェイスに割り当てられます。
また、すべてのネットワークインターフェイスの適切な管理とガベージコレクションを確実に行います。
## 負荷分散
EKS 自動モードl でプロビジョニングされた AWS 弾性ロードバランサー はサービスリソースとイングレスリソースの注釈を使用して設定します。
詳細については「[IngressClass を作成して Application Load Balancer を設定する](auto-configure-alb.md)」または「[サービス注釈を使用して Network Load Balancer を設定する](auto-configure-nlb.md)」を参照してください。
### EKS 自動モードl によるロードバランシングに関する考慮事項
+ デフォルトのターゲットモードは IP モードであり、インスタンスモードではありません。
+ EKS 自動モードl はネットワークロードバランサー のセキュリティグループモードのみをサポートします。
+ AWS はセルフマネージド AWS ロードバランサーコントローラー から EKS 自動モードl による管理へのロードバランサーの移行をサポートしていません。
+ `TargetGroupBinding` 仕様の `networking.ingress.ipBlock` フィールドはサポートされていません。
+ ワーカーノードがカスタムセキュリティグループ (`eks-cluster-sg- ` 命名パターンではない) を使用している場合、クラスターロールには追加の IAM アクセス許可が必要です。デフォルトの EKS マネージドポリシーではEKS による `eks-cluster-sg-` という名前のセキュリティグループの変更のみを許可します。カスタムセキュリティグループを変更する許可がないと、EKS は ALB/NLB トラフィックがポッドに到達できるようにするのに必要な進入ルールを追加できません。
#### CoreDNS に関する考慮事項
EKS 自動モードは、クラスター内で DNS を解決する場合に、従来の CoreDNS デプロイを使用しません。代わりに、自動モードノードが、各ノードでシステムサービスとして直接実行される CoreDNS を使用します。従来のクラスターを自動モードに移行する場合、ワークロードを自動モードノードに移動したら、クラスターから CoreDNS デプロイを削除できます。
**重要**
自動モードノードと非自動モードノードの両方でクラスターを維持する場合は、CoreDNS デプロイを保持する必要があります。非自動モードノードは、自動モードが備えるノードレベルの DNS サービスにアクセスできないため、従来の CoreDNS ポッドがないと DNS を解決できません。