**このページの改善にご協力ください**
このユーザーガイドに貢献するには、すべてのページの右側のペインにある「**GitHub でこのページを編集する**」リンクを選択してください。
# Amazon EKS クラスターのネットワーキングを設定する
Amazon EKS クラスターは VPC 内に作成されます。AWS インフラストラクチャ上で実行されるノードに対しては、ポッドネットワークは Amazon VPC Container Network Interface (CNI) プラグインによって提供されます。独自のインフラストラクチャでノードを実行している場合は、「[ハイブリッドノードの CNI を設定する](hybrid-nodes-cni.md)」を参照してください。この章では、クラスターのネットワークの詳細に関する以下のトピックについて説明します。
**Topics**
+ [管理コンソールから既存の VPC サブネットを Amazon EKS クラスターに追加する](#add-existing-subnet)
+ [VPC とサブネットの Amazon EKS ネットワーキング要件を表示する](network-reqs.md)
+ [Amazon EKS クラスターの Amazon VPC を作成する](creating-a-vpc.md)
+ [クラスターの Amazon EKS セキュリティグループ要件を表示する](sec-group-reqs.md)
+ [Amazon EKS クラスターのネットワーキングアドオンを管理する](eks-networking-add-ons.md)
## 管理コンソールから既存の VPC サブネットを Amazon EKS クラスターに追加する
1. 管理コンソールでクラスターに移動します。
1. **[ネットワーキング]** タブから **[VPC リソースを管理]** を選択します。
1. **[サブネット]** ドロップダウンから、クラスターの VPC からのサブネットを追加で選択します。
新しい VPC サブネットを作成するには:
+ [EKS サブネットの要件を確認します。](network-reqs.md#network-requirements-subnets)
+ 「Amazon Virtual Private Cloud ユーザーガイド」の「[Create a Subnet](https://docs.aws.amazon.com/vpc/latest/userguide/create-subnets.html)」を参照してください。
# VPC とサブネットの Amazon EKS ネットワーキング要件を表示する
クラスターを作成する際には、[VPC](https://docs.aws.amazon.com/vpc/latest/userguide/configure-your-vpc.html) と、異なるアベイラビリティーゾーンに存在する 2 つ以上のサブネットを指定します。このトピックでは、クラスターで使用する VPC およびサブネットに関する Amazon EKS 固有の要件と考慮事項の概要について説明します。Amazon EKS で使用する VPC がない場合は、「[Amazon EKS クラスターの Amazon VPC を作成する](creating-a-vpc.md)」を参照してください。AWS Outposts でローカルクラスターまたは拡張クラスターを作成する場合は、このトピックの代わりに「[AWS Outposts で Amazon EKS クラスターの VPC とサブネットを作成する](eks-outposts-vpc-subnet-requirements.md)」を参照してください。このトピックのコンテンツは、ハイブリッドノードを持つ Amazon EKS クラスターに適用されます。ハイブリッドノードのその他のネットワーク要件については、「[ハイブリッドノード用のネットワークを準備する](hybrid-nodes-networking.md)」を参照してください。
## VPC の要件と考慮事項
クラスターを作成する際には、指定する VPC が次の要件と考慮事項を満たす必要があります。
+ VPC には、作成するクラスター、ノード、およびその他の Kubernetes リソースで利用できる十分な数の IP アドレスが必要です。使用する VPC に十分な数の IP アドレスがない場合は、使用可能な IP アドレスの数を増やしてみてください。
これを行うには、クラスター設定を更新して、クラスターが使用するサブネットとセキュリティグループを変更します。AWS マネジメントコンソール、AWS CLI の最新バージョン、AWS CloudFormation、および `eksctl` のバージョン `v0.164.0-rc.0` 以降から更新できます。クラスターバージョンを正常にアップグレードするにはこれを実行して、サブネットに利用可能な IP アドレスを増やす必要がある場合があります。
**重要**
追加するサブネットはすべて、クラスターの作成時に最初に提供したのと同じ一連の AZ 内にある必要があります。新しいサブネットは、その他のすべての要件 (例えば、十分な IP アドレスを持っている必要がある) を満たす必要があります。
例えば、1 つのクラスターを作成し、4 つのサブネットを指定したとします。指定した順序では、1 番目のサブネットは `us-west-2a` アベイラビリティーゾーンにあり、2 番目と 3 番目のサブネットは `us-west-2b` アベイラビリティーゾーンにあり、4 番目のサブネットは `us-west-2c` アベイラビリティーゾーンにあります。サブネットを変更する場合は、3 つのアベイラビリティーゾーンのそれぞれに少なくとも 1 つのサブネットを指定する必要があります。また、サブネットは元のサブネットと同じ VPC 内にある必要があります。
VPC 内の CIDR ブロックよりも多くの IP アドレスが必要な場合は、VPC に[追加の Classless Inter-Domain Routing (CIDR) ブロックを関連付ける](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-vpcs.html#add-ipv4-cidr)ことで CIDR ブロックを追加できます。クラスターの作成前または作成後に、プライベート (RFC 1918) とパブリック (非 RFC 1918) の CIDR ブロックを VPC に関連付けることができます。
新しい CIDR ブロックを追加するとすぐにそのブロックを使用するノードを追加することができます。ただし、コントロールプレーンでは調整が完了した後にのみ新しい CIDR ブロックが認識されるため、VPC に関連付けられた CIDR ブロックがクラスターで認識されるまでに最大で 1 時間かかることがあります。その後、新しい CIDR ブロック内のノードとポッドに対して、`kubectl cp`、`kubectl exec`、`kubectl attach`、`kubectl logs`、および `kubectl port-forward` コマンドを実行できます (これらのコマンドは `kubelet API` を使用します)。また、ウェブフックバックエンドとして機能するポッドがある場合は、コントロールプレーンの調整が完了するまで待機する必要があります。
+ トランジットゲートウェイ、VPC ピアリング、またはその他のネットワーク設定を介して EKS クラスターを他の VPC に接続するときは、IP アドレス範囲が重複しないようにします。CIDR 競合は、EKS クラスターのサービス CIDR が接続された VPC の CIDR と重複するときに発生します。これらのシナリオでは、ServiceIP アドレスは同じ IP アドレスを持つ接続された VPC 内のリソースよりも優先されますが、トラフィックルーティングが予測不能になり、アプリケーションが目的のリソースに接続できなくなる可能性があります。
CIDR の競合を回避するには、EKS サービス CIDR が接続された VPC CIDR と重複しないようにし、すべての CIDR 割り当ての一元化された記録を維持するようにします。CIDR の重複が発生した場合は、共有サービス VPC でトランジットゲートウェイを使用できます。詳細については、「[共有サービスによる分離された VPC](https://docs.aws.amazon.com/vpc/latest/tgw/transit-gateway-isolated-shared.html)」および「[Amazon EKS VPC routable IP address conservation patterns in a hybrid network (ハイブリッドネットワークにおける Amazon EKS VPC ルーティング可能な IP アドレス保全パターン)](https://aws.amazon.com/blogs/containers/eks-vpc-routable-ip-address-conservation)」を参照してください。また、EKS ベストプラクティスガイドの「[VPC とサブネットに関する考慮事項](https://docs.aws.amazon.com/eks/latest/best-practices/subnets.html)」ページの「VPC 間の通信」セクションを参照してください。
+ Kubernetes で `IPv6` アドレスを Pod およびサービスに割り当てる場合は、`IPv6` CIDR ブロックを VPC に関連付けます。詳細については、「Amazon VPC ユーザーガイド」の「[IPv6 CIDR ブロックと VPC の関連付け](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-vpcs.html#vpc-associate-ipv6-cidr)」を参照してください。ハイブリッドノードで実行されているポッドやサービスで `IPv6` アドレスを使用することはできません。また、`IPv6` IP アドレスファミリーで設定されたクラスターでハイブリッドノードを使用することはできません。
+ VPC は、`DNS` ホスト名と `DNS` 解決がサポートされている必要があります。そうではない場合、ノードはクラスターに登録されません。詳細については、「Amazon VPC ユーザーガイド」の「[DNS attributes for your VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html)」(VPC の DNS 属性) を参照してください。
+ VPC では、AWS PrivateLink を使用する VPC エンドポイントが必要になる場合があります。詳細については、「[サブネットの要件と考慮事項](#network-requirements-subnets)」を参照してください。
Kubernetes `1.14` 以前でクラスターを作成した場合、Amazon EKS は次のタグを VPC に追加しています。
| キー | 値 |
| --- | --- |
| `kubernetes.io/cluster/my-cluster ` | `owned` |
このタグは Amazon EKS でのみ使用されています。サービスに影響を与えずに、このタグを削除できます。このタグは、バージョン `1.15` 以降のクラスターでは使用されません。
## サブネットの要件と考慮事項
クラスターを作成すると、Amazon EKS は、指定したサブネットに 2～4 つの [Elastic Network Interface](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html) を作成します。これらのネットワークインターフェイスは、クラスターと VPC 間の通信を可能にします。これらのネットワークインターフェイスでは、`kubelet API` を使用する Kubernetes の機能も有効化されます。`kubelet` API への接続は、`kubectl attach`、`kubectl cp`、`kubectl exec`、`kubectl logs`、`kubectl port-forward` の各コマンドで使用されます。Amazon EKS が作成した各ネットワークインターフェイスの説明には、テキスト `Amazon EKS cluster-name ` が書き込まれます。
Amazon EKS は、クラスターの作成時に指定した任意のサブネットにネットワークインターフェイスを作成することができます。クラスターの作成後に、Amazon EKS がネットワークインターフェイスを作成するサブネットを変更できます。クラスターの Kubernetes バージョンを更新すると、Amazon EKS は作成した元のネットワークインターフェイスを削除し、新しいネットワークインターフェイスを作成します。これらのネットワークインターフェイスは、元のネットワークインターフェイスと同じサブネット内に作成することも、元のネットワークインターフェイスとは異なるサブネット内に作成することもできます。ネットワークインターフェイスを作成するサブネットを制御する場合は、クラスターを作成するとき、またはクラスターの作成後にサブネットを更新するときに、指定するサブネットの数を 2 つだけに制限します。
### クラスターのサブネットの要件
クラスターの作成または更新時に指定する[サブネット](https://docs.aws.amazon.com/vpc/latest/userguide/configure-subnets.html#subnet-types)は、次の要件を満たす必要があります。
+ サブネットには、Amazon EKS での使用のために、それぞれ 6 個以上の IP アドレスが必要です。ただし、IP アドレスは 16 個以上を推奨します。
+ サブネットは、少なくとも 2 つの異なるアベイラビリティーゾーンに存在している必要があります。
+ サブネットは AWS Outposts または AWS Wavelength 内に存在できません。ただし、VPC 内にサブネットが存在する場合は、セルフマネージド型ノードおよび Kubernetes のリソースをこれらのタイプのサブネットにデプロイできます。セルフマネージド型ノードの詳細については、「[セルフマネージドノードでノードを自分自身で維持する](worker.md)」を参照してください。
+ サブネットは、パブリックでもプライベートでもかまいません。ただし、可能であれば、プライベートサブネットを指定することをお勧めします。パブリックサブネットは、[インターネットゲートウェイ](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html)へのルートが含まれているルートテーブルを含むサブネットです。一方、プライベートサブネットは、インターネットゲートウェイへのルートが含まれていないルートテーブルを含むサブネットです。
+ サブネットは以下のアベイラビリティーゾーンには配置できません。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/eks/latest/userguide/network-reqs.html)
### 各コンポーネントの IP アドレスファミリー使用状況
以下の表に、Amazon EKS の各コンポーネントで使用される IP アドレスファミリーを示します。ネットワークアドレス変換 (NAT) またはその他の互換システムを使用すると、表の値が「No」のファミリーに属する送信元 IP アドレスから、これらのコンポーネントに接続できます。
機能は、クラスターの IP ファミリー (`ipFamily`) 設定によって異なる場合があります。この設定は、Kubernetes がサービスに割り当てる CIDR ブロックに使用される IP アドレスのタイプを変更します。設定値が IPv4 のクラスターは *IPv4 クラスター*と呼ばれ、設定値が IPv6 のクラスターは *IPv6 クラスター*と呼ばれます。
| コンポーネント | IPv4 アドレス | IPv6 アドレス | デュアルスタックアドレス |
| --- | --- | --- | --- |
| EKS API パブリックエンドポイント | あり1、3 | あり1、3 | あり1、3 |
| EKS API VPC エンドポイント | はい | なし | 不可 |
| EKS Auth API パブリックエンドポイント (EKS Pod Identity) | はい 1 | はい 1 | はい 1 |
| EKS Auth API VPC エンドポイント (EKS Pod Identity) | はい 1 | はい 1 | はい 1 |
| `IPv4` Kubernetes クラスターパブリックエンドポイント2 | はい | なし | 不可 |
| `IPv4` Kubernetes クラスタープライベートエンドポイント2 | はい | なし | 不可 |
| `IPv6` Kubernetes クラスターパブリックエンドポイント2 | はい 1、4 | はい 1、4 | はい 4 |
| `IPv6` Kubernetes クラスタープライベートエンドポイント2 | はい 1、4 | はい 1、4 | はい 4 |
| Kubernetes クラスターサブネット | あり2 | 不可 | はい 2 |
| ノードのプライマリ IP アドレス | あり2 | 不可 | はい 2 |
| サービス IP アドレスのクラスター CIDR 範囲 | はい 2 | あり2 | 不可 |
| VPC CNI による Pod IP アドレス | はい 2 | あり2 | 不可 |
| IRSA OIDC 発行者 URL | あり1、3 | あり1、3 | あり1、3 |
**注記**
1 エンドポイントは、`IPv4` アドレスと `IPv6` アドレスの両方を持つデュアルスタックです。AWS 外部のアプリケーション、クラスターのノード、およびクラスター内のポッドは、`IPv4` または `IPv6` のいずれかによってこのエンドポイントに到達できます。
2 クラスターの作成時に、クラスターの IP ファミリー (`ipFamily`) 設定で `IPv4` クラスターと `IPv6` クラスターのどちらかを選択します。これは後から変更できません。代わりに、他のクラスターを作成してワークロードを移行する際は、別の設定を選択する必要があります。
3 デュアルスタックエンドポイントは、2024 年 8 月に導入されました。AWS CLI でデュアルスタックエンドポイントを使用するには、「*AWS SDK およびツールリファレンスガイド*」の「[デュアルスタックと FIPS エンドポイント](https://docs.aws.amazon.com/sdkref/latest/guide/feature-endpoints.html)」の設定を参照してください。新しいエンドポイントを次に示します:
**EKS API パブリックエンドポイント**
`eks.region.api.aws`
**IRSA OIDC 発行者 URL**
`oidc-eks.region.api.aws`
4 デュアルスタッククラスターエンドポイントは、2024 年 10 月に導入されました。EKS は、この日より後に作成され、クラスターの IP ファミリー (ipFamily ) 設定で `IPv6` を選択した新しいクラスターに次のエンドポイントを作成します。
**EKS クラスターパブリック／プライベートエンドポイント**
`eks-cluster.region.api.aws`
### ノードのサブネットの要件
クラスターの作成時に指定するのと同じサブネットに、ノードと Kubernetes リソースをデプロイできます。ただし、これは必須ではありません。これは、クラスターの作成時に指定しなかったサブネットにもノードと Kubernetes リソースをデプロイできるためです。ノードを異なるサブネットにデプロイする場合、Amazon EKS は、それらのサブネットにクラスターネットワークインターフェイスを作成しません。ノードと Kubernetes リソースをデプロイするサブネットは、次の要件を満たす必要があります。
+ サブネットには、すべてのノードと Kubernetes リソースをデプロイするのに十分な数の使用可能な IP アドレスが必要です。
+ Kubernetes で `IPv6` アドレスを Pod およびサービスに割り当てる場合は、サブネットに関連付けられている `IPv6` CIDR ブロックと `IPv4` CIDR ブロックをそれぞれ 1 つずつ指定する必要があります。詳細については、「Amazon VPC ユーザーガイド」の「[IPv6 CIDR ブロックをサブネットに関連付ける](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-subnets.html#subnet-associate-ipv6-cidr)」を参照してください。サブネットに関連付けられているルートテーブルには、`IPv4` および `IPv6` のアドレスへのルートを含める必要があります。詳細については、「Amazon VPC ユーザーガイド」の「[Routes](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Route_Tables.html#route-table-routes)」(ルート) を参照してください。ポッドに割り当てられるのは `IPv6` アドレスのみです。ただし、Amazon EKS がクラスターとノード用に作成するネットワークインターフェイスには、`IPv4` および `IPv6` のアドレスが割り当てられます。
+ インターネットから Pod へのインバウンドアクセスが必要な場合は、ロードバランサーのデプロイおよびインバウンドトラフィック (イングレス) に十分な数の IP アドレスを利用できるパブリックサブネットが少なくとも 1 つあることを必ず確認してください。パブリックサブネットにロードバランサーをデプロイできます。ロードバランサーは、プライベートサブネットまたはパブリックサブネット内の Pod への負荷分散を行います。可能であれば、プライベートサブネットにノードをデプロイすることをお勧めします。
+ ノードをパブリックサブネットにデプロイする場合は、サブネットが `IPv4` パブリックアドレスまたは `IPv6` アドレスを自動割り当てする必要があります。ノードを `IPv6` CIDR ブロックが関連付けられているプライベートサブネットにデプロイする場合、プライベートサブネットも `IPv6` アドレスを自動割り当てする必要があります。2020 年 3 月 26 日以降に Amazon EKS が提供する AWS CloudFormation テンプレートを使用して VPC をデプロイした場合、この設定は有効になっています。テンプレートを使用してこの日付より前に VPC をデプロイした場合、または独自の VPC を使用した場合は、この設定を手動で有効にする必要があります。テンプレートについては、「[Amazon EKS クラスターの Amazon VPC を作成する](creating-a-vpc.md)」を参照してください。詳細については、「[Amazon VPC ユーザーガイド](https://docs.aws.amazon.com/vpc/latest/userguide/)」の「[サブネットのパブリック IPv4 アドレス指定属性を変更する](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-subnets.html#subnet-public-ip)」および「[サブネットの IPv6 アドレス指定属性を変更する](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-subnets.html#subnet-ipv6)」を参照してください。
+ ノードをデプロイするサブネットがプライベートサブネットであり、そのルートテーブルにネットワークアドレス変換 [(NAT) デバイス](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat.html) (`IPv4`) または [Egress-Only ゲートウェイ](https://docs.aws.amazon.com/vpc/latest/userguide/egress-only-internet-gateway.html) (`IPv6`) へのルートが含まれていない場合は、AWS PrivateLink を使用して VPC エンドポイントを VPC に追加します。VPC エンドポイントは、ノードと Pod が通信を行う必要があるすべての AWS サービスで必要になります。例としては、Amazon ECR、Elastic Load Balancing、Amazon CloudWatch、AWS Security Token Service、Amazon Simple Storage Service (Amazon S3) などがあります。エンドポイントには、ノードが存在するサブネットを含める必要があります。すべての AWS で VPC エンドポイントがサポートされているわけではありません。詳細については、「[AWS PrivateLink とは](https://docs.aws.amazon.com/vpc/latest/privatelink/what-is-privatelink.html)」および「[AWS PrivateLink と統合する AWS サービス](https://docs.aws.amazon.com/vpc/latest/privatelink/aws-services-privatelink-support.html)」を参照してください。Amazon EKS のその他の要件のリストについては、「[インターネットアクセスが制限されたプライベートクラスターをデプロイする](private-clusters.md)」を参照してください。
+ ロードバランサーをサブネットにデプロイする場合は、サブネットに次のタグが必要です。
+ プライベートサブネット
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/eks/latest/userguide/network-reqs.html)
+ パブリックサブネット
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/eks/latest/userguide/network-reqs.html)
バージョン `1.18` 以前の Kubernetes クラスターが作成された場合、Amazon EKS は指定したすべてのサブネットに次のタグを追加します。
| キー | 値 |
| --- | --- |
| `kubernetes.io/cluster/my-cluster ` | `shared` |
ここで新しい Kubernetes クラスターを作成した場合、Amazon EKS はサブネットにタグを追加しません。`1.19` より前のバージョンのクラスターが使用していたサブネットにタグがあった場合、クラスターが新しいバージョンに更新されても、タグはサブネットから自動的に削除されませんでした。AWS Load Balancer Controller のバージョン `2.1.1` 以前では、このタグが必要です。新しいバージョンの Load Balancer Controller を使用している場合は、サービスを中断することなくタグを削除できます。コントローラーの詳細については、「[AWS Load Balancer Controller を使用してインターネットトラフィックをルーティングする](aws-load-balancer-controller.md)」を参照してください。
`eksctl` または Amazon EKS AWS CloudFormation VPC テンプレートのいずれかを使用して VPC をデプロイした場合、次が適用されます。
+ **2020 年 3 月 26 日以降** - パブリック `IPv4` アドレスは、パブリックサブネットにより、パブリックサブネットにデプロイした新しいノードに自動的に割り当てられます。
+ **2020 年 3 月 26 日より前** - パブリック `IPv4` アドレスは、パブリックサブネットにより、パブリックサブネットにデプロイした新しいノードに自動的に割り当てられません。
この変更は、パブリックサブネットにデプロイされた新しいノードグループに、次のような影響を与えます。
+ **[マネージドノードグループ](create-managed-node-group.md)** - 2020 年 4 月 22 日以降にノードグループをパブリックサブネットにデプロイした場合は、パブリックサブネットでパブリック IP アドレスの自動割り当てを有効にする必要があります。詳細については「[サブネットの IPv4 アドレス指定属性の変更](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html#subnet-public-ip)」を参照してください。
+ **[Linux](launch-workers.md)、[Windows](launch-windows-workers.md)、または [Arm](eks-optimized-ami.md#arm-ami) のセルフマネージドノードグループ** - 2020 年 3 月 26 日以降にノードグループをパブリックサブネットにデプロイした場合は、パブリックサブネットでパブリック IP アドレスの自動割り当てを有効にする必要があります。それ以外の場合は、代わりにパブリック IP アドレスを使用してノードを起動する必要があります。詳細については、「[サブネットのパブリック IPv4 アドレス指定属性の変更](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html#subnet-public-ip)」または「[インスタンス起動時のパブリック IPv4 アドレスの割り当て](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html#vpc-public-ip)」を参照してください。
## 共有サブネットの要件と考慮事項
*VPC 共有*を使用して、同じ AWS 組織内でサブネットを他の AWS アカウントと共有できます。共有サブネットに Amazon EKS クラスターを作成できますが、以下の考慮事項に注意してください。
+ VPC サブネットの所有者は、参加者アカウントで Amazon EKS クラスターを作成する前に、そのアカウントとサブネットを共有する必要があります。
+ VPC のデフォルトセキュリティグループは所有者に属しているため、デフォルトのセキュリティグループを使用してリソースを起動することはできません。さらに、参加者は、他の参加者または所有者が所有するセキュリティグループを使用してリソースを起動することはできません。
+ 共有サブネットでは、参加者と所有者がそれぞれのアカウント内のセキュリティグループを個別に管理します。サブネットの所有者は、参加者が作成したセキュリティグループを表示できますが、これらのグループに対してアクションを実行することはできません。サブネットの所有者がこれらのセキュリティグループの削除または変更を希望する場合は、セキュリティグループを作成した参加者がそのアクションを実行する必要があります。
+ 参加者がクラスターを作成する場合、以下の考慮事項が適用されます。
+ クラスター IAM ロールとノード IAM ロールは、そのアカウントで作成する必要があります。詳細については、「[Amazon EKS クラスター の IAM ロール](cluster-iam-role.md)」および「[Amazon EKS ノードの IAM ロール](create-node-role.md)」を参照してください。
+ 管理対象ノードグループを含め、すべてのノードは同じ参加者が作成する必要があります。
+ 共有 VPC の所有者は、参加者が共有サブネット内に作成したクラスターを表示、更新、削除することはできません。これは、アカウントごとに異なるアクセス権を持つ VPC リソースに加えて適用されます。詳細については、「*Amazon VPC ユーザーガイド*」の「[所有者および参加者の責任と権限](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-sharing.html#vpc-share-limitations)」を参照してください。
+ Amazon VPC CNI plugin for Kubernetes の*カスタムネットワーク*機能を使用する場合、所有者アカウントに記載されているアベイラビリティーゾーン ID マッピングを使用して、それぞれの `ENIConfig` を作成する必要があります。詳細については、「[カスタムネットワーキングを使用して代替サブネットに Pod をデプロイする](cni-custom-network.md)」を参照してください。
VPC サブネット共有の詳細については、「*Amazon VPC ユーザーガイド*」の「[VPC を他のアカウントと共有する](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-sharing.html#vpc-share-limitations)」を参照してください。
# Amazon EKS クラスターの Amazon VPC を作成する
Amazon Virtual Private Cloud (Amazon VPC) を使用すると、定義した仮想ネットワーク内で AWS リソースを起動できます。この仮想ネットワークは、お客様自身のデータセンターで運用されている従来のネットワークによく似ています。ただし、Amazon Web Services のスケーラブルなインフラストラクチャを使用できるというメリットがあります。本番用に使う Amazon EKS クラスターをデプロイする前に、Amazon VPC サービスを十分に理解しておくことをお勧めします。詳細については、[Amazon VPC ユーザーガイド](https://docs.aws.amazon.com/vpc/latest/userguide/)を参照してください。
Amazon EKS クラスター、ノード、および Kubernetes リソースが VPC にデプロイされます。Amazon EKS で既存の VPC を使用する場合は、その VPC が「[VPC とサブネットの Amazon EKS ネットワーキング要件を表示する](network-reqs.md)」に記載されている要件を満たしている必要があります。このトピックでは、Amazon EKS に用意されている AWS CloudFormation テンプレートを使用して Amazon EKS 要件を満たす VPC を作成する方法について説明します。テンプレートをデプロイすると、テンプレートによって作成されたリソースを表示して、作成されたリソースとそれらのリソースの設定を正確に把握できます。ハイブリッドノードを使用している場合、VPC のルートテーブルにオンプレミスネットワークへのルートが含まれている必要があります。ハイブリッドノードのネットワーク要件の詳細については、「[ハイブリッドノード用のネットワークを準備する](hybrid-nodes-networking.md)」を参照してください。
## 前提条件
Amazon EKS 用の VPC を作成するには、Amazon VPC リソースを作成するのに必要な IAM アクセス許可が必要です。これらのリソースは、VPC、サブネット、セキュリティグループ、ルートテーブルとルート、およびインターネットと NAT ゲートウェイです。詳細については、「Amazon VPC ユーザーガイド」の「[パブリックサブネットを持つ VPC を作成するポリシー例](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-policy-examples.html#vpc-public-subnet-iam)」を参照してください。完全なリストについては、「[サービス認可リファレンス](https://docs.aws.amazon.com/service-authorization/latest/reference/reference.html)」の「[アクション](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonec2.html#amazonec2-actions-as-permissions)」を参照してください。
パブリックサブネットとプライベートサブネット、パブリックサブネットのみ、またはプライベートサブネットのみで、VPC を作成できます。
## パブリックサブネットおよびプライベートサブネット
この VPC には、2 つのパブリックサブネットと 2 つのプライベート サブネットがあります。パブリックサブネットの関連付けられているルートテーブルには、インターネットゲートウェイへのルートが含まれています。一方、プライベートサブネットのルートテーブルには、インターネットゲートウェイへのルートがありません。1 つのパブリックサブネットと 1 つのプライベートサブネットが同じ[アベイラビリティーゾーン](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html#concepts-regions-availability-zones)にデプロイされます。他のパブリックサブネットとプライベートサブネットは、同じ AWS リージョン内の 2 番目のアベイラビリティーゾーンにデプロイされます。ほとんどのデプロイにこのオプションをお勧めします。
このオプションを使用すると、プライベートサブネットにノードをデプロイできます。このオプションでは、Kubernetes がパブリックサブネットにロードバランサーをデプロイできるようにします。これにより、プライベートサブネットのノードで実行されている Pod へのトラフィックの負荷を分散できます。パブリック `IPv4` アドレスは、パブリックサブネットにデプロイされたノードに自動的に割り当てられます。一方、プライベートサブネットにデプロイされたノードに対しては、パブリック `IPv4` アドレスは割り当てられません。
また、パブリックサブネットおよびプライベートサブネットに置かれたノードに対し、`IPv6` アドレスを割り当てることもできます。プライベートサブネット内のノードは、クラスターや他の AWS サービスとの通信が可能です。Pod は、各アベイラビリティーゾーンにデプロイされた NAT ゲートウェイ (`IPv4` アドレスを使用) または送信専用インターネットゲートウェイ (`IPv6` アドレスを使用) を介して、インターネットへの通信が可能です。クラスターまたはノード以外のソースからのすべてのインバウンドトラフィックを拒否するが、すべてのアウトバウンドトラフィックを許可するルールを持つセキュリティグループがデプロイされます。サブネットには、Kubernetes がロードバランサーをデプロイできるようにタグが付けられています。
1. [AWS CloudFormation コンソール](https://console.aws.amazon.com/cloudformation/)を開きます。
1. ナビゲーションバーで、Amazon EKS をサポートする AWS リージョンを選択します。
1. **[スタックの作成]** を選択し、**[新しいリソースの使用 (標準)]** を選択します。
1. **[Prerequisite - Prepare template]** (前提条件 – テンプレートの準備) の下で、**[Template is ready]** (テンプレートの準備完了) がオンになっていることを確認した上で、**[Specify template]** (テンプレートの指定) の下で、**[Amazon S3 URL]** を選択します。
1. `IPv4` のみをサポートする VPC、または `IPv4` と `IPv6` をサポートする VPC を作成できます。下記の URL の 1 つを **[Amazon S3 URL]** の下にあるテキスト領域に貼り付けて、**[Next]** (次へ) をクリックします。
+ `IPv4`
```
https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2020-10-29/amazon-eks-vpc-private-subnets.yaml
```
+ `IPv4` および `IPv6`
```
https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2020-10-29/amazon-eks-ipv6-vpc-public-private-subnets.yaml
```
1. **[Specify stack details]** (スタック詳細の指定) ページで、パラメータを入力し、**[Next]** (次へ) を選択します。
+ **スタック名**: AWS CloudFormation スタックのスタック名を選択します。例えば、前のステップで使用されたテンプレート名を使用できます。この名前には英数字 (大文字と小文字が区別されます) とハイフンのみを使用できます。先頭の文字は英数字である必要があります。また、100 文字より長くすることはできません。名前は、クラスターを作成する AWS リージョンおよび AWS アカウント内で一意である必要があります。
+ **[VpcBlock]**: VPC の `IPv4` CIDR 範囲を選択します。デプロイする各ノード、ポッド、およびロードバランサーには、このブロックの `IPv4` アドレスが割り当てられます。デフォルトの `IPv4` 値で、ほとんどの実装において十分な IP アドレスを取得できますが、不足する場合はこの値を変更できます。詳細については、「Amazon VPC ユーザーガイド」の「[VPC とサブネットのサイズ設定](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Subnets.html#VPC_Sizing)」を参照してください。VPC を作成したら、追加の CIDR ブロックを VPC に追加することもできます。`IPv6` VPC を作成する場合、`IPv6` CIDR 範囲は Amazon のグローバルユニキャストアドレススペースから自動的に割り当てられます。
+ **[PublicSubnet01Block]**: パブリックサブネット 1 の `IPv4` CIDR ブロックを指定します。デフォルト値は、ほとんどの実装で十分な IP アドレスを提供しますが、そうでない場合は、変更することができます。`IPv6` VPC を作成する場合、テンプレートで指定済みブロックを使用できます。
+ **[PublicSubnet02Block]**: パブリックサブネット 2 の `IPv4` CIDR ブロックを指定します。デフォルト値は、ほとんどの実装で十分な IP アドレスを提供しますが、そうでない場合は、変更することができます。`IPv6` VPC を作成する場合、テンプレートで指定済みブロックを使用できます。
+ **[PrivateSubnet01Block]**: プライベートサブネット 1 の `IPv4` CIDR ブロックを指定します。デフォルト値は、ほとんどの実装で十分な IP アドレスを提供しますが、そうでない場合は、変更することができます。`IPv6` VPC を作成する場合、テンプレートで指定済みブロックを使用できます。
+ **[PrivateSubnet02Block]**: プライベートサブネット 2 の `IPv4` CIDR ブロックを指定します。デフォルト値は、ほとんどの実装で十分な IP アドレスを提供しますが、そうでない場合は、変更することができます。`IPv6` VPC を作成する場合、テンプレートで指定済みブロックを使用できます。
1. (オプション) **[Configure stack options]** (スタックオプションの設定) ページで、スタックリソースにタグ付けを行った上で、**[Next]** (次へ) をクリックします。
1. **[確認]** ページで **[スタックの作成]** を選択します。
1. スタックが作成されたら、コンソールで選択し、**[Outputs]** (出力) を選択します。
1. 作成された VPC の **[VpcId]** を記録します。これは、クラスターとノードを作成するときに必要です。
1. 作成されたサブネットの **SubnetIds** と、それらをパブリックサブネットとプライベートサブネットのどちらとして作成したかを記録します。クラスターとノードを作成するときは、これらのうち少なくとも 2 つが必要です。
1. `IPv4` VPC を作成している場合、この手順をスキップしてください。`IPv6` VPC を作成している場合は、テンプレートによって作成されたパブリックサブネットにおいて、`IPv6` アドレスの自動割り当てオプションが有効化されている必要があります。この設定は、プライベートサブネットに対してすでに有効になっています。次の手順を完了して、設定を有効にします。
1. Amazon VPC コンソールの https://console.aws.amazon.com/vpc/ を開いてください。
1. 左のナビゲーションペインで **[Subnets]** (サブネット) を選択します。
1. パブリックサブネット (** *stack-name*/SubnetPublic01** または ** *stack-name*/SubnetPublic02** には、**public** という語が含まれています) の 1 つを選択し、**[Actions]** (アクション)、**[Edit subnet settings]** (サブネット設定の編集) の順に選択します。
1. **[Enable auto-assign IPv6 address]** (IPv6 アドレスの自動割り当てを有効にする) チェックボックスをオンにし、**[Save]** (保存) をクリックします。
1. 他のパブリックサブネットに対しても、ここまでの手順を再度実行します。
## パブリックサブネットのみ
この VPC には、AWS リージョン内の異なるアベイラビリティーゾーンにデプロイされる 3 つのパブリックサブネットがあります。すべてのノードには自動的にパブリック `IPv4` アドレスが割り当てられ、[インターネットゲートウェイ](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html)を介してインターネットトラフィックを送受信できます。すべてのインバウンドトラフィックを拒否し、すべてのアウトバウンドトラフィックを許可する[セキュリティグループ](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html)がデプロイされます。サブネットには、Kubernetes がロードバランサーをデプロイできるようにタグが付けられています。
1. [AWS CloudFormation コンソール](https://console.aws.amazon.com/cloudformation/)を開きます。
1. ナビゲーションバーで、Amazon EKS をサポートする AWS リージョンを選択します。
1. **[Create stack]** (スタックの作成) を選択し、**[With new resources (standard)]** (新しいリソースの使用 (標準)) を選択します。
1. **[テンプレートの準備]** の下で、**[テンプレートの準備完了]** が選択されていることを確認し、**[テンプレートソース]** の下で、**[Amazon S3 URL]** を選択します。
1. 次の URL を **[Amazon S3 URL]** の下のテキスト領域に貼り付けて、**[次へ]** を選択します。
```
https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2020-10-29/amazon-eks-vpc-sample.yaml
```
1. **[Specify Details]** (詳細の指定) ページで、パラメータを入力し、**[Next]** (次へ) を選択します。
+ **スタック名**: AWS CloudFormation スタックのスタック名を選択します。例えば、*amazon-eks-vpc-sample* という名前にすることができます。この名前には英数字 (大文字と小文字が区別されます) とハイフンのみを使用できます。先頭の文字は英数字である必要があります。また、100 文字より長くすることはできません。名前は、クラスターを作成する AWS リージョンおよび AWS アカウント内で一意である必要があります。
+ **[VpcBlock]**: VPC の CIDR ブロックを選択します。デプロイする各ノード、ポッド、およびロードバランサーには、このブロックの `IPv4` アドレスが割り当てられます。デフォルトの `IPv4` 値で、ほとんどの実装において十分な IP アドレスを取得できますが、不足する場合はこの値を変更できます。詳細については、「Amazon VPC ユーザーガイド」の「[VPC とサブネットのサイズ設定](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Subnets.html#VPC_Sizing)」を参照してください。VPC を作成したら、追加の CIDR ブロックを VPC に追加することもできます。
+ **Subnet01Block**: サブネット 1 の CIDR ブロックを指定します。デフォルト値は、ほとんどの実装で十分な IP アドレスを提供しますが、そうでない場合は、変更することができます。
+ **Subnet02Block**: サブネット 2 の CIDR ブロックを指定します。デフォルト値は、ほとんどの実装で十分な IP アドレスを提供しますが、そうでない場合は、変更することができます。
+ **Subnet03Block**: サブネット 3 の CIDR ブロックを指定します。デフォルト値は、ほとんどの実装で十分な IP アドレスを提供しますが、そうでない場合は、変更することができます。
1. (オプション) **[オプション]** ページで、スタックリソースをタグ付けします。[**次へ**] を選択します。
1. [**Review**] ページで、[**Create **] を選択します。
1. スタックが作成されたら、コンソールで選択し、**[Outputs]** (出力) を選択します。
1. 作成された VPC の **[VpcId]** を記録します。これは、クラスターとノードを作成するときに必要です。
1. 作成されたサブネットの **[SubnetIds]** を記録します。クラスターとノードを作成するときは、これらのうち少なくとも 2 つが必要です。
1. (オプション) この VPC にデプロイするクラスターは、Pod とサービスにプライベート `IPv4` アドレスを割り当てることができます。この VPC にクラスターをデプロイし、Pod とサービスにプライベート `IPv6` アドレスを割り当てる場合は、VPC、サブネット、ルートテーブル、およびセキュリティグループを更新します。詳細については、「Amazon VPC ユーザーガイド」の「[既存の VPC を IPv4 から IPv6 に移行する](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-migrate-ipv6.html)」を参照してください。Amazon EKS では、サブネットにおいて、`IPv6` アドレスの `Auto-assign` オプションが有効化されている必要があります。デフォルトでは、このオプションは無効となっています。
## プライベートサブネットのみ
この VPC には、AWS リージョン内の異なるアベイラビリティーゾーンにデプロイされる 3 つのプライベートサブネットがあります。サブネットにデプロイされたリソースはインターネットにアクセスできず、インターネットからサブネット内のリソースにアクセスすることもできません。ノードが通常アクセスする必要があるいくつかの AWS サービスの AWS PrivateLink を使用して、[VPC エンドポイント](https://docs.aws.amazon.com/vpc/latest/privatelink/privatelink-access-aws-services.html)がテンプレートによって作成されます。ノードにアウトバウンドインターネットアクセスが必要な場合は、VPC が作成された後で、各サブネットのアベイラビリティーゾーン内に、パブリック [NAT ゲートウェイ](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html)を追加できます。[セキュリティグループ](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html)は、サブネットにデプロイされたリソースからのトラフィックを除き、すべてのインバウンドトラフィックを拒否するように作成されます。また、セキュリティグループは、すべてのアウトバウンドトラフィックを許可します。サブネットには、Kubernetes が内部ロードバランサーをデプロイできるようにタグが付けられています。この設定で VPC を作成する場合は、「[インターネットアクセスが制限されたプライベートクラスターをデプロイする](private-clusters.md)」を参照してその他の要件と考慮事項を確認してください。
1. [AWS CloudFormation コンソール](https://console.aws.amazon.com/cloudformation/)を開きます。
1. ナビゲーションバーで、Amazon EKS をサポートする AWS リージョンを選択します。
1. **[Create stack]** (スタックの作成) を選択し、**[With new resources (standard)]** (新しいリソースの使用 (標準)) を選択します。
1. **[テンプレートの準備]** の下で、**[テンプレートの準備完了]** が選択されていることを確認し、**[テンプレートソース]** の下で、**[Amazon S3 URL]** を選択します。
1. 次の URL を **[Amazon S3 URL]** の下のテキスト領域に貼り付けて、**[次へ]** を選択します。
```
https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2020-10-29/amazon-eks-fully-private-vpc.yaml
```
1. **[詳細の指定]** ページでパラメータを入力し、**[次へ]** を選択します。
+ **スタック名**: AWS CloudFormation スタックのスタック名を選択します。例えば、*amazon-eks-fully-private-vpc* という名前にすることができます。この名前には英数字 (大文字と小文字が区別されます) とハイフンのみを使用できます。先頭の文字は英数字である必要があります。また、100 文字より長くすることはできません。名前は、クラスターを作成する AWS リージョンおよび AWS アカウント内で一意である必要があります。
+ **[VpcBlock]**: VPC の CIDR ブロックを選択します。デプロイする各ノード、ポッド、およびロードバランサーには、このブロックの `IPv4` アドレスが割り当てられます。デフォルトの `IPv4` 値で、ほとんどの実装において十分な IP アドレスを取得できますが、不足する場合はこの値を変更できます。詳細については、「Amazon VPC ユーザーガイド」の「[VPC とサブネットのサイズ設定](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Subnets.html#VPC_Sizing)」を参照してください。VPC を作成したら、追加の CIDR ブロックを VPC に追加することもできます。
+ **PrivateSubnet01Block**: サブネット 1 の CIDR ブロックを指定します。デフォルト値は、ほとんどの実装で十分な IP アドレスを提供しますが、そうでない場合は、変更することができます。
+ **PrivateSubnet02Block**: サブネット 2 の CIDR ブロックを指定します。デフォルト値は、ほとんどの実装で十分な IP アドレスを提供しますが、そうでない場合は、変更することができます。
+ **PrivateSubnet03Block**: サブネット 3 の CIDR ブロックを指定します。デフォルト値は、ほとんどの実装で十分な IP アドレスを提供しますが、そうでない場合は、変更することができます。
1. (オプション) **[オプション]** ページで、スタックリソースをタグ付けします。[**次へ**] を選択します。
1. [**Review**] ページで、[**Create **] を選択します。
1. スタックが作成されたら、コンソールで選択し、**[Outputs]** (出力) を選択します。
1. 作成された VPC の **[VpcId]** を記録します。これは、クラスターとノードを作成するときに必要です。
1. 作成されたサブネットの **[SubnetIds]** を記録します。クラスターとノードを作成するときは、これらのうち少なくとも 2 つが必要です。
1. (オプション) この VPC にデプロイするクラスターは、Pod とサービスにプライベート `IPv4` アドレスを割り当てることができます。この VPC にクラスターをデプロイし、Pod とサービスにプライベート `IPv6` アドレスを割り当てる場合は、VPC、サブネット、ルートテーブル、およびセキュリティグループを更新します。詳細については、「Amazon VPC ユーザーガイド」の「[既存の VPC を IPv4 から IPv6 に移行する](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-migrate-ipv6.html)」を参照してください。Amazon EKS は、サブネットで `Auto-assign IPv6` アドレスオプションが有効になっている必要があります (デフォルトでは無効)。
# クラスターの Amazon EKS セキュリティグループ要件を表示する
このトピックでは、Amazon EKS クラスターのセキュリティグループの要件について説明します。
## デフォルトのクラスターセキュリティグループ
クラスターを作成すると、Amazon EKS により `eks-cluster-sg-my-cluster-uniqueID ` という名前のセキュリティグループが作成されます。セキュリティグループには、デフォルトで次のルールがあります。
| ルールタイプ | プロトコル | ポート | 送信元 | 目的地 |
| --- | --- | --- | --- | --- |
| インバウンド | すべて | すべて | 自分 | |
| アウトバウンド | すべて | すべて | | 0.0.0.0/0 (`IPv4`) または ::/0 (`IPv6`) |
| アウトバウンド | すべて | すべて | | 自分 (EFA トラフィック用) |
デフォルトのセキュリティグループには、同じセキュリティグループの宛先に対して Elastic Fabric Adapter (EFA) トラフィックを許可するアウトバウンドルールが含まれます。これにより、クラスター内の EFA トラフィックが有効になり、AI/ML およびハイパフォーマンスコンピューティング (HPC) ワークロードに役立てることができます。詳細については、「*Amazon Elastic Compute Cloud ユーザーガイド*」の「[Amazon EC2 の AI/ML および HPC ワークロード用の Elastic Fabric Adapter](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa.html)」を参照してください。
**重要**
クラスターに `0.0.0.0/0` (IPv4)、`::/0` (IPv6) へのアウトバウンドルールが必要ない場合は、削除できます。削除する場合でも、「[クラスタートラフィックの制限](#security-group-restricting-cluster-traffic)」に記載されている最低限のルールが適用されます。クラスターセキュリティグループ自体との間のトラフィックを許可するインバウンドルールまたはアウトバウンドルールを削除すると、クラスターが更新されるたびに Amazon EKS によって再作成されます。
Amazon EKS は次のタグをセキュリティグループに追加します。タグを削除した場合、Amazon EKS はクラスターが更新されるたびにこれらのタグをセキュリティグループに追加します。
| キー | 値 |
| --- | --- |
| `kubernetes.io/cluster/my-cluster ` | `owned` |
| `aws:eks:cluster-name` | *my-cluster* |
| `Name` | `eks-cluster-sg-my-cluster-uniqueid ` |
Amazon EKS は、同様に作成される次のリソースに、セキュリティグループを自動的に関連付けます。
+ 2—4 エラスティックネットワークインターフェイス (これ以降、ネットワークインターフェイス) は、クラスターの作成時に作成されます。
+ 作成したマネージドノードグループ内のノードのネットワークインターフェイス。
デフォルトのルールでは、すべてのトラフィックがクラスターとノード間で自由に行き来することができます。また、任意の送信先へのすべてのアウトバウンドトラフィックが許可されています。クラスターを作成すると、オプションで独自のセキュリティグループを指定できます。その場合、Amazon EKS は、指定したセキュリティグループをクラスター用に作成するネットワークインターフェイスにも関連付けます。ただし、作成したノードグループには関連付けられません。
クラスターのセキュリティグループの ID は、AWS マネジメントコンソール のクラスターの **[Networking]** (ネットワーキング) セクションで確認できます。もしくは、次の AWS CLI コマンドを実行して確認できます。
```
aws eks describe-cluster --name my-cluster --query cluster.resourcesVpcConfig.clusterSecurityGroupId
```
## クラスタートラフィックの制限
EKS コントロールプレーンとノード間で開いているポートの数を制限する必要がある場合は、[デフォルトのアウトバウンドルール](#security-group-default-rules) `0.0.0.0/0` (IPv4)/`::/0` (IPv6) を削除し、クラスターに必要な以下の最小限のルールを追加できます。
送信元がセルフとなるすべてのトラフィック (クラスターセキュリティグループからのトラフィック) を許可する[デフォルトのインバウンドルール](#security-group-default-rules)を削除した場合、クラスターが更新されると Amazon EKS によって再作成されます。
送信先がセルフとなるすべてのトラフィック (クラスターセキュリティグループへのトラフィック) を許可する[デフォルトのアウトバウンドルール](#security-group-default-rules)を削除した場合、クラスターが更新されると Amazon EKS によって再作成されます。
| ルールタイプ | プロトコル | ポート | 目的地 |
| --- | --- | --- | --- |
| アウトバウンド | TCP | 443 | クラスターセキュリティグループ |
| アウトバウンド | TCP | 10250 | クラスターセキュリティグループ |
| アウトバウンド (DNS) | TCP と UDP | 53 | クラスターセキュリティグループ |
次のトラフィックにもルールを追加する必要があります。
+ ノード間通信にノードが使用するプロトコルおよびポート。
+ アウトバウンドのインターネットアクセス。これによりノードが Amazon EKS API にアクセス可能になり、起動時のノードの登録やクラスターの詳細分析が行えます。ノードがインターネットにアクセスできない場合は、「[インターネットアクセスが制限されたプライベートクラスターをデプロイする](private-clusters.md)」でその他の考慮事項を参照してください。
+ Amazon ECR や、イメージをプルする必要があるその他のコンテナレジストリ (DockerHub など) からコンテナイメージをプルするためのノードのアクセス。詳細については、「AWS 全般のリファレンス」の「[AWS IP アドレス範囲](https://docs.aws.amazon.com/general/latest/gr/aws-ip-ranges.html)」を参照してください。
+ Amazon S3 へのノードのアクセス。
+ `IPv4` や `IPv6` アドレスが必要な個別のルール。
+ ハイブリッドノードを使用している場合は、クラスターに追加のセキュリティグループを追加して、オンプレミスのノードやポッドとの通信を許可する必要があります。詳細については、「[ハイブリッドノード用のネットワークを準備する](hybrid-nodes-networking.md)」を参照してください。
ルールの制限を検討している場合は、変更したルールを本番稼働用のクラスターに適用する前に、すべての Pod を徹底的にテストすることをお勧めします。
最初に Kubernetes `1.14` およびプラットフォームバージョン `eks.3` またはそれ以前でクラスターを最初にデプロイした場合、次の点を考慮してください。
+ コントロールプレーンおよびノードセキュリティグループがある場合もあります。これらのグループの作成時、前の表に示した制限付きルールが含まれていました。これらのセキュリティグループは不要で、削除できます。ただし、それらのグループに含まれるルールがクラスターセキュリティグループに含まれていることを確認する必要があります。
+ API を使用してクラスターを直接デプロイした場合、または AWS CLI や AWS CloudFormation などのツールを使用してクラスターを作成しており、クラスター作成時にセキュリティグループを指定しなかった場合、Amazon EKS が作成したクラスターネットワークインターフェイスに VPC のデフォルトのセキュリティグループが適用されます。
## 共有セキュリティグループ
Amazon EKS は、共有セキュリティグループをサポートしています。
+ **[セキュリティグループの VPC 関連付け]** により、セキュリティグループは同じアカウントとリージョン内の複数の VPC に関連付けられます。
+ 「*Amazon VPC ユーザーガイド*」で、[セキュリティグループを複数の VPC に関連付ける](https://docs.aws.amazon.com/vpc/latest/userguide/security-group-assoc.html)方法をご覧ください。
+ **[共有セキュリティグループ]** を使用すると、セキュリティグループを他の AWS アカウントと共有できます。アカウントは同じ AWS 組織内にある必要があります。
+ 「*Amazon VPC ユーザーガイド*」で、[セキュリティグループを組織と共有する](https://docs.aws.amazon.com/vpc/latest/userguide/security-group-sharing.html)方法をご覧ください。
+ セキュリティグループは常に 1 つの AWS リージョンに制限されます。
### Amazon EKS の考慮事項
+ EKS には、標準セキュリティグループと同じ共有セキュリティグループまたはマルチ VPC セキュリティグループの要件があります。
# Amazon EKS クラスターのネットワーキングアドオンを管理する
Amazon EKS クラスターで使用できるネットワーキングアドオンがいくつかあります。
## 組み込みアドオン
**注記**
**EKS クラスターを作成するとき:**
**AWS コンソールの使用**: 組み込みアドオン (CoreDNS や kube-proxy など) は Amazon EKS アドオンとして自動的にインストールされます。これらは、AWS コンソール、CLI、SDK を介して簡単に設定および更新できます。
**他の方法の使用** (CLI や SDK など): 通常の Kubernetes デプロイとして実行されるセルフマネージドバージョンと同じ組み込みアドオンがインストールされます。AWS ツールで管理できないため、手動で設定および更新が必要です。
アドオン管理を簡素化し、AWS サービスを通じて一元化された設定および更新を有効にするには、セルフマネージドバージョンではなく、Amazon EKS アドオンを使用することをお勧めします。
**Amazon VPC CNI plugin for Kubernetes**
この CNI アドオンは、Elastic Network Interface を作成し、Amazon EC2 ノードにアタッチします。このアドオンは、VPC からプライベート `IPv4` または `IPv6` アドレスを各 Pod およびサービスにも割り当てます。このアドオンはデフォルトでクラスターにインストールされます。詳細については、「[Amazon VPC CNI を使用して Pod に IP を割り当てる](managing-vpc-cni.md)」を参照してください。ハイブリッドノードを使用している場合、VPC CNI はデフォルトでインストールされますが、アンチアフィニティルールによりハイブリッドノード上での実行が防止されます。ハイブリッドノードの CNI オプションの詳細については、「[ハイブリッドノードの CNI を設定する](hybrid-nodes-cni.md)」を参照してください。
**CoreDNS**
CoreDNS は、Kubernetes クラスター DNS として機能する、フレキシブルで拡張可能な DNS サーバーです。CoreDNS により、クラスター内にあるすべての Pod の名前が解決されます。このアドオンはデフォルトでクラスターにインストールされます。詳細については、「[Amazon EKS クラスターで DNS の CoreDNS を管理する](managing-coredns.md)」を参照してください。
** `kube-proxy` **
このアドオンは、Amazon EC2 ノード上のネットワークルールを維持し、Pod へのネットワーク通信を可能にします。このアドオンはデフォルトでクラスターにインストールされます。詳細については、「[Amazon EKS クラスターで `kube-proxy` を管理する](managing-kube-proxy.md)」を参照してください。
## オプションの AWS ネットワークアドオン
** AWS Load Balancer Controller**
`loadbalancer` タイプの Kubernetes サービスオブジェクトをデプロイするとき、コントローラーは AWS Network Load Balancer を作成します。Kubernetes 入力オブジェクトを作成するとき、コントローラーは AWS Application Load Balancer を作成します。Network Load Balancer のプロビジョニングには、Kubernetes に組み込まれている[従来のクラウドプロバイダー](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/guide/service/annotations/#legacy-cloud-provider)コントローラーではなく、このコントローラーを使用することをお勧めします。詳細については、[AWS Load Balancer Controller](https://kubernetes-sigs.github.io/aws-load-balancer-controller) ドキュメントを参照してください。
** AWSゲートウェイ API コントローラー**
このコントローラーを使用すると、[Kubernetes ゲートウェイ API](https://gateway-api.sigs.k8s.io/) を使用して複数の Kubernetes クラスターを通してサービスに接続できます。コントローラーは、[Amazon VPC Lattice](https://docs.aws.amazon.com/vpc-lattice/latest/ug/what-is-vpc-service-network.html) サービスを使用して Amazon EC2 インスタンス、コンテナ、サーバーレス機能で実行されている Kubernetes サービスを接続します。詳細については、「[AWS ゲートウェイ API コントローラー](https://www.gateway-api-controller.eks.aws.dev/)」ドキュメントを参照してください。
アドオンの詳細については、「[Amazon EKS アドオン](eks-add-ons.md)」を参照してください。
# Amazon VPC CNI を使用して Pod に IP を割り当てる
**ヒント**
今後開催予定の Amazon EKS ワークショップに[登録](https://aws-experience.com/emea/smb/events/series/get-hands-on-with-amazon-eks?trk=4a9b4147-2490-4c63-bc9f-f8a84b122c8c&sc_channel=el)してください。
**ヒント**
Amazon EKS 自動モード ではネットワーク形成のアドオンをインストールまたはアップグレードする必要はありません。自動モード にはポッドのネットワーク形成とロードバランシング機能が含まれています。
詳細については、「[EKS Auto Mode を使用してクラスターインフラストラクチャを自動化する](automode.md)」を参照してください。
Amazon VPC CNI plugin for Kubernetes アドオンは、Amazon EKS クラスター内の各 Amazon EC2 ノードにデプロイされます。アドオンは [エラスティックネットワークインターフェイス](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html) を作成し、Amazon EC2 ノードにアタッチします。また、アドオンは VPC のプライベート `IPv4` アドレスまたは `IPv6` アドレスを各 Pod に割り当てます。
アドオンのバージョンはクラスター内の各 Fargate ノードにデプロイされますが、Fargate ノードでは更新しません。Amazon EKS クラスターではその他の互換性のある CNI プラグインも使用できますが、これは AWS インフラストラクチャで動作するノード用の Amazon EKS がサポートする唯一の CNI プラグインです。互換性のある他の CNI プラグインの詳細については「[Amazon EKS クラスターの代替 CNI プラグイン](alternate-cni-plugins.md)」を参照してください。VPC CNI はハイブリッドノードでの使用はサポートされていません。ハイブリッドノードの CNI オプションの詳細については「[ハイブリッドノードの CNI を設定する](hybrid-nodes-cni.md)」を参照してください。
次の表は、Kubernetes バージョンごとに Amazon EKS アドオンタイプの最新バージョンを示しています。
## Amazon VPC CNI のバージョン
| Kubernetes バージョン | Amazon EKS タイプの VPC CNI バージョン |
| --- | --- |
| 1.35 | v1.21.1-eksbuild.5 |
| 1.34 | v1.21.1-eksbuild.5 |
| 1.33 | v1.21.1-eksbuild.5 |
| 1.32 | v1.21.1-eksbuild.5 |
| 1.31 | v1.21.1-eksbuild.5 |
| 1.30 | v1.21.1-eksbuild.5 |
| 1.29 | v1.21.1-eksbuild.5 |
**重要**
このアドオンを自己管理している場合、表のバージョンは利用可能なセルフマネージドバージョンと同じではない可能性があります。このアドオンのセルフマネージドタイプの更新の詳細については「[Amazon VPC CNI の更新 (セルフマネージド型アドオン)](vpc-add-on-self-managed-update.md)」を参照してください。
**重要**
VPC CNI v1.12.0 以降にアップグレードするにはまず VPC CNI v1.7.0 にアップグレードする必要があります。一度に 1 つのマイナーバージョンを更新することをお勧めします。
## 考慮事項
この機能を使用する際の考慮事項を次に示します。
+ バージョンは `major-version.minor-version.patch-version-eksbuild.build-number` として指定されます。
+ 各機能のバージョン互換性を確認します。Amazon VPC CNI plugin for Kubernetes の各リリースに含まれる機能によっては、特定の Kubernetes バージョンが必要になることがあります。異なる Amazon EKS の機能を使用する際、アドオンの特定のバージョンが必要な場合については機能に関するドキュメントに記載されています。以前のバージョンを実行する特定の理由がある場合を除いて、最新のバージョンを実行することをお勧めします。
# Amazon VPC CNI Amazon EKS アドオンの追加します。
次のステップを使用して、Amazon VPC CNI Plugin for Kubernetes の Amazon EKS アドオンを作成します。
開始する前に、考慮事項を確認してください。詳細については、「[考慮事項](managing-vpc-cni.md#manage-vpc-cni-add-on-on-considerations)」を参照してください。
## 前提条件
以下は、Amazon VPC CNI Plugin for Kubernetes の Amazon EKS アドオンの前提条件です。
+ 既存の Amazon EKS クラスター。デプロイするには「[Amazon EKS の使用を開始する](getting-started.md)」を参照してください。
+ クラスターの既存の AWS Identity and Access Management (IAM) OpenID Connect (OIDC) プロバイダー。既に存在しているかどうかを確認する、または作成するには「[クラスターの IAM OIDC プロバイダーを作成するには](enable-iam-roles-for-service-accounts.md)」を参照してください。
+ [AmazonEKS\$1CNI\$1Policy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKS_CNI_Policy.html) IAM ポリシー (クラスターが `IPv4` ファミリーを使用している場合)、または IPv6 ポリシー (クラスターが `IPv6` ファミリーを使用している場合) がアタッチされた IAM 役割です。VPC CNI 役割の詳細については、「[IRSA を使用するように Amazon VPC CNI プラグインを設定する](cni-iam-role.md)」を参照してください。IPv6 ポリシーの詳細については、「[`IPv6` ファミリーを使用するクラスター用に IAM ポリシーを作成します。](cni-iam-role.md#cni-iam-role-create-ipv6-policy)」を参照してください。
**重要**
Amazon VPC CNI Plugin for Kubernetes バージョン`v1.16.0` から `v1.16.1` では、CNI 仕様バージョン `v1.0.0` が実装されています。バージョン `v1.0.0` のCNI 仕様の詳細については、GitHub の「[Container Network Interface (CNI) Specification](https://github.com/containernetworking/cni/blob/spec-v1.0.0/SPEC.md)」を参照してください。
## 手順
前提条件を満たしたら、次のステップを使用してアドオンを作成します。
1. クラスターにインストールされているアドオンのバージョンを確認します。
```
kubectl describe daemonset aws-node --namespace kube-system | grep amazon-k8s-cni: | cut -d : -f 3
```
出力例は次のとおりです。
```
v1.16.4-eksbuild.2
```
1. クラスターにインストールされているアドオンのタイプを確認します。クラスターを作成するために使用したツールによっては、現在クラスターに Amazon EKS アドオンタイプがインストールされていない場合があります。*マイクラスター* の部分は、自分のクラスター名に置き換えます。
```
aws eks describe-addon --cluster-name my-cluster --addon-name vpc-cni --query addon.addonVersion --output text
```
バージョン番号が返された場合、Amazon EKS タイプのアドオンがクラスターにインストールされているため、このステップの残りのステップを完了する必要はありません。エラーが返された場合、クラスターに Amazon EKS タイプのアドオンがインストールされていません。インストールするには、このステップの残りのステップを完了します。
1. 現在インストールされているアドオンの設定を保存します。
```
kubectl get daemonset aws-node -n kube-system -o yaml > aws-k8s-cni-old.yaml
```
1. AWS CLI を使用してアドオンを作成します。AWS マネジメントコンソール または `eksctl` を使用してアドオンを作成する場合は、「[Amazon EKS アドオンを作成する](creating-an-add-on.md)」を参照して、アドオン名の `vpc-cni` を指定します。デバイスに沿ったコマンドをコピーします。必要に応じてコマンドに次の変更を加え、変更したコマンドを実行してください。
+ *マイクラスター* の部分は、自分のクラスター名に置き換えます。
+ *v1.20.3-eksbuild.1* を、使用しているクラスターバージョンに対して最新バージョンの表に記載されている最新バージョンに置き換えます。最新バージョンの表については、「[Amazon VPC CNI のバージョン](managing-vpc-cni.md#vpc-cni-latest-available-version)」を参照してください。
+ *111122223333* を、アカウント ID に置き換えて、*AmazonEKSVPCCNIRole* を作成した[既存の IAM 役割](cni-iam-role.md#cni-iam-role-create-role)の名前に置き換えます。ロールを指定するには、クラスター用に IAM OpenID Connect (OIDC) プロバイダーが必要です。クラスター用に持っているかどうかを確認、あるいは作成するには、「[クラスターの IAM OIDC プロバイダーを作成するには](enable-iam-roles-for-service-accounts.md)」を参照してください。
```
aws eks create-addon --cluster-name my-cluster --addon-name vpc-cni --addon-version v1.20.3-eksbuild.1 \
--service-account-role-arn arn:aws:iam::111122223333:role/AmazonEKSVPCCNIRole
```
Amazon EKS アドオンのデフォルト設定と競合するカスタム設定を現在のアドオンに適用した場合、作成が失敗する可能性があります。作成に失敗した場合、問題解決に役立つエラーが表示されます。または、前のコマンドに `--resolve-conflicts OVERWRITE` を追加することもできます。これにより、アドオンは既存のカスタム設定を上書きできます。アドオンを作成したら、カスタム設定で更新できます。
1. クラスターの Kubernetes バージョン用のアドオンの最新バージョンがクラスターに追加されたことを確認します。*マイクラスター* の部分は、自分のクラスター名に置き換えます。
```
aws eks describe-addon --cluster-name my-cluster --addon-name vpc-cni --query addon.addonVersion --output text
```
アドオンの作成が完了するまでに数秒かかる場合があります。
出力例は次のとおりです。
```
v1.20.3-eksbuild.1
```
1. 元のアドオンに対してカスタム設定を行った場合は、Amazon EKS アドオンを作成する前に、前のステップで保存した設定を使用して、カスタム設定で EKS アドオンを更新します。「[Amazon VPC CNI を更新する (Amazon EKS アドオン)](vpc-add-on-update.md)」のステップを実行してください。
1. (オプション)`cni-metrics-helper` をクラスターにインストールします。メトリクスヘルパーは、ネットワークインターフェイスと IP アドレス情報を収集し、クラスターレベルでメトリクスを集計し、メトリクスを Amazon CloudWatch に発行するために使用できるツールです。詳細については[GitHub の CNI](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/cmd/cni-metrics-helper/README.md) を参照してください。
# Amazon VPC CNI を更新する (Amazon EKS アドオン)
Amazon EKS タイプの Amazon VPC CNI Plugin for Kubernetes アドオンを更新します。Amazon EKS タイプのアドオンをクラスターに追加していない場合は「[Amazon VPC CNI Amazon EKS アドオンの追加します。](vpc-add-on-create.md)」に従ってインストールできます。または「[Amazon VPC CNI の更新 (セルフマネージド型アドオン)](vpc-add-on-self-managed-update.md)」に従って他のタイプの VPC CNI インストールを更新します。
1. クラスターにインストールされているアドオンのバージョンを確認します。*マイクラスター* の部分は自分のクラスター名に置き換えます。
```
aws eks describe-addon --cluster-name my-cluster --addon-name vpc-cni --query "addon.addonVersion" --output text
```
出力例は次のとおりです。
```
v1.20.0-eksbuild.1
```
バージョンを [Amazon VPC CNI のバージョン](managing-vpc-cni.md#vpc-cni-latest-available-version) の最新バージョンの表と比較します。返されたバージョンが、最新バージョンの表にあるクラスターの Kubernetes バージョンのバージョンと同じである場合は既に最新バージョンがクラスターにインストールされているため、この手順の残りを完了する必要はありません。出力にバージョン番号ではなくエラーが表示される場合はAmazon EKS タイプのアドオンがクラスターにインストールされていません。この手順でアドオンを更新する前に、アドオンを作成する必要があります。VPC CNI アドオンの Amazon EKS タイプを作成するには「[Amazon VPC CNI Amazon EKS アドオンの追加します。](vpc-add-on-create.md)」に従います。
1. 現在インストールされているアドオンの設定を保存します。
```
kubectl get daemonset aws-node -n kube-system -o yaml > aws-k8s-cni-old.yaml
```
1. AWS CLI を使用してアドオンを更新します。AWS マネジメントコンソール または `eksctl` を使用してアドオンを更新する場合は「[Amazon EKS アドオンを更新する](updating-an-add-on.md)」を参照してください。デバイスに沿ったコマンドをコピーします。必要に応じてコマンドに次の変更を加え、変更したコマンドを実行してください。
+ *マイクラスター* の部分は、自分のクラスター名に置き換えます。
+ *v1.20.0-eksbuild.1* を、使用しているクラスターバージョンに対して最新バージョンの表に記載されている最新バージョンに置き換えます。
+ *111122223333* を、アカウント ID に置き換えます。また、*AmazonEKSVPCCNIRole* を、作成した既存の IAM 役割の名前に置き換えます。VPC CNI の IAM 役割を作成するには「[ステップ 1: Amazon VPC CNI plugin for Kubernetes の IAM ロールを作成する](cni-iam-role.md#cni-iam-role-create-role)」を参照してください。ロールを指定するには、クラスター用に IAM OpenID Connect (OIDC) プロバイダーが必要です。クラスター用に持っているかどうかを確認、あるいは作成するには「[クラスターの IAM OIDC プロバイダーを作成するには](enable-iam-roles-for-service-accounts.md)」を参照してください。
+ `--resolve-conflicts PRESERVE` オプションはアドオンの既存の設定値を保存します。アドオン設定にカスタム値を設定していて、このオプションを使用しない場合、Amazon EKS は値をデフォルト値で上書きします。このオプションを使用する場合、実稼働クラスターのアドオンを更新する前に、非稼動クラスターのフィールドおよび値変更をテストすることをお勧めします。この値を `OVERWRITE` に変更する場合、すべての設定が Amazon EKS のデフォルト値に変更されます。いずれかの設定にカスタム値を設定した場合、Amazon EKS のデフォルト値で上書きされる可能性があります。この値を `none` に変更した場合、Amazon EKS は設定の値を一切変更しませんが、更新が失敗する可能性があります。更新に失敗した場合、競合の解決に役立つエラーメッセージが返されます。
+ 構成設定を更新しない場合はコマンドから `--configuration-values '{"env":{"AWS_VPC_K8S_CNI_EXTERNALSNAT":"true"}}'` を削除します。構成設定を更新する場合は*"env":\$1"AWS\$1VPC\$1K8S\$1CNI\$1EXTERNALSNAT":"true"\$1* を、希望する設定に置き換えます。この例では`AWS_VPC_K8S_CNI_EXTERNALSNAT` 環境変数は `true` に設定されています。指定する値は設定スキーマに対して有効である必要があります。設定スキーマが不明である場合は `aws eks describe-addon-configuration --addon-name vpc-cni --addon-version v1.20.0-eksbuild.1 ` を実行して、*v1.20.0-eksbuild.1* を、設定を表示するアドオンのバージョン番号に置き換えます。出力でスキーマが返されます。既存のカスタム設定があり、それをすべて削除してすべての設定の値を Amazon EKS のデフォルトに戻したい場合はコマンドから *"env":\$1"AWS\$1VPC\$1K8S\$1CNI\$1EXTERNALSNAT":"true"\$1* を削除して、`{}` が空になるようにします。各設定の説明についてはGitHub の「[CNI 設定変数](https://github.com/aws/amazon-vpc-cni-k8s#cni-configuration-variables)」を参照してください。
```
aws eks update-addon --cluster-name my-cluster --addon-name vpc-cni --addon-version v1.20.3-eksbuild.1 \
--service-account-role-arn arn:aws:iam::111122223333:role/AmazonEKSVPCCNIRole \
--resolve-conflicts PRESERVE --configuration-values '{"env":{"AWS_VPC_K8S_CNI_EXTERNALSNAT":"true"}}'
```
更新が完了するまでに数秒かかる場合があります。
1. アドオンのバージョンが更新されたことを確認します。*マイクラスター* の部分は自分のクラスター名に置き換えます。
```
aws eks describe-addon --cluster-name my-cluster --addon-name vpc-cni
```
更新が完了するまでに数秒かかる場合があります。
出力例は次のとおりです。
```
{
"addon": {
"addonName": "vpc-cni",
"clusterName": "my-cluster",
"status": "ACTIVE",
"addonVersion": "v1.20.3-eksbuild.1",
"health": {
"issues": []
},
"addonArn": "arn:aws:eks:region:111122223333:addon/my-cluster/vpc-cni/74c33d2f-b4dc-8718-56e7-9fdfa65d14a9",
"createdAt": "2023-04-12T18:25:19.319000+00:00",
"modifiedAt": "2023-04-12T18:40:28.683000+00:00",
"serviceAccountRoleArn": "arn:aws:iam::111122223333:role/AmazonEKSVPCCNIRole",
"tags": {},
"configurationValues": "{\"env\":{\"AWS_VPC_K8S_CNI_EXTERNALSNAT\":\"true\"}}"
}
}
```
## トラブルシューティング
VPC CNI を v1.13.2 より前のバージョンからアップグレードする場合は、更新後にクラスター内のすべてのノードを置き換える必要があります。v1.13.2 より前のバージョンでは、iptables-legacy バックエンドを使用して、ソース NAT (SNAT) などの適切な機能に必要な iptables ルールを挿入します。
バージョン v1.13.2 は、[iptables-wrapper を導入](https://github.com/aws/amazon-vpc-cni-k8s/pull/2402)した重要なリリースであり、チェーンとルールを挿入するための適切な iptables バックエンド (iptables-legacy または iptables-nft) を自動的に検出します。この変更は、パフォーマンスの制限によりレガシーバックエンドから離れるというアップストリーム Kubernetes の決定方針と一致しています。
VPC CNI を v1.13.2 より前のバージョンからアップグレードした場合、ノードを置き換える必要があります。これは、iptables-legacy バックエンドと iptables-nft バックエンドの両方にルールを導入すると、プライマリ以外の ENI から発生するトラフィックに予期しない動作が生じる可能性があるためです。
# Amazon VPC CNI の更新 (セルフマネージド型アドオン)
**重要**
セルフマネージド型のアドオンを使用する代わりに、Amazon EKS タイプのアドオンをクラスターに追加することをお勧めします。タイプの違いがよくわからない場合は「[Amazon EKS アドオン](eks-add-ons.md)」を参照してください。Amazon EKS アドオンをクラスターに追加する方法については「[Amazon EKS アドオンを作成する](creating-an-add-on.md)」を参照してください。Amazon EKS アドオンを使用できない場合はその理由に関する問題を[コンテナロードマップ GitHub リポジトリ](https://github.com/aws/containers-roadmap/issues)に送信することをお勧めします。
1. Amazon EKS タイプのアドオンがクラスターにインストールされていないことを確認します。*マイクラスター* の部分は自分のクラスター名に置き換えます。
```
aws eks describe-addon --cluster-name my-cluster --addon-name vpc-cni --query addon.addonVersion --output text
```
エラーメッセージが返された場合、クラスターに Amazon EKS タイプのアドオンがインストールされていません。アドオンを自己管理するにはこの手順の残りのステップを完了してアドオンを更新します。バージョン番号が返された場合、クラスターに Amazon EKS タイプのアドオンがインストールされています。更新するにはこの手順を使用するのではなく、「[Amazon EKS アドオンを更新する](updating-an-add-on.md)」の手順を使用してください。アドオンタイプの違いがよくわからない場合は「[Amazon EKS アドオン](eks-add-ons.md)」を参照してください。
1. クラスターに現在インストールされているコンテナイメージのバージョンを確認します。
```
kubectl describe daemonset aws-node --namespace kube-system | grep amazon-k8s-cni: | cut -d : -f 3
```
出力例は次のとおりです。
```
v1.20.0-eksbuild.1
```
出力にビルド番号が含まれていない場合があります。
1. 現在の設定をバックアップして、バージョンを更新した後も同じ設定を構成できるようにします。
```
kubectl get daemonset aws-node -n kube-system -o yaml > aws-k8s-cni-old.yaml
```
利用可能なバージョンを確認し、更新するバージョンの変更について理解するには、GitHub の「[Releases](https://github.com/aws/amazon-vpc-cni-k8s/releases)」を参照してください。新しいバージョンが GitHub で利用できる場合でも、利用可能な最新バージョンの表に記載されている同じ `major`.`minor`.`patch` バージョンに更新することをお勧めします。利用可能な最新バージョンの表については「[Amazon VPC CNI のバージョン](managing-vpc-cni.md#vpc-cni-latest-available-version)」を参照してください。表に記載されているビルドバージョンはGitHub に記載されているセルフマネージドバージョンでは指定されていません。次のオプションのいずれかでタスクを完了して、バージョンを更新します。
+ アドオンのカスタム設定がない場合は更新先の[リリース](https://github.com/aws/amazon-vpc-cni-k8s/releases)の GitHub の `To apply this release:` の見出しの下にあるコマンドを実行してください。
+ カスタム設定がある場合は次のコマンドを実行してマニフェストファイルをダウンロードします。*https://raw.githubusercontent.com/aws/amazon-vpc-cni-k8s/v1.20.0/config/master/aws-k8s-cni.yaml* を、更新先の GitHub 上のリリースの URL に変更します。
```
curl -O https://raw.githubusercontent.com/aws/amazon-vpc-cni-k8s/v1.20.3/config/master/aws-k8s-cni.yaml
```
必要に応じて、前のステップで作成したバックアップのカスタム設定でマニフェストを変更し、変更したマニフェストをクラスターに適用します。ノードがイメージの取得元のプライベート Amazon EKS Amazon ECR リポジトリにアクセスできない場合 (マニフェストの `image:` で始まる行を参照)、イメージをダウンロードして自分のリポジトリにコピーし、リポジトリからイメージを取得するようにマニフェストを変更する必要があります。詳細については「[あるリポジトリから別のリポジトリにコンテナイメージをコピーする](copy-image-to-repository.md)」を参照してください。
```
kubectl apply -f aws-k8s-cni.yaml
```
1. 新しいバージョンがクラスターにインストールされたことを確認します。
```
kubectl describe daemonset aws-node --namespace kube-system | grep amazon-k8s-cni: | cut -d : -f 3
```
出力例は次のとおりです。
```
v1.20.3
```
1. (オプション)`cni-metrics-helper` をクラスターにインストールします。メトリクスヘルパーは、ネットワークインターフェイスと IP アドレス情報を収集し、クラスターレベルでメトリクスを集計し、メトリクスを Amazon CloudWatch に発行するために使用できるツールです。詳細については[GitHub の CNI](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/cmd/cni-metrics-helper/README.md) を参照してください。
# IRSA を使用するように Amazon VPC CNI プラグインを設定する
[Amazon VPC CNI plugin for Kubernetes](https://github.com/aws/amazon-vpc-cni-k8s) は、Amazon EKS クラスター内の Pod ネットワーキング用のネットワークプラグインです。プラグインは Kubernetes ポッドに VPC IP アドレスを割り当て、各ノードのポッドに必要なネットワークを設定する役割を果たしています。
**注記**
Amazon VPC CNI プラグインは、Amazon EKS Pod Identity もサポートしています。詳細については、「[IAM ロールを Kubernetes サービスアカウントに割り当てる](pod-id-association.md)」を参照してください。
プラグイン:
+ AWS アイデンティティとアクセス管理 (IAM のアクセス許可が必要です。クラスターが `IPv4` ファミリーを使用する場合、このアクセス許可は、[https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKS_CNI_Policy.html](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKS_CNI_Policy.html) AWS 管理ポリシーで指定されます。クラスターが `IPv6` ファミリーを使用する場合には、作成した IAM ポリシーにアクセス許可を追加する必要があります。手順については、「[`IPv6` ファミリーを使用するクラスター用に IAM ポリシーを作成します。](#cni-iam-role-create-ipv6-policy)」を参照してください。このポリシーはAmazon EKS ノード IAM ロール または 個別の IAM ロールにアタッチすることができます。Amazon EKS ノード IAM ロールにポリシーをアタッチする手順については「[Amazon EKS ノードの IAM ロール](create-node-role.md)」を参照してください。このトピックで詳細に説明するように、別のロールに割り当てることをお勧めします。
+ デプロイ時に作成すると、`aws-node` という名前の Kubernetes サービスアカウントを使用するように設定されます。サービスアカウントは `aws-node` という名前の Kubernetes `clusterrole` にバインドされます。これには、必要な Kubernetes アクセス許可が割り当てられています。
**注記**
IMDS へのアクセスをブロックする場合を除き、Amazon VPC CNI plugin for Kubernetes 用の Pod には、[Amazon EKS ノード IAM ロール](create-node-role.md)に割り当てられたパーミッションへのアクセス権があります。詳細については「[ワーカーノードに割り当てられたインスタンスプロファイルへのアクセスを制限する](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node)」を参照してください。
+ 既存の Amazon EKS クラスターが必要です。デプロイするには「[Amazon EKS の使用を開始する](getting-started.md)」を参照してください。
+ クラスターに、既存の AWS Identity and Access Management (IAM) OpenID Connect (OIDC) プロバイダーが必要です。既に存在しているかどうかを確認する、または作成するには「[クラスターの IAM OIDC プロバイダーを作成するには](enable-iam-roles-for-service-accounts.md)」を参照してください。
## ステップ 1: Amazon VPC CNI plugin for Kubernetes の IAM ロールを作成する
1. クラスターで使用する IP ファミリを決定します。
```
aws eks describe-cluster --name my-cluster | grep ipFamily
```
出力例は次のとおりです。
```
"ipFamily": "ipv4"
```
この出力では代わりに `ipv6` が返されることがあります。
1. IAM ロールの作成 IAM ロールを作成するには`eksctl` または `kubectl` および AWS CLI を使用してます。
eksctl
+ クラスターの IP ファミリーに適合するコマンドを使用して IAM ロールを作成し、そのロールに IAM ポリシーをアタッチします。このコマンドでは、IAM ロールを作成する AWS CloudFormation スタックを作成およびデプロイし、そのために指定したポリシーをアタッチします。さらに、既存の `aws-node` Kubernetes サービスアカウントに対し、作成された IAM ロールの ARN をアノテーションします。
+ `IPv4`
*マイクラスター* を独自の値に置き換えます。
```
eksctl create iamserviceaccount \
--name aws-node \
--namespace kube-system \
--cluster my-cluster \
--role-name AmazonEKSVPCCNIRole \
--attach-policy-arn arn:aws:iam::aws:policy/AmazonEKS_CNI_Policy \
--override-existing-serviceaccounts \
--approve
```
+ `IPv6`
*マイクラスター* を独自の値に置き換えます。*111122223333* を、ご自身のアカウント ID に置き換えます。また、*AmazonEKS\$1CNI\$1IPv6\$1Policy* を、`IPv6` ポリシー名に置き換えます。`IPv6` ポリシーがない場合は[`IPv6` ファミリーを使用するクラスター用に IAM ポリシーを作成します。](#cni-iam-role-create-ipv6-policy) を参照して作成します。クラスターで `IPv6` を使用するにはいくつかの要件を満たす必要があります。詳細については「[クラスター、Pod、サービスに対する IPv6 アドレスの説明](cni-ipv6.md)」を参照してください。
```
eksctl create iamserviceaccount \
--name aws-node \
--namespace kube-system \
--cluster my-cluster \
--role-name AmazonEKSVPCCNIRole \
--attach-policy-arn arn:aws:iam::111122223333:policy/AmazonEKS_CNI_IPv6_Policy \
--override-existing-serviceaccounts \
--approve
```
kubectl と AWS CLI
1. クラスターの OIDC プロバイダーの URL を表示します。
```
aws eks describe-cluster --name my-cluster --query "cluster.identity.oidc.issuer" --output text
```
出力例は次のとおりです。
```
https://oidc.eks.region-code.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE
```
出力が返されない場合は[クラスター用の IAM OIDC プロバイダーを作成する](enable-iam-roles-for-service-accounts.md)必要があります。
1. 次の内容を *vpc-cni-trust-policy.json* という名前のファイルにコピーします。*111122223333* を、ご自身のアカウント ID および前のステップで返された出力 *EXAMPLED539D4633E53DE1B71EXAMPLE* に置き換えます。*地域コード* を、クラスターのある AWS リージョンに置き換えます。
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::111122223333:oidc-provider/oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {
"oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE:aud": "sts.amazonaws.com",
"oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE:sub": "system:serviceaccount:kube-system:aws-node"
}
}
}
]
}
```
1. ロールを作成します。*AmazonEKSVPCCNIRole* は任意の名前に置き換えることができます。
```
aws iam create-role \
--role-name AmazonEKSVPCCNIRole \
--assume-role-policy-document file://"vpc-cni-trust-policy.json"
```
1. 必要な IAM ポリシーをロールにアタッチします。クラスターの IP ファミリに適合したコマンドを実行してください。
+ `IPv4`
```
aws iam attach-role-policy \
--policy-arn arn:aws:iam::aws:policy/AmazonEKS_CNI_Policy \
--role-name AmazonEKSVPCCNIRole
```
+ `IPv6`
*111122223333* はご自身のアカウント ID に置き換え、*AmazonEKS\$1CNI\$1IPv6\$1Policy* はご使用の `IPv6` ポリシーの名前に置き換えます。`IPv6` ポリシーがない場合は[`IPv6` ファミリーを使用するクラスター用に IAM ポリシーを作成します。](#cni-iam-role-create-ipv6-policy) を参照して作成します。クラスターで `IPv6` を使用するにはいくつかの要件を満たす必要があります。詳細については「[クラスター、Pod、サービスに対する IPv6 アドレスの説明](cni-ipv6.md)」を参照してください。
```
aws iam attach-role-policy \
--policy-arn arn:aws:iam::111122223333:policy/AmazonEKS_CNI_IPv6_Policy \
--role-name AmazonEKSVPCCNIRole
```
1. 次のコマンドを実行し、先に作成した IAM ロールの ARN で `aws-node` サービスアカウントをアノテーションします。example の値は独自の値に置き換えます。
```
kubectl annotate serviceaccount \
-n kube-system aws-node \
eks.amazonaws.com/role-arn=arn:aws:iam::111122223333:role/AmazonEKSVPCCNIRole
```
1. (オプション) Kubernetes サービスアカウントで使用されている AWS Security Token Service エンドポイントタイプを設定します。詳細については、「[サービスアカウントの AWS Security Token Service エンドポイントを設定する](configure-sts-endpoint.md)」を参照してください。
## ステップ 2: Amazon VPC CNI plugin for Kubernetes の Pod を再デプロイする
1. 認証情報環境変数を適用するために、サービスアカウントに関連付けられている既存の Pod を削除して再作成します。現在アノテーションなしで実行されている Pod には、アノテーションは適用されません。次のコマンドは、既存の `aws-node` DaemonSet Pod を削除し、サービスアカウントのアノテーションを使用してデプロイします。
```
kubectl delete Pods -n kube-system -l k8s-app=aws-node
```
1. Pod がすべて再起動したことを確認します。
```
kubectl get pods -n kube-system -l k8s-app=aws-node
```
1. Pod の 1 つについて説明し、`AWS_WEB_IDENTITY_TOKEN_FILE` および `AWS_ROLE_ARN` 環境変数が存在することを確認します。*cpjw7* を、前のステップの出力で返された、いずれかの Pod の名前に置き換えます。
```
kubectl describe pod -n kube-system aws-node-cpjw7 | grep 'AWS_ROLE_ARN:\|AWS_WEB_IDENTITY_TOKEN_FILE:'
```
出力例は次のとおりです。
```
AWS_ROLE_ARN: arn:aws:iam::111122223333:role/AmazonEKSVPCCNIRole
AWS_WEB_IDENTITY_TOKEN_FILE: /var/run/secrets/eks.amazonaws.com/serviceaccount/token
AWS_ROLE_ARN: arn:aws:iam::111122223333:role/AmazonEKSVPCCNIRole
AWS_WEB_IDENTITY_TOKEN_FILE: /var/run/secrets/eks.amazonaws.com/serviceaccount/token
```
Pod には 2 つのコンテナが含まれているため、重複した結果の 2 つのセットが返されます。両方のコンテナの値は同じです。
Pod で AWS リージョンエンドポイントを使用している場合、前の出力では下記の行も返されています。
```
AWS_STS_REGIONAL_ENDPOINTS=regional
```
## ステップ 3: ノードの IAM ロールから CNI ポリシーを削除する
現在、[Amazon EKS ノード IAM ロール](create-node-role.md)に `AmazonEKS_CNI_Policy` IAM (`IPv4`) ポリシーまたは [IPv6 ポリシー](#cni-iam-role-create-ipv6-policy)がアタッチされており、さらに、別の IAM ロールを作成し、このロールに対し前出のポリシーをアタッチし、そのロールを `aws-node` Kubernetes サービスアカウントに割り当てている場合、クラスターの IP ファミリーに適合する AWS CLI コマンドを使用して、ノードのロールからポリシーを削除することをお勧めします。*AmazonEKSNodeRole* を、ノードのロールの名前に置き換えます。
+ `IPv4`
```
aws iam detach-role-policy --role-name AmazonEKSNodeRole --policy-arn arn:aws:iam::aws:policy/AmazonEKS_CNI_Policy
```
+ `IPv6`
*111122223333* はご自身のアカウント ID に置き換え、*AmazonEKS\$1CNI\$1IPv6\$1Policy* はご使用の `IPv6` ポリシーの名前に置き換えます。
```
aws iam detach-role-policy --role-name AmazonEKSNodeRole --policy-arn arn:aws:iam::111122223333:policy/AmazonEKS_CNI_IPv6_Policy
```
## `IPv6` ファミリーを使用するクラスター用に IAM ポリシーを作成します。
`IPv6` ファミリーを使用するクラスターを作成し、そのクラスターでバージョン `1.10.1` 以降の Amazon VPC CNI plugin for Kubernetes アドオンが設定されている場合は、IAM ロールに割り当てることができる IAM ポリシーを作成する必要があります。作成時に `IPv6` ファミリーの使用を設定していない、既存のクラスターにおいて、`IPv6` を使用する場合には新しいクラスターを作成する必要があります。クラスターでの `IPv6` 使用の詳細については「[クラスター、Pod、サービスに対する IPv6 アドレスの説明](cni-ipv6.md)」を参照してください。
1. 次のテキストをコピーし、`vpc-cni-ipv6-policy.json` という名前のファイルに保存します。
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:AssignIpv6Addresses",
"ec2:DescribeInstances",
"ec2:DescribeTags",
"ec2:DescribeNetworkInterfaces",
"ec2:DescribeInstanceTypes"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ec2:CreateTags"
],
"Resource": [
"arn:aws:ec2:*:*:network-interface/*"
]
}
]
}
```
1. IAM ポリシーを作成する
```
aws iam create-policy --policy-name AmazonEKS_CNI_IPv6_Policy --policy-document file://vpc-cni-ipv6-policy.json
```
# VPC CNI モードと設定について説明します。
Amazon VPC CNI plugin for Kubernetes は、Pod のネットワーキングを提供します。使用可能なネットワーク機能の詳細については次の表を参照してください。
| ネットワーキング機能 | 詳細はこちら |
| --- | --- |
| クラスター、Pod、サービスに IPv6 アドレスを割り当てるようにクラスターを設定する | [クラスター、Pod、サービスに対する IPv6 アドレスの説明](cni-ipv6.md) |
| Pod に IPv4 Source Network Address Translation を使用する | [Pod のアウトバウンドインターネットアクセスを有効にする](external-snat.md) |
| Pod との間のネットワークトラフィックを制限する | [Kubernetes ネットワークポリシーを使用して Pod ネットワークトラフィックを制限する](cni-network-policy-configure.md) |
| ノードでセカンダリネットワークインターフェイスをカスタマイズする | [カスタムネットワーキングを使用して代替サブネットに Pod をデプロイする](cni-custom-network.md) |
| ノードの IP アドレスを増やす | [プレフィックスを使用して Amazon EKS ノードに割り当てる IP アドレスを増やす](cni-increase-ip-addresses.md) |
| Pod ネットワークトラフィックにセキュリティグループを使用する | [セキュリティグループを個別の Pod に割り当てる](security-groups-for-pods.md) |
| Pod に複数のネットワークインターフェイスを使用する | [複数のネットワークインターフェイスをポッドにアタッチする](pod-multiple-network-interfaces.md) |
# クラスター、Pod、サービスに対する IPv6 アドレスの説明
**適用対象**: Amazon EC2 インスタンスを持つ Pod と Fargate Pod
Kubernetes のデフォルトでは、`IPv4` アドレスが Pod とサービスに割り当てられます。Pod とサービスに `IPv4` アドレスを割り当てる代わりに、`IPv6` アドレスを割り当てるようにクラスターを設定できます。Amazon EKS は、Kubernetes がサポートしていても、デュアルスタックのポッドまたはサービスをサポートしません。つまり、Pod とサービスに `IPv4` アドレスと `IPv6` アドレスの両方を割り当てることはできません。
そのクラスターに使用する IP ファミリーは、クラスターの作成時に選択します。クラスターの作成後は、ファミリーを変更できません。
Amazon EKS `IPv6` クラスターをデプロイするチュートリアルについては、「[Amazon EKS `IPv6` クラスターとマネージド Amazon Linux ノードをデプロイする](deploy-ipv6-cluster.md)」を参照してください。
この機能を使用する際の考慮事項を次に示します。
## `IPv6` の機能のサポート
+ **Windows サポートなし**: Windows の Pod とサービスはサポートされていません。
+ **Nitro ベースの EC2 ノードが必要**: `IPv6` は、AWS Nitro ベースの Amazon EC2 または Fargate ノードでのみ使用が可能です。
+ **EC2 ノードおよび Fargate ノードがサポートされる**:`IPv6` は、Amazon EC2 ノードと Fargate ノードで [セキュリティグループを個別の Pod に割り当てる](security-groups-for-pods.md) とともに使用できます。
+ **Outposts はサポートされない**: `IPv6` は [AWS Outposts を使用して Amazon EKS をオンプレミスにデプロイする](eks-outposts.md) とともに使用できません。
+ **FSx for Lustre はサポートされない**: [Amazon FSx for Lustre で高性能なアプリケーションストレージを使用する](fsx-csi.md) はサポートされていません。
+ **カスタムネットワーキングはサポートされない**: IP アドレスの枯渇を緩和するために、これまで使用していた [カスタムネットワーキングを使用して代替サブネットに Pod をデプロイする](cni-custom-network.md) の代わりとして、`IPv6` を使用することができます。`IPv6` では、カスタムネットワーキングを使用することはできません。クラスターにおいて、ネットワークの分離用としてカスタムネットワーキングを使用する場合は、引き続き、`IPv4` ファミリーによるカスタムネットワーキングを使用する必要があります。
## IP アドレスの割り当て
+ **Kubernetes サービス**: Kubernetes サービスには `IPv6` アドレスのみが割り当てられます。これらには、IPv4 アドレスは割り当てられません。
+ **ポッド**: ポッドには IPv6 アドレスとホストローカル IPv4 アドレスが割り当てられます。ホストローカル IPv4 アドレスは、VPC CNI と連鎖されたホストローカル CNI プラグインを使用して割り当てられ、そのアドレスは Kubernetes コントロールプレーンに報告されません。これは、ポッドが別の Amazon VPC またはインターネット内の外部 IPv4 リソースと通信する必要がある場合にのみ使用されます。ホストローカル IPv4 アドレスは、ワーカーノードのプライマリ ENI のプライマリ IPv4 アドレスに (VPC CNI によって) SNAT されます。
+ **ポッドとサービス**: ポッドおよびサービスは `IPv4` アドレスではなく、`IPv6` アドレスのみを受け取ります。ポッドが外部 `IPv4` エンドポイントと通信する必要がある場合、ノード自体で NAT が使用されます。この組み込み NAT 機能により、[DNS64 および NAT64](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html#nat-gateway-nat64-dns64) が不要になります。パブリックインターネットアクセスを必要とするトラフィックの場合、ポッドのトラフィックはパブリック IP アドレスに変換されたソースネットワークアドレスになります。
+ **ルーティングアドレス**: ポッドが VPC の外部で通信する場合、元の `IPv6` アドレスは保持されます (ノードの `IPv6` アドレスに変換されない)。このトラフィックは、インターネットゲートウェイまたは Egress-Only のインターネットゲートウェイを介して直接ルーティングされます。
+ **ノード**: すべてのノードには、`IPv4` と `IPv6` のアドレスが割り当てられています。
+ **Fargate ポッド**: 各 Fargate Pod は、デプロイ先のサブネット用に指定された CIDR から、`IPv6` アドレスを受け取ります。Fargate Pod を実行するための基盤ハードウェアユニットは、そのユニットがデプロイされているサブネットに割り当てられている CIDR から、一意の `IPv4` および `IPv6` アドレスを取得します。
## EKS で `IPv6` を使用する方法
+ **新しいクラスターを作成する**: 新しいクラスターを作成し、そのクラスターで `IPv6` ファミリーの使用を指定する必要があります。これより前のバージョンからクラスターを更新して、`IPv6` ファミリーを有効化することはできません。新しいクラスターを作成する手順については、「考慮事項」を参照してください。
+ **最新の VPC CNI を使用する**: Amazon VPC CNI バージョン `1.10.1` 以降をデプロイします。このバージョン以降がデフォルトでデプロイされます。アドオンのデプロイ後は、クラスター内のすべてのノードグループ内にあるすべてのノードを削除しない限り、Amazon VPC CNI アドオンを `1.10.1` より前のバージョンにダウングレードすることはできません。
+ **`IPv6` 用の VPC CNI を設定する**: Amazon EC2 ノードを使用する場合は、IP プレフィックスの委任と `IPv6` を使用して Amazon VPC CNI アドオンを設定する必要があります。クラスターの作成時に `IPv6` ファミリーを選択した場合は、バージョン `1.10.1` のアドオンが、この設定のデフォルトになります。これは、セルフマネージド型のアドオン、および Amazon EKS アドオンの両方に当てはまります。IP プレフィックス委任の詳細については、「[プレフィックスを使用して Amazon EKS ノードに割り当てる IP アドレスを増やす](cni-increase-ip-addresses.md)」を参照してください。
+ **`IPv4` アドレスと `IPv6` アドレスを設定する**: クラスターを作成する際に指定する VPC とサブネットには、それらに割り当てられた `IPv6` CIDR ブロックが必要です。同時に、`IPv4` CIDR ブロックも割り当てられている必要があります。これは、`IPv6` のみを使用する場合でも、VPC が機能するには `IPv4` CIDR ブロックが必要になるためです。詳細については、「Amazon VPC ユーザーガイド」の「[IPv6 CIDR ブロックと VPC の関連付け](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-vpcs.html#vpc-associate-ipv6-cidr)」を参照してください。
+ **IPv6 アドレスをノードに自動割り当てする:** ノードを作成する際は、`IPv6` アドレスを自動割り当てするように設定されたサブネットを指定する必要があります。指定していない場合、ノードをデプロイできません。自動割り当ての設定はデフォルトで無効になっています｡ 詳細については、「Amazon VPC ユーザーガイド」の「[サブネットのパブリック IPv6 アドレス属性を変更する](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html#subnet-ipv6)」を参照してください。
+ **ルートテーブルを設定して `IPv6` を使用する**: サブネットに割り当てられるルートテーブルには、`IPv6` アドレス用のルートが必要です。詳細については、「Amazon VPC ユーザーガイド」の「[既存の VPC を IPv4 から IPv6 に移行する](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-migrate-ipv6.html)」を参照してください。
+ **`IPv6` のセキュリティグループを設定する**: セキュリティグループは `IPv6` アドレスを許可する必要があります。詳細については、「Amazon VPC ユーザーガイド」の「[既存の VPC を IPv4 から IPv6 に移行する](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-migrate-ipv6.html)」を参照してください。
+ **ロードバランサーを設定する**: AWS Load Balancer Controller のバージョン `2.3.1` 以降を使用して、「[Application Load Balancer を使用してアプリケーションと HTTP トラフィックをルーティングする](alb-ingress.md)」を使用した HTTP アプリケーションのロードバランシング、または、「[Network Load Balancer を使用して TCP および UDP トラフィックをルーティングする](network-load-balancing.md)」を使用したネットワークトラフィックの `IPv6` Pod へのロードバランシングを行います。いずれの場合もインスタンスモードではなく IP モードを使用してください。詳細については、「[AWS Load Balancer Controller を使用してインターネットトラフィックをルーティングする](aws-load-balancer-controller.md)」を参照してください。
+ **`IPv6` IAM ポリシーを追加する**: ノード IAM または CNI IAM ロールには、`IPv6` のIAM ポリシーをアタッチする必要があります。上記 2 つの中では、CNI IAM ロールへのアタッチが推奨されます。詳細については、「[`IPv6` ファミリーを使用するクラスター用に IAM ポリシーを作成します。](cni-iam-role.md#cni-iam-role-create-ipv6-policy)」および「[ステップ 1: Amazon VPC CNI plugin for Kubernetes の IAM ロールを作成する](cni-iam-role.md#cni-iam-role-create-role)」を参照してください。
+ **すべてのコンポーネントを評価する**: アプリケーション、Amazon EKS アドオン、および、`IPv6` クラスターのデプロイ前に統合した AWS サービスに関しては、包括的な評価を実施します。これにより、`IPv6` を使用した場合も、すべてが想定どおりに動作することを保証できます。
# Amazon EKS `IPv6` クラスターとマネージド Amazon Linux ノードをデプロイする
このチュートリアルでは、`IPv6` ファミリーを使用する `IPv6` Amazon VPC と Amazon EKS クラスターのデプロイ、および Amazon EC2 Amazon Linux ノードを使用するマネージド型ノードグループのデプロイ方法を説明します。`IPv6` クラスター内では、Amazon EC2 Windows のノードをデプロイすることはできません。Fargate ノードをクラスターにデプロイすることもできますが、理解しやすくするため、これらの手順はこのトピックでは説明していません。
## 前提条件
このチュートリアルを開始する前に以下を完了してください。
Amazon EKS クラスターの作成と管理に必要な次のツールおよびリソースをインストールおよび設定します。
+ すべての設定を習熟し、要件を満たす設定でクラスターをデプロイすることをお勧めします。詳細については、「[Amazon EKS クラスターを作成します。](create-cluster.md)」、「[マネージドノードグループを使用してノードライフサイクルを簡素化する](managed-node-groups.md)」、ならびにこのトピックの「[考慮事項](cni-ipv6.md)」を参照してください。一部の設定の有効化は、クラスターの作成時にのみ行えます。
+ デバイスまたは AWS クラウドシェル に、`kubectl` コマンドラインツールがインストールされていること。バージョンはご使用のクラスターの Kubernetes バージョンと同じか、1 つ前のマイナーバージョン以前、あるいはそれより新しいバージョンが使用できます。例えば、クラスターのバージョンが `1.29` である場合、`kubectl` のバージョン `1.28`、`1.29`、または `1.30` が使用できます。`kubectl` をインストールまたはアップグレードする方法については「[`kubectl` および `eksctl` のセットアップ](install-kubectl.md)」を参照してください。
+ 使用している IAM セキュリティプリンシパルは、Amazon EKS の IAM ロール、サービスにリンクされたロール、AWS CloudFormation、VPC、関連リソースを使用するために許可が必要です。詳細については、「IAM ユーザーガイド」の「[アクション](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html)」および「[サービスにリンクされたロールの使用](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html)」を参照してください。
+ eksctl を使用する場合は、コンピュータにバージョン `0.215.0` 以降をインストールします。インストールまたはアップグレードするには、`eksctl` ドキュメントの「[インストール](https://eksctl.io/installation)」を参照してください。
+ ご使用のデバイスまたは AWS CloudShell で、バージョン `2.12.3` 以降、または AWS コマンドラインインターフェイス (AWS CLI) のバージョン `1.27.160` 以降がインストールおよび設定されていること。現在のバージョンを確認するには「`aws --version | cut -d / -f2 | cut -d ' ' -f1`」を参照してください。`yum`、`apt-get`、macOS 用の Homebrew などのパッケージマネージャーは、多くの場合 AWS CLI の最新バージョンより数バージョン古くなっています。最新バージョンをインストールするには「*AWS コマンドラインインターフェイスユーザーガイド*」の「[インストール](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html)」および「[aws configure を使用したクイック設定](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config)」を参照してください。AWS クラウドシェル にインストールされている AWS CLI バージョンも最新バージョンより数バージョン遅れることがあります。更新するには、「*AWS CloudShell ユーザーガイド*」の「[ホームディレクトリへの AWS CLI のインストール](https://docs.aws.amazon.com/cloudshell/latest/userguide/vm-specs.html#install-cli-software)」を参照してください。AWS CloudShell を使用する場合は、[バージョン 2.12.3 以降または 1.27.160 以降の AWS CLI をインストール](https://docs.aws.amazon.com/cloudshell/latest/userguide/vm-specs.html#install-cli-software)する必要があります。AWS CloudShell には、デフォルトとして AWS CLI の古いバージョンがインストールされている可能性があります。
eksctl または CLI を使用して `IPv6` クラスターをデプロイできます。
## eksctl を使用して IPv6 クラスターをデプロイする
1. `ipv6-cluster.yaml` ファイルの作成 デバイスに沿ったコマンドをコピーします。必要に応じてコマンドに次の変更を加え、変更したコマンドを実行してください：
+ *my-cluster* の部分は、自分のクラスター名に置き換えます。この名前には英数字 (大文字と小文字が区別されます) とハイフンのみを使用できます。先頭の文字は英数字である必要があります。また、100 文字より長くすることはできません。名前は、クラスターを作成する AWS リージョンおよび AWS アカウント内で一意である必要があります。
+ *region-code* は、Amazon EKS がサポートする任意の AWS リージョンに置き換えます。AWS リージョンの一覧については、AWS の全般的なリファレンスガイドの [Amazon EKS エンドポイントとクォータ](https://docs.aws.amazon.com/general/latest/gr/eks.html)を参照してください。
+ `version` の値には、クラスターのバージョンを設定する必要があります。詳細については、「[Amazon EKS supported versions](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html)」を参照してください。
+ *my-nodegroup* を、ノードグループの名前に置き換えます。ノードグループ名は 63 文字以下である必要があります。先頭は文字または数字でなければなりませんが、残りの文字にはハイフンおよびアンダースコアを含めることもできます。
+ *t3.medium* の部分は、任意の [AWS Nitro System インスタンスタイプ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html#ec2-nitro-instances)に置き換えます。
```
cat >ipv6-cluster.yaml <
aws-node-t74jh 1/1 Running 0 5m32s 2600:1f13:b66:8203:4516:2080:8ced:1ca9 ip-192-168-253-70.region-code.compute.internal
coredns-85d5b4454c-cw7w2 1/1 Running 0 56m 2600:1f13:b66:8203:34e5:: ip-192-168-253-70.region-code.compute.internal
coredns-85d5b4454c-tx6n8 1/1 Running 0 56m 2600:1f13:b66:8203:34e5::1 ip-192-168-253-70.region-code.compute.internal
kube-proxy-btpbk 1/1 Running 0 5m36s 2600:1f13:b66:8200:11a5:ade0:c590:6ac8 ip-192-168-34-75.region-code.compute.internal
kube-proxy-jjk2g 1/1 Running 0 5m33s 2600:1f13:b66:8203:4516:2080:8ced:1ca9 ip-192-168-253-70.region-code.compute.internal
```
1. デフォルトのサービスに、`IPv6` アドレスが割り当てられていることを確認します。
```
kubectl get services -n kube-system -o wide
```
出力例は次のとおりです。
```
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR
kube-dns ClusterIP fd30:3087:b6c2::a 53/UDP,53/TCP 57m k8s-app=kube-dns
```
1. (オプション) [サンプルアプリケーションをデプロイする](sample-deployment.md)か、[AWS Load Balancer コントローラーとサンプルアプリケーションをデプロイ](aws-load-balancer-controller.md)して、「[Application Load Balancer を使用してアプリケーションと HTTP トラフィックをルーティングする](alb-ingress.md)」に従い HTTP アプリケーションをロードバランシングするか、「[Network Load Balancer を使用して TCP および UDP トラフィックをルーティングする](network-load-balancing.md)」に従いネットワークトラフィックを `IPv6` Pod にロードバランシングします。
1. このチュートリアルのために作成したクラスターとノードの使用が終了したら、それらのリソースは、次のコマンドにより削除しておきます。
```
eksctl delete cluster my-cluster
```
## AWS CLI を使用して IPv6 クラスターをデプロイする
**重要**
この手順のすべてのステップは、同一のユーザーとして実行する必要があります。現在のユーザーを確認するには、次のコマンドを実行します。
```
aws sts get-caller-identity
```
この手順のすべてのステップは、同一のシェル内で実行する必要があります。いくつかのステップには、これより前のステップで設定した変数を使用します。変数の値が異なるシェル内で設定されていると、その変数を使用するステップは正しく機能しません。[AWS CloudShell](https://docs.aws.amazon.com/cloudshell/latest/userguide/welcome.html) を使用して次の手順を実行する際、約 20～30 分の間キーボードまたはポインタによる操作がないと、シェルセッションが終了することを銘記しておいてください。実行中のプロセスは、操作数としてカウントされません。
各命令は Bash シェル用に記述されているので、他のシェルでは修正が必要な場合があります。
この手順の各ステップにおいて、すべての example values は、ご自分が使用する値に置き換える必要があります。
1. 以下のコマンドを実行して、後のステップで使用するいくつかの変数を設定します。*region-code* は、リソースをデプロイする AWS リージョンに置き換えます。この値には、Amazon EKS でサポートされている任意の AWS リージョンが設定できます。AWS リージョンの一覧については、AWS の全般的なリファレンスガイドの [Amazon EKS エンドポイントとクォータ](https://docs.aws.amazon.com/general/latest/gr/eks.html)を参照してください。*my-cluster* の部分は、自分のクラスター名に置き換えます。この名前には英数字 (大文字と小文字が区別されます) とハイフンのみを使用できます。先頭の文字は英数字である必要があります。また、100 文字より長くすることはできません。名前は、クラスターを作成する AWS リージョンおよび AWS アカウント内で一意である必要があります。*my-nodegroup* を、ノードグループの名前に置き換えます。ノードグループ名は 63 文字以下である必要があります。先頭は文字または数字でなければなりませんが、残りの文字にはハイフンおよびアンダースコアを含めることもできます。*111122223333* は、ご自分のアカウント ID に置き換えます。
```
export region_code=region-code
export cluster_name=my-cluster
export nodegroup_name=my-nodegroup
export account_id=111122223333
```
1. パブリックサブネットとプライベートサブネットを持ち、Amazon EKS と `IPv6` の要件を満たす Amazon VPC を作成します。
1. 次のコマンドを実行して、AWS CloudFormation スタック名のための変数を設定します。*my-eks-ipv6-vpc* は、任意の名前に置き換えることができます。
```
export vpc_stack_name=my-eks-ipv6-vpc
```
1. AWS CloudFormation のテンプレートを使用して `IPv6` VPC を作成します。
```
aws cloudformation create-stack --region $region_code --stack-name $vpc_stack_name \
--template-url https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2020-10-29/amazon-eks-ipv6-vpc-public-private-subnets.yaml
```
スタックが作成されるまで数分かかります。以下のコマンドを実行してください。コマンドの出力が「`CREATE_COMPLETE`」になるまで、次のステップに進まないでください。
```
aws cloudformation describe-stacks --region $region_code --stack-name $vpc_stack_name --query Stacks[].StackStatus --output text
```
1. 作成されたパブリックサブネットの ID を取得します。
```
aws cloudformation describe-stacks --region $region_code --stack-name $vpc_stack_name \
--query='Stacks[].Outputs[?OutputKey==`SubnetsPublic`].OutputValue' --output text
```
出力例は次のとおりです。
```
subnet-0a1a56c486EXAMPLE,subnet-099e6ca77aEXAMPLE
```
1. 作成されたパブリックサブネットで、`IPv6` アドレスの自動割り当てオプションを有効にします。
```
aws ec2 modify-subnet-attribute --region $region_code --subnet-id subnet-0a1a56c486EXAMPLE --assign-ipv6-address-on-creation
aws ec2 modify-subnet-attribute --region $region_code --subnet-id subnet-099e6ca77aEXAMPLE --assign-ipv6-address-on-creation
```
1. テンプレートによって作成されたサブネットおよびセキュリティグループの名前を、デプロイされた AWS CloudFormation スタックから取得します。これらの名前は、後のステップで使用するために変数に格納しておきます。
```
security_groups=$(aws cloudformation describe-stacks --region $region_code --stack-name $vpc_stack_name \
--query='Stacks[].Outputs[?OutputKey==`SecurityGroups`].OutputValue' --output text)
public_subnets=$(aws cloudformation describe-stacks --region $region_code --stack-name $vpc_stack_name \
--query='Stacks[].Outputs[?OutputKey==`SubnetsPublic`].OutputValue' --output text)
private_subnets=$(aws cloudformation describe-stacks --region $region_code --stack-name $vpc_stack_name \
--query='Stacks[].Outputs[?OutputKey==`SubnetsPrivate`].OutputValue' --output text)
subnets=${public_subnets},${private_subnets}
```
1. クラスターの IAM ロールを作成して、そのロールに必要な Amazon EKS IAM 管理ポリシーをアタッチします。Amazon EKS によって管理される Kubernetes クラスターは、そのサービスで使用するリソースを管理するために、ユーザーに代わって他の AWS のサービスを呼び出します。
1. 次のコマンドを実行して、`eks-cluster-role-trust-policy.json` ファイルを作成します。
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "eks.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
1. 次のコマンドを実行して、ロール名の変数を設定します。*myAmazonEKSClusterRole* は、任意の名前に置き換えることができます。
```
export cluster_role_name=myAmazonEKSClusterRole
```
1. ロールを作成します。
```
aws iam create-role --role-name $cluster_role_name --assume-role-policy-document file://"eks-cluster-role-trust-policy.json"
```
1. IAM ロールの ARN を取得し、後のステップで使用するために変数に格納します。
```
CLUSTER_IAM_ROLE=$(aws iam get-role --role-name $cluster_role_name --query="Role.Arn" --output text)
```
1. このロールに、必要な Amazon EKS 管理の IAM ポリシーをアタッチします。
```
aws iam attach-role-policy --policy-arn arn:aws:iam::aws:policy/AmazonEKSClusterPolicy --role-name $cluster_role_name
```
1. クラスターを作成する
```
aws eks create-cluster --region $region_code --name $cluster_name --kubernetes-version 1.XX \
--role-arn $CLUSTER_IAM_ROLE --resources-vpc-config subnetIds=$subnets,securityGroupIds=$security_groups \
--kubernetes-network-config ipFamily=ipv6
```
1. 注意: リクエストで指定したアベイラビリティーゾーンのいずれかに、Amazon EKS クラスターの作成に十分な容量がない場合には、エラーが表示されることがあります。このエラー出力には新しいクラスターをサポートできるアベイラビリティーゾーンが表示されます。アカウント向けにサポートされているアベイラビリティーゾーンにある 2 つ以上のサブネットを使用して、クラスターを作成します。詳細については「[容量不足](troubleshooting.md#ice)」を参照してください。
クラスターが作成されるまでに数分かかります。以下のコマンドを実行してください。コマンドの出力が「`ACTIVE`」になるまで、次のステップに進まないでください。
```
aws eks describe-cluster --region $region_code --name $cluster_name --query cluster.status
```
1. クラスターの `kubeconfig` ファイルを作成または更新し、そのクラスターと通信できるようにします。
```
aws eks update-kubeconfig --region $region_code --name $cluster_name
```
デフォルトでは、`config` ファイルが `~/.kube` に作成されるか、`config` ファイルが既に `~/.kube` に存在する場合には、その中に新しいクラスター設定が追加されます。
1. ノードの IAM ロールを作成します。
1. 次のコマンドを実行して、`vpc-cni-ipv6-policy.json` ファイルを作成します。
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:AssignIpv6Addresses",
"ec2:DescribeInstances",
"ec2:DescribeTags",
"ec2:DescribeNetworkInterfaces",
"ec2:DescribeInstanceTypes"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ec2:CreateTags"
],
"Resource": [
"arn:aws:ec2:*:*:network-interface/*"
]
}
]
}
```
1. IAM ポリシーを作成します。
```
aws iam create-policy --policy-name AmazonEKS_CNI_IPv6_Policy --policy-document file://vpc-cni-ipv6-policy.json
```
1. 次のコマンドを実行して、`node-role-trust-relationship.json` ファイルを作成します。
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "ec2.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
1. 次のコマンドを実行して、ロール名の変数を設定します。*AmazonEKSNodeRole* は、任意の名前に置き換えることができます。
```
export node_role_name=AmazonEKSNodeRole
```
1. IAM ロールの作成
```
aws iam create-role --role-name $node_role_name --assume-role-policy-document file://"node-role-trust-relationship.json"
```
1. IAM ロールに IAM ポリシーをアタッチします。
```
aws iam attach-role-policy --policy-arn arn:aws:iam::$account_id:policy/AmazonEKS_CNI_IPv6_Policy \
--role-name $node_role_name
```
**重要**
簡単にするため、このチュートリアルでは、ポリシーが以下の IAM ロールにアタッチされています。ただし、本番向けクラスターの場合は、異なる IAM ロールにポリシーをアタッチすることをお勧めします。詳細については、「[IRSA を使用するように Amazon VPC CNI プラグインを設定する](cni-iam-role.md)」を参照してください。
1. IAM ロールに、2 つの必須なマネージド IAM ポリシーをアタッチします。
```
aws iam attach-role-policy --policy-arn arn:aws:iam::aws:policy/AmazonEKSWorkerNodePolicy \
--role-name $node_role_name
aws iam attach-role-policy --policy-arn arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryReadOnly \
--role-name $node_role_name
```
1. IAM ロールの ARN を取得し、後のステップで使用するために変数に格納します。
```
node_iam_role=$(aws iam get-role --role-name $node_role_name --query="Role.Arn" --output text)
```
1. マネージド型ノードグループを作成する
1. 前のステップで作成したサブネットの ID を表示します。
```
echo $subnets
```
出力例は次のとおりです。
```
subnet-0a1a56c486EXAMPLE,subnet-099e6ca77aEXAMPLE,subnet-0377963d69EXAMPLE,subnet-0c05f819d5EXAMPLE
```
1. ノードグループを作成します。*0a1a56c486EXAMPLE*、*099e6ca77aEXAMPLE*、*0377963d69EXAMPLE*、および *0c05f819d5EXAMPLE* は、前のステップの出力で返された値に置き換えます。次のコマンドでは、前の出力の中でサブネット ID の間にあるカンマを必ず削除して使用します。*t3.medium* の部分は、任意の [AWS Nitro System インスタンスタイプ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html#ec2-nitro-instances)に置き換えることができます。
```
aws eks create-nodegroup --region $region_code --cluster-name $cluster_name --nodegroup-name $nodegroup_name \
--subnets subnet-0a1a56c486EXAMPLE subnet-099e6ca77aEXAMPLE subnet-0377963d69EXAMPLE subnet-0c05f819d5EXAMPLE \
--instance-types t3.medium --node-role $node_iam_role
```
ノードグループの作成には数分かかります。以下のコマンドを実行してください。出力が「`ACTIVE`」を返すまで、次のステップに進まないでください。
```
aws eks describe-nodegroup --region $region_code --cluster-name $cluster_name --nodegroup-name $nodegroup_name \
--query nodegroup.status --output text
```
1. デフォルトの Pod に `IPv6` アドレスが割り当てられていることを、`IP` 列で確認します。
```
kubectl get pods -n kube-system -o wide
```
出力例は次のとおりです。
```
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
aws-node-rslts 1/1 Running 1 5m36s 2600:1f13:b66:8200:11a5:ade0:c590:6ac8 ip-192-168-34-75.region-code.compute.internal
aws-node-t74jh 1/1 Running 0 5m32s 2600:1f13:b66:8203:4516:2080:8ced:1ca9 ip-192-168-253-70.region-code.compute.internal
coredns-85d5b4454c-cw7w2 1/1 Running 0 56m 2600:1f13:b66:8203:34e5:: ip-192-168-253-70.region-code.compute.internal
coredns-85d5b4454c-tx6n8 1/1 Running 0 56m 2600:1f13:b66:8203:34e5::1 ip-192-168-253-70.region-code.compute.internal
kube-proxy-btpbk 1/1 Running 0 5m36s 2600:1f13:b66:8200:11a5:ade0:c590:6ac8 ip-192-168-34-75.region-code.compute.internal
kube-proxy-jjk2g 1/1 Running 0 5m33s 2600:1f13:b66:8203:4516:2080:8ced:1ca9 ip-192-168-253-70.region-code.compute.internal
```
1. デフォルトのサービスに `IPv6` アドレスが割り当てられていることを、`IP` 列で確認します。
```
kubectl get services -n kube-system -o wide
```
出力例は次のとおりです。
```
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR
kube-dns ClusterIP fd30:3087:b6c2::a 53/UDP,53/TCP 57m k8s-app=kube-dns
```
1. (オプション) [サンプルアプリケーションをデプロイする](sample-deployment.md)か、[AWS Load Balancer コントローラーとサンプルアプリケーションをデプロイ](aws-load-balancer-controller.md)して、「[Application Load Balancer を使用してアプリケーションと HTTP トラフィックをルーティングする](alb-ingress.md)」に従い HTTP アプリケーションをロードバランシングするか、「[Network Load Balancer を使用して TCP および UDP トラフィックをルーティングする](network-load-balancing.md)」 に従いネットワークトラフィックを `IPv6` Pod にロードバランシングします。
1. このチュートリアルのために作成したクラスターとノードの使用が終了したら、以下のコマンドにより、作成したリソースのクリーンアップを行う必要があります。削除を行う前に、これらのリソースが、このチュートリアルの外部で使用されていないことを確認します。
1. ここまでの手順を実行したのとは異なるシェルで、このステップを完了する場合は、サンプル値を前の手順を実行した際に指定した値に置き換えながら、すべての変数を前の手順で使用した値に設定します。前の手順を実行したのと同じシェルでこのステップを完了する場合は、このまま次のステップに進みます。
```
export region_code=region-code
export vpc_stack_name=my-eks-ipv6-vpc
export cluster_name=my-cluster
export nodegroup_name=my-nodegroup
export account_id=111122223333
export node_role_name=AmazonEKSNodeRole
export cluster_role_name=myAmazonEKSClusterRole
```
1. ノードグループを削除します。
```
aws eks delete-nodegroup --region $region_code --cluster-name $cluster_name --nodegroup-name $nodegroup_name
```
削除には数分かかります。以下のコマンドを実行してください。何らかの出力が返された場合は、次のステップに進まないでください。
```
aws eks list-nodegroups --region $region_code --cluster-name $cluster_name --query nodegroups --output text
```
1. クラスターを削除します。
```
aws eks delete-cluster --region $region_code --name $cluster_name
```
クラスターの削除には数分かかります。次に進む前に、下記のコマンドを使用してクラスターが削除されていることを確認します。
```
aws eks describe-cluster --region $region_code --name $cluster_name
```
下記のような出力が返されるまで、次のステップに進まないでください。
```
An error occurred (ResourceNotFoundException) when calling the DescribeCluster operation: No cluster found for name: my-cluster.
```
1. 作成した IAM リソースを削除します。前の手順で使用した名前とは異なる名前を選択した場合は、その名で *AmazonEKS\$1CNI\$1IPv6\$1Policy* を置き換えます。
```
aws iam detach-role-policy --role-name $cluster_role_name --policy-arn arn:aws:iam::aws:policy/AmazonEKSClusterPolicy
aws iam detach-role-policy --role-name $node_role_name --policy-arn arn:aws:iam::aws:policy/AmazonEKSWorkerNodePolicy
aws iam detach-role-policy --role-name $node_role_name --policy-arn arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryReadOnly
aws iam detach-role-policy --role-name $node_role_name --policy-arn arn:aws:iam::$account_id:policy/AmazonEKS_CNI_IPv6_Policy
aws iam delete-policy --policy-arn arn:aws:iam::$account_id:policy/AmazonEKS_CNI_IPv6_Policy
aws iam delete-role --role-name $cluster_role_name
aws iam delete-role --role-name $node_role_name
```
1. VPC を作成した AWS CloudFormation スタックを削除します。
```
aws cloudformation delete-stack --region $region_code --stack-name $vpc_stack_name
```
# Pod のアウトバウンドインターネットアクセスを有効にする
**適用対象**: Linux `IPv4` Fargate ノード、Amazon EC2 インスタンスを持つ Linux ノード
`IPv6` ファミリーを使用してクラスターをデプロイした場合、このトピックの情報はクラスターに適用されません。`IPv6` アドレスがネットワーク変換されないからです。クラスターでの `IPv6` 使用の詳細については「[クラスター、Pod、サービスに対する IPv6 アドレスの説明](cni-ipv6.md)」を参照してください。
デフォルトでは、クラスター内の各 Pod に、Pod がデプロイされた VPC に関連付けられた Classless Inter-Domain Routing (CIDR) ブロックから、[プライベート](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-instance-addressing.html#concepts-private-addresses) `IPv4` アドレスが割り当てられます。同じ VPC 内の Pod は、これらのプライベート IP アドレスをエンドポイントとして使用して相互に通信します。VPC に関連付けられている CIDR ブロック外の `IPv4` アドレスと Pod が通信する場合、([Linux](https://github.com/aws/amazon-vpc-cni-k8s#amazon-vpc-cni-k8s) と [Windows](https://github.com/aws/amazon-vpc-cni-plugins/tree/master/plugins/vpc-bridge) 両用の) Amazon VPC CNI プラグインが Pod の `IPv4` アドレスを、Pod が実行されているノードのプライマリ [Elastic Network Interface](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html#eni-basics) のプライマリプライベート `IPv4` アドレスに変換します (デフォルトでは [\$1](#snat-exception))。
**注記**
Windows ノードについては、他にも考慮すべき事項があります。デフォルトでは、[Windows の VPC CNI プラグイン](https://github.com/aws/amazon-vpc-cni-plugins/tree/master/plugins/vpc-bridge)は、同じ VPC 内の宛先へのトラフィックを SNAT から除外するネットワーク設定で定義されます。つまり、内部 VPC 通信では SNAT が無効になっており、Pod に割り当てられた IP アドレスは VPC 内でルーティング可能です。ただし、VPC 外の宛先へのトラフィックでは、送信元 Pod IP がインスタンスの ENI のプライマリ IP アドレスに SNAT されます。Windows のこのデフォルト設定により、Pod はホストインスタンスと同じ方法で VPC 外部のネットワークにアクセスできます。
この動作によって、次の現象が起こります。
+ Pod は、それらが実行されているノードに[パブリック](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-instance-addressing.html#concepts-public-addresses) IP アドレスまたは [Elastic](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-eips.html) IP アドレスが割り当てられており、[パブリックサブネット](https://docs.aws.amazon.com/vpc/latest/userguide/configure-subnets.html#subnet-basics)内にある場合にのみ、インターネットリソースと通信できます。パブリックサブネットに関連付けられている[ルートテーブル](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Route_Tables.html)には、インターネットゲートウェイへのルートが含まれています。可能であれば、プライベートサブネットにノードをデプロイすることをお勧めします。
+ `1.8.0` よりも古いバージョンのプラグインの場合、[VPC ピアリング](https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html)、[トランジット VPC](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/transit-vpc-option.html)、または [AWS Direct Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/Welcome.html) を使用してクラスター VPC に接続されているネットワークまたは VPC 内にあるリソースは、セカンダリ Elastic Network Interface の背後にある Pod との通信を開始できません。ただし、Pod はこれらのリソースとの通信を開始し、リソースから応答を受け取ることができます。
ご使用の環境で次のいずれかが当てはまる場合は、次のコマンドを使用してデフォルト設定を変更してください。
+ [VPC ピアリング](https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html)、[トランジット VPC](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/transit-vpc-option.html)、または [AWS Direct Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/Welcome.html) を使用してクラスター VPC に接続されているネットワークまたは VPC 内に、`IPv4` アドレスを使用して Pod との通信を開始する必要があるリソースがあり、プラグインのバージョンが `1.8.0` よりも前である。
+ Pod が[プライベートサブネット](https://docs.aws.amazon.com/vpc/latest/userguide/configure-subnets.html#subnet-basics)にあり、インターネットへのアウトバウンド通信を行う必要がある。サブネットには、[NAT ゲートウェイ](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html)へのルートがある。
```
kubectl set env daemonset -n kube-system aws-node AWS_VPC_K8S_CNI_EXTERNALSNAT=true
```
**注記**
`AWS_VPC_K8S_CNI_EXTERNALSNAT` および `AWS_VPC_K8S_CNI_EXCLUDE_SNAT_CIDRS` CNI の設定変数は Windows ノードに適用されません。SNAT の無効化は Windows でサポートされていません。`IPv4` CIDR のリストを SNAT から除外する場合は、Windows ブートストラップスクリプトで `ExcludedSnatCIDRs` パラメータを指定して定義できます。このパラメータの使用に関する詳細については、「[ブートストラップスクリプトの設定パラメータ](eks-optimized-windows-ami.md#bootstrap-script-configuration-parameters)」を参照してください。
## ホストネットワーキング
\$1 Pod の仕様に `hostNetwork=true` が含まれている場合 (デフォルトは `false`)、その IP アドレスは別のアドレスに変換されません。これは、デフォルトでクラスターで実行される `kube-proxy` および Amazon VPC CNI plugin for Kubernetes Pod の場合に当てはまります。これらの Pod の場合、IP アドレスはノードのプライマリ IP アドレスと同じであるため、Pod の IP アドレスは変換されません。Pod の `hostNetwork` 設定の詳細については、Kubernetes API リファレンスの「[PodSpec v1 core](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.35/#podspec-v1-core)」を参照してください。
# Kubernetes ネットワークポリシーにより Pod トラフィックを制限する
## 概要
デフォルトでは、Kubernetes の IP アドレス、ポート、クラスター内の Pod 間の接続、またはポッドと他のネットワークのリソースの接続に制限はありません。Kubernetes *ネットワークポリシー*を使用して、自分の Pod 間で送受信されるネットワークトラフィックを制限できます。詳細については、Kubernetes ドキュメントの「[ネットワークポリシー](https://kubernetes.io/docs/concepts/services-networking/network-policies/)」を参照してください。
## 標準のネットワークポリシー
標準の `NetworkPolicy` を使用すると、クラスター内のポッド間トラフィックをセグメント化できます。OSI ネットワークモデルのレイヤー 3 と 4 で動作するネットワークポリシーであり、Amazon EKS クラスター内の IP アドレスまたはポートレベルでトラフィックフローを制御できます。標準のネットワークポリシーは、範囲が名前空間レベルに限定されます。
### ユースケース
+ ワークロード間でネットワークトラフィックをセグメント化すると、関連するアプリケーションのみが相互に通信できるようになります。
+ ポリシーを使用して名前空間レベルでテナントを分離すると、ネットワークを分離できます。
### 例
以下のポリシーでは、*sun* 名前空間の *webapp* ポッドからのエグレストラフィックが制限されています。
```
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: webapp-egress-policy
namespace: sun
spec:
podSelector:
matchLabels:
role: webapp
policyTypes:
- Egress
egress:
- to:
- namespaceSelector:
matchLabels:
name: moon
podSelector:
matchLabels:
role: frontend
ports:
- protocol: TCP
port: 8080
- to:
- namespaceSelector:
matchLabels:
name: stars
podSelector:
matchLabels:
role: frontend
ports:
- protocol: TCP
port: 8080
```
ポリシーは、`sun` 名前空間で `role: webapp` というラベルが付いたポッドに適用されます。
+ 許可されるトラフィック: TCP ポート `8080` の `moon` 名前空間で `role: frontend` というラベルが付いたポッド。
+ 許可されるトラフィック: TCP ポート `8080` の `stars` 名前空間で role: frontend というラベルが付いたポッド。
+ ブロックされるトラフィック: `webapp` ポッドからの他のすべてのアウトバウンドトラフィックは暗黙的に拒否されます。
## 管理者 (あるいはクラスター) ネットワークポリシー
![\[EKS でネットワークポリシーが評価される順序を示した図\]](http://docs.aws.amazon.com/ja_jp/eks/latest/userguide/images/evaluation-order.png)
`ClusterNetworkPolicy` を使用すると、ネットワークセキュリティ標準をクラスター全体に適用できます。名前空間ごとにポリシーを繰り返し定義して維持するのではなく、単一のポリシーを使用して、名前空間に関係なく、クラスター内のさまざまなワークロードに対するネットワークアクセスコントロールを一元管理できます。
### ユースケース
+ EKS クラスター内のすべての (または一部の) ワークロードに対するネットワークアクセスコントロールを一元管理します。
+ クラスター全体にわたるデフォルトのネットワークセキュリティ体制を定義します。
+ 組織のセキュリティ標準を運用効率の高い方法でクラスターの範囲へと拡張します。
### 例
以下のポリシーでは、他の名前空間からのクラスタートラフィックを明示的にブロックして、機密性の高いワークロード名前空間へのネットワークアクセスを防ぐことができます。
```
apiVersion: networking.k8s.aws/v1alpha1
kind: ClusterNetworkPolicy
metadata:
name: protect-sensitive-workload
spec:
tier: Admin
priority: 10
subject:
namespaces:
matchLabels:
kubernetes.io/metadata.name: earth
ingress:
- action: Deny
from:
- namespaces:
matchLabels: {} # Match all namespaces.
name: select-all-deny-all
```
## 重要な注意事項
Amazon VPC CNI plugin for Kubernetes のネットワークポリシーは、以下に示した構成でサポートされています。
+ 標準と管理者のどちらのネットワークポリシーでも、Amazon VPC CNI プラグインのバージョンが 1.21.0 (またはそれ以降) です。
+ `IPv4` または `IPv6` アドレス用に設定されたクラスター。
+ [ポッド用のセキュリティグループ](security-groups-for-pods.md)でネットワークポリシーを使用できます。ネットワークポリシーを使用すると、クラスター内の通信をすべて制御できます。Pod 用のセキュリティグループを使用すると、Pod 内のアプリケーションから AWS サービスへのアクセスを制御できます。
+ *カスタムネットワーク*および*プレフィックス委任*でネットワークポリシーを使用できます。
## 考慮事項
**アーキテクチャ** ()
+ Amazon VPC CNI plugin for Kubernetes を含むクラスターに Amazon VPC CNI plugin for Kubernetes ネットワークポリシーを適用する場合、Amazon EC2 Linux ノードにのみポリシーを適用できます。Fargate または Windows ノードにはポリシーを適用できません。
+ ネットワークポリシーは`IPv4` または `IPv6` アドレスのいずれかのみを適用しますが、両方は適用しません。`IPv4` クラスターではVPC CNI は `IPv4` アドレスをポッドに割り当て、`IPv4` ポリシーを適用します。`IPv6` クラスターではVPC CNI は `IPv6` アドレスをポッドに割り当て、`IPv6` ポリシーを適用します。`IPv6` クラスターに適用された `IPv4` ネットワークポリシールールは無視されます。`IPv4` クラスターに適用された `IPv6` ネットワークポリシールールは無視されます。
**ネットワークポリシー**
+ ネットワークポリシーはデプロイの一部である Pod にのみ適用されます。`metadata.ownerReferences` セットを持たないスタンドアロンの Pod ではネットワークポリシーを適用できません。
+ 同じ Pod に複数のネットワークポリシーを適用できます。同じ Pod を選択するポリシーが 2 つ以上設定されている場合、すべてのポリシーが Pod に適用されます。
+ ある IP アドレス範囲 (CIDR) に許可されるポートとプロトコルの組み合わせの最大数は、ネットワークポリシー全体で 24 です。`namespaceSelector` などのセレクターは、1 つ以上の CIDR に解決されます。複数のセレクターが 1 つの CIDR に解決される場合や、同一または異なるネットワークポリシーに同じ直接 CIDR を複数回指定した場合に、この制限が考慮されます。
+ どの Kubernetes サービスでも、サービスポートはコンテナポートと同じでなければなりません。名前付きポートを使用している場合はサービス仕様でも同じ名前を使用してください。
**管理者ネットワークポリシー**
1. **管理者層ポリシー (最初に評価)**: 管理者階層のすべての ClusterNetworkPolicy が他のポリシーよりも先に評価されます。管理者階層内では、優先順位に従って (優先順位番号の最も小さいものから) ポリシーが処理されます。次にどうなるかは、アクションタイプによって決まります。
+ **拒否アクション (最も高い優先順位)**: 拒否アクションを定義した管理者ポリシーがトラフィックと一致すると、そのトラフィックは他のポリシーとは関係なくすぐにブロックされます。ClusterNetworkPolicy や NetworkPolicy ルールはそれ以上処理されません。これにより、組織全体のセキュリティコントロールを名前空間レベルのポリシーで上書きできないようにしています。
+ **許可アクション**: 拒否ルールが評価されると、許可アクションを定義した管理者ポリシーが優先順位に従って (優先順位番号の最も小さいものから) 処理されます。許可アクションに一致すると、トラフィックは受け入れられ、ポリシーはそれ以上評価されません。これらのポリシーは、ラベルセレクターに基づいて複数の名前空間に対するアクセスを許可して、特定のリソースにどのワークロードがアクセスできるかを一元的に制御できます。
+ **パスアクション**: 管理階層ポリシーにパスアクションを定義すると、意思決定が下位の階層に委任されます。トラフィックがパスルールに一致すると、そのトラフィックの残りの管理者階層ルールの評価がスキップされ、NetworkPolicy 階層に直接進みます。これにより、管理者は特定のトラフィックパターンに対する制御をアプリケーションチームに明示的に委任できます。例えば、パスルールを使用すると、外部アクセスを厳密に制御しつつ、名前空間内のトラフィック管理を名前空間管理者に委任できます。
1. **ネットワークポリシー階層**: 拒否または許可に一致する管理者階層ポリシーがない場合や、パスアクションが一致した場合、次は名前空間範囲の NetworkPolicy リソースが評価されます。これらは個々の名前空間内できめ細かく制御できるポリシーで、アプリケーションチームによって管理されます。名前空間範囲のポリシーでは、管理者ポリシーよりも厳しく制限を課すことができます。管理者ポリシーによる拒否の判断を上書きすることはできませんが、管理者ポリシーによって許可またはパスされたトラフィックをさらに制限できます。
1. **ベースライン階層管理ポリシー**: トラフィックに一致する管理者ポリシーや名前空間範囲のポリシーがない場合、ベースライン階層の ClusterNetworkPolicy が評価されます。これにより、デフォルトのセキュリティ体制を名前空間範囲のポリシーで上書きできるため、管理者が組織全体のデフォルトを設定する一方で、チームが必要に応じて柔軟にカスタマイズできます。ベースラインポリシーは、優先順位に従って (優先順位番号の最も小さいものから) 評価されます。
1. **デフォルト拒否 (一致するポリシーがない場合)**: この deny-by-default 動作により、明示的に認められた接続のみが許可されるため、強力なセキュリティ体制を維持できます。
**移行**
+ クラスターが現在サードパーティーソリューションを使用して Kubernetes ネットワークポリシーを管理している場合、同じポリシーを Amazon VPC CNI plugin for Kubernetes で使用できます。ただし、同じポリシーを管理しないように、既存のソリューションを削除する必要があります。
**警告**
ネットワークポリシーソリューションを削除したら、そのソリューションが適用されていたすべてのノードを置き換えることをお勧めします。ソリューションのポッドが突然終了した場合に、トラフィックルールが残ってしまう可能性があるためです。
**インストール**。
+ ネットワークポリシー機能では`policyendpoints.networking.k8s.aws` と呼ばれる `PolicyEndpoint` カスタムリソース定義 (CRD が作成され、必要になります。カスタムリソースの `PolicyEndpoint` オブジェクトは Amazon EKS によって管理されます。これらのリソースを変更または削除しないでください。
+ インスタンスロールの IAM 認証情報を使用するポッドを実行するか、EC2 IMDS に接続するポッドを実行する場合はEC2 IMDS へのアクセスをブロックするネットワークポリシーがないか慎重に確認してください。EC2 IMDS へのアクセスを許可するネットワークポリシーを追加する必要がある場合があります。詳細については「Amazon EC2 ユーザーガイド」の「[インスタンスメタデータとユーザーデータ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html)」を参照してください。
*サービスアカウントの IAM ロール*または *EKS Pod Identity* を使用するポッドはEC2 IMDS にアクセスしません。
+ Amazon VPC CNI plugin for Kubernetes は、各ポッドの追加のネットワークインターフェイスにはネットワークポリシーを適用せず、各ポッドのプライマリインターフェイス (`eth0`) のみにネットワークポリシーを適用します。これは以下のアーキテクチャに影響します：
+ `ENABLE_V4_EGRESS` 変数が `true` に設定された `IPv6` ポッド。この変数により、`IPv4` エグレス機能が IPv6 ポッドをクラスター外のエンドポイントなどの `IPv4` エンドポイントに接続できるようになります。`IPv4` エグレス機能は、ローカルループバック IPv4 アドレスを持つ追加のネットワークインターフェースを作成することで機能します。
+ Multus などのチェーンネットワークプラグインを使用する場合。これらのプラグインは各ポッドにネットワークインターフェースを追加するため、ネットワークポリシーはチェーンネットワークプラグインには適用されません。
# Kubernetes ネットワークポリシーを使用して Pod ネットワークトラフィックを制限する
Kubernetes ネットワークポリシーを使用して、自分の Pod 間で送受信されるネットワークトラフィックを制限できます。詳細については、Kubernetes ドキュメントの「[ネットワークポリシー](https://kubernetes.io/docs/concepts/services-networking/network-policies/)」を参照してください。
この機能を使用するには以下を設定する必要があります：
1. Pod 起動時のポリシーの適用を設定します。これは VPC CNI `DaemonSet` の `aws-node` コンテナでできます。
1. アドオンのネットワークポリシーパラメータを有効にします。
1. Kubernetes ネットワークポリシーを使用するようにクラスターを設定します。
開始する前に、考慮事項を確認してください。詳細については「[考慮事項](cni-network-policy.md#cni-network-policy-considerations)」を参照してください。
## 前提条件
この機能の前提条件は次のとおりです。
### 最小クラスターバージョン
既存の Amazon EKS クラスター。デプロイするには「[Amazon EKS の使用を開始する](getting-started.md)」を参照してください。クラスターは、次の表に示す Kubernetes バージョンとプラットフォームバージョンのいずれかを実行している必要があります。一覧にあるバージョンより後の Kubernetes とプラットフォームのバージョンもサポートされることにご注意ください。現在の Kubernetes バージョンを確認するには、次のコマンドの *my-cluster* をクラスターの名前に置き換えて、変更したコマンドを実行します。
```
aws eks describe-cluster --name my-cluster --query cluster.version --output text
```
| Kubernetes バージョン | プラットフォームバージョン |
| --- | --- |
| `1.27.4` | `eks.5` |
| `1.26.7` | `eks.6` |
### 最小 VPC CNI バージョン
標準 Kubernetes ネットワークポリシーと管理者ネットワークポリシーの両方を作成するには、VPC CNI プラグインのバージョン `1.21` を実行する必要があります。現在のバージョンは、次のコマンドで確認できます。
```
kubectl describe daemonset aws-node --namespace kube-system | grep amazon-k8s-cni: | cut -d : -f 3
```
バージョンが `1.21` より前の場合は、[Amazon VPC CNI を更新する (Amazon EKS アドオン)](vpc-add-on-update.md) を確認してバージョン `1.21` 以降にアップグレードしてください。
### 最小 Linux カーネルバージョン
ノードにはバージョン `5.10` 以降の Linux カーネルが必要です。カーネルのバージョンは、`uname -r` で確認できます。Amazon EKS 最適化 Amazon Linux、Amazon EKS 最適化高速 Amazon Linux AMI、と Bottlerocket AMI の最新バージョンを使用している場合、既に必要なカーネルバージョンがインストールされています。
Amazon EKS 最適化高速 Amazon Linux AMI `v20231116` バージョン以降には、カーネルバージョン `5.10` があります。
## ステップ 1: Pod 起動時のポリシーの適用を設定する
Amazon VPC CNI plugin for Kubernetes はポッドのプロビジョニングと並行して、ポッドのネットワークポリシーを設定します。新しいポッドにすべてのポリシーが設定されるまで、新しいポッドのコンテナは*デフォルトの許可ポリシー*で起動します。これは*標準モード*と呼ばれます。デフォルトの許可ポリシーはすべての ingress トラフィックと egress トラフィックが新しいポッドとの間で許可されることを意味します。例えば、新しいポッドがアクティブなポリシーで更新されるまで、ポッドにはファイアウォールルールが適用されません (すべてのトラフィックが許可されます)。
変数 `NETWORK_POLICY_ENFORCING_MODE` を `strict` に設定すると、VPC CNI を使用するポッドは*デフォルトの拒否ポリシー*で起動し、その後ポリシーが設定されます。これは *Strict モード*と呼ばれます。Strict モードではポッドがクラスター内でアクセスする必要があるすべてのエンドポイントにネットワークポリシーが必要です。この要件は CoreDNS ポッドに適用されることに注意してください。デフォルトの拒否ポリシーはホストネットワークを使用するポッドには設定されていません。
このデフォルトのネットワークポリシーはVPC CNI `DaemonSet` の `aws-node` コンテナで環境変数 `NETWORK_POLICY_ENFORCING_MODE` を `strict` に設定することで変更できます。
```
env:
- name: NETWORK_POLICY_ENFORCING_MODE
value: "strict"
```
## ステップ 2: アドオンのネットワークポリシーパラメータを有効にする
ネットワークポリシー機能はデフォルトでノード上のポート `8162` をメトリクスに使用します。また、この機能はヘルスプローブにポート `8163` を使用します。そのノード上、またはこれらのポートを使用する必要があるポッド内で他のアプリケーションを実行すると、そのアプリは実行できません。VPC CNI バージョン `v1.14.1` 以降で、これらのポートを変更できます。
アドオンのネットワークポリシーパラメータを有効にするには次の手順に従います。
### AWS マネジメントコンソール
1. [Amazon EKS コンソール](https://console.aws.amazon.com/eks/home#/clusters)を開きます。
1. 左のナビゲーションペインで、**[クラスター]** を選択し、 Amazon VPC CNI アドオンを設定するクラスターの名前を選択してください。
1. **[アドオン]** タブを選択してください。
1. アドオンボックスの右上にあるボックスを選択し、次に **[編集]** を選択してください。
1. **[`Amazon VPC CNI` を設定]** ページで、次の操作を行います：
1. **[バージョン]** リストで `v1.14.0-eksbuild.3` 以降のバージョンを選択してください。
1. **[オプションの構成設定]** を展開します。
1. **[設定値]** に JSON キー `"enableNetworkPolicy":` と値 `"true"` を入力します。結果のテキストは有効な JSON オブジェクトでなければなりません。このキーと値だけがテキストボックス内のデータである場合はキーと値を中括弧 `{ }` で囲みます。
次の例ではネットワークポリシー機能が有効になっており、メトリクスとヘルスプローブがデフォルトのポート番号に設定されています：
```
{
"enableNetworkPolicy": "true",
"nodeAgent": {
"healthProbeBindAddr": "8163",
"metricsBindAddr": "8162"
}
}
```
### Helm
`helm` を通して Amazon VPC CNI plugin for Kubernetes をインストールしている場合、設定を更新してポートを変更できます。
1. 次に、以下のコマンドを実行して、ポートを変更します。キー `nodeAgent.metricsBindAddr` または キー `nodeAgent.healthProbeBindAddr` の値にそれぞれポート番号を設定します。
```
helm upgrade --set nodeAgent.metricsBindAddr=8162 --set nodeAgent.healthProbeBindAddr=8163 aws-vpc-cni --namespace kube-system eks/aws-vpc-cni
```
### kubectl
1. エディターで `aws-node``DaemonSet` を開きます。
```
kubectl edit daemonset -n kube-system aws-node
```
1. VPC CNI `aws-node` デーモンセットマニフェストの `aws-network-policy-agent` コンテナで、以下の `args:` のコマンド引数でポート番号を置き換えます。
```
- args:
- --metrics-bind-addr=:8162
- --health-probe-bind-addr=:8163
```
## ステップ 3: Kubernetes ネットワークポリシーを使用するようにクラスターを設定する
これはAmazon EKS アドオンまたはセルフマネージドアドオンに対して設定できます。
### Amazon EKS アドオン
AWS CLI を使用すると、次のコマンドを実行して、Kubernetes ネットワークポリシーを使用するようにクラスターを設定できます。`my-cluster` をクラスターの名前に置き換え、IAM ロール ARN を使用するロールに置き換えます。
```
aws eks update-addon --cluster-name my-cluster --addon-name vpc-cni --addon-version v1.14.0-eksbuild.3 \
--service-account-role-arn arn:aws:iam::123456789012:role/AmazonEKSVPCCNIRole \
--resolve-conflicts PRESERVE --configuration-values '{"enableNetworkPolicy": "true"}'
```
AWS マネジメントコンソールを使用してこれを設定するには、以下の手順に従います。
1. [Amazon EKS コンソール](https://console.aws.amazon.com/eks/home#/clusters)を開きます。
1. 左のナビゲーションペインで、**[クラスター]** を選択し、 Amazon VPC CNI アドオンを設定するクラスターの名前を選択してください。
1. **[アドオン]** タブを選択してください。
1. アドオンボックスの右上にあるボックスを選択し、次に **[編集]** を選択してください。
1. **[`Amazon VPC CNI` を設定]** ページで、次の操作を行います：
1. **[バージョン]** リストで `v1.14.0-eksbuild.3` 以降のバージョンを選択してください。
1. **[オプションの構成設定]** を展開します。
1. **[設定値]** に JSON キー `"enableNetworkPolicy":` と値 `"true"` を入力します。結果のテキストは有効な JSON オブジェクトでなければなりません。このキーと値だけがテキストボックス内のデータである場合はキーと値を中括弧 `{ }` で囲みます。次の例はネットワークポリシーが有効になっていることを示しています：
```
{ "enableNetworkPolicy": "true" }
```
次のスクリーンショットはこのシナリオの例を示しています。
![\[オプション設定でネットワークポリシーが設定されている VPC CNI アドオンを示す 。\]](http://docs.aws.amazon.com/ja_jp/eks/latest/userguide/images/console-cni-config-network-policy.png)
### セルフマネージド型アドオン
`helm` を通して Amazon VPC CNI plugin for Kubernetes をインストールしている場合、設定を更新してネットワークポリシーを有効にできます。
1. 次のコマンドを実行してネットワークポリシーを有効にします。
```
helm upgrade --set enableNetworkPolicy=true aws-vpc-cni --namespace kube-system eks/aws-vpc-cni
```
1. エディターで `amazon-vpc-cni``ConfigMap` を開きます。
```
kubectl edit configmap -n kube-system amazon-vpc-cni -o yaml
```
1. 次の行を `ConfigMap` の`data`に追加します。
```
enable-network-policy-controller: "true"
```
行を追加すると、`ConfigMap` は次の例のようになるはずです。
```
apiVersion: v1
kind: ConfigMap
metadata:
name: amazon-vpc-cni
namespace: kube-system
data:
enable-network-policy-controller: "true"
```
1. エディターで `aws-node``DaemonSet` を開きます。
```
kubectl edit daemonset -n kube-system aws-node
```
1. VPC CNI `aws-node` デーモンセットマニフェストの `aws-network-policy-agent` コンテナで、`args:` のコマンド引数 `--enable-network-policy=false` の `false` を `true` に置き換えます。
```
- args:
- --enable-network-policy=true
```
## ステップ 4. 次のステップ
設定が完了したら、`aws-node` ポッドがクラスターで実行されていることを確認します。
```
kubectl get pods -n kube-system | grep 'aws-node\|amazon'
```
出力例は次のとおりです。
```
aws-node-gmqp7 2/2 Running 1 (24h ago) 24h
aws-node-prnsh 2/2 Running 1 (24h ago) 24h
```
バージョン `1.14` 以降の `aws-node` ポッドには 2 つのコンテナがあります。以前のバージョンではネットワークポリシーが無効になっている場合、`aws-node` ポッドにコンテナは 1 つしか存在しません。
これで、Kubernetes ネットワークポリシーをクラスターにデプロイできます。
Kubernetes ネットワークポリシーを実装するために、Kubernetes の `NetworkPolicy` オブジェクトまたは `ClusterNetworkPolicy` オブジェクトを作成してクラスターにデプロイできます。`NetworkPolicy` オブジェクトの範囲は名前空間に限定されますが、`ClusterNetworkPolicy` オブジェクトの範囲はクラスター全体または複数の名前空間に限定できます。ラベルセレクター、名前空間、および IP アドレス範囲に基づいて、Pod 間のトラフィックを許可または拒否するポリシーを実装します。`NetworkPolicy` オブジェクトの作成の詳細については Kubernetes ドキュメントの「[ネットワークポリシー](https://kubernetes.io/docs/concepts/services-networking/network-policies/#networkpolicy-resource)」を参照してください。
Kubernetes `NetworkPolicy` オブジェクトの適用は、Extended Berkeley Packet Filter (eBPF) を使用して実装されます。`iptables` をベースにした実装に関連して、CPU 使用率の低下やシーケンシャルルックアップの回避など、低レイテンシーを実現し、パフォーマンス特性を発揮します。さらに、eBPF プローブは、複雑なカーネルレベルの問題のデバッグやオブザーバビリティの向上に役立つ、コンテキスト豊富なデータへのアクセスを提供します。Amazon EKS は、プローブを利用して各ノードのポリシー結果をログに記録し、そのデータを外部のログコレクターにエクスポートしてデバッグに役立てる eBPF ベースのエクスポーターをサポートしています。詳細については「[eBPFドキュメント](https://ebpf.io/what-is-ebpf/#what-is-ebpf)」を参照してください。
# Amazon EKS Pod ネットワークトラフィックの Kubernetes ネットワークポリシーを無効にする
Kubernetes ネットワークポリシーを無効にして Amazon EKS Pod ネットワークトラフィックの制限を停止する
1. すべての Kubernetes ネットワークポリシーを一覧表示します。
```
kubectl get netpol -A
```
1. 各 Kubernetes ネットワークポリシーを削除します。ネットワークポリシーを無効にする前に、すべてのネットワークポリシーを削除する必要があります。
```
kubectl delete netpol
```
1. エディタで aws-node DaemonSet を開きます。
```
kubectl edit daemonset -n kube-system aws-node
```
1. VPC CNI `aws-node` デーモンセットマニフェストの `aws-network-policy-agent` コンテナで、`args:` のコマンド引数 `--enable-network-policy=true` の `true` を `false` に置き換えます。
```
- args:
- --enable-network-policy=true
```
# Amazon EKS の Kubernetes ネットワークポリシーのトラブルシューティング
これは、Amazon VPC CNI のネットワークポリシー機能のトラブルシューティングガイドです。
このガイドでは、以下について説明します。
+ インストール情報、CRD、RBAC アクセス許可 [新しい `policyendpoints` CRD とアクセス許可](#network-policies-troubleshooting-permissions)
+ ネットワークポリシーの問題の診断時に調べるログ [ネットワークポリシーのログ](#network-policies-troubleshooting-flowlogs)
+ トラブルシューティング用の eBPF SDK ツール群の実行
+ 既知の問題と解決策 [既知の問題と解決策](#network-policies-troubleshooting-known-issues)
**注記**
ネットワークポリシーは、Kubernetes *デプロイメント*によって作成されたポッドにのみ適用されることに注意してください。VPC CNI のネットワークポリシーにおける他の制限事項については、「[考慮事項](cni-network-policy.md#cni-network-policy-considerations)」を参照してください。
[ネットワークポリシーのログ](#network-policies-troubleshooting-flowlogs)を読み、[eBPF SDK](#network-policies-ebpf-sdk) のツールを実行することにより、ネットワークポリシーを使用するネットワーク接続をトラブルシューティングおよび調査できます。
## 新しい `policyendpoints` CRD とアクセス許可
+ CRD: `policyendpoints.networking.k8s.aws`
+ Kubernetes API: `v1.networking.k8s.io` と呼ばれる `apiservice`
+ Kubernetes リソース: `Kind: NetworkPolicy`
+ RBAC: `aws-node` と呼ばれる `ClusterRole` (VPC CNI)、`eks:network-policy-controller` と呼ばれる `ClusterRole` (EKS クラスターコントロールプレーンのネットワークポリシーコントローラー)
ネットワークポリシーの場合、VPC CNI は `policyendpoints.networking.k8s.aws` と呼ばれる新しい `CustomResourceDefinition` (CRD) を作成します。VPC CNI には CRD を作成し、この CRD および VPC CNI (`eniconfigs.crd.k8s.amazonaws.com`) によってインストールされたその他の CRD の CustomResources (CR) を作成するアクセス許可が必要です。両方の CRD は GitHub の [`crds.yaml` ファイル](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/charts/aws-vpc-cni/crds/customresourcedefinition.yaml)で利用できます。具体的には、VPC CNI には `policyendpoints` の「get」、「list」、「watch」動詞のアクセス許可が必要です。
Kubernetes *ネットワークポリシー*は、`v1.networking.k8s.io` と呼ばれる `apiservice` の一部であり、これはポリシー YAML ファイル内では `apiversion: networking.k8s.io/v1` となります。VPC CNI `DaemonSet` には、Kubernetes API のこの部分を使用するアクセス許可が必要です。
VPC CNI アクセス許可は、`aws-node` と呼ばれる `ClusterRole` にあります。`ClusterRole` オブジェクトは、名前空間にグループ化されないことに注意してください。次の内容では、クラスターの `aws-node` が示されます。
```
kubectl get clusterrole aws-node -o yaml
```
```
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
labels:
app.kubernetes.io/instance: aws-vpc-cni
app.kubernetes.io/managed-by: Helm
app.kubernetes.io/name: aws-node
app.kubernetes.io/version: v1.19.4
helm.sh/chart: aws-vpc-cni-1.19.4
k8s-app: aws-node
name: aws-node
rules:
- apiGroups:
- crd.k8s.amazonaws.com
resources:
- eniconfigs
verbs:
- list
- watch
- get
- apiGroups:
- ""
resources:
- namespaces
verbs:
- list
- watch
- get
- apiGroups:
- ""
resources:
- pods
verbs:
- list
- watch
- get
- apiGroups:
- ""
resources:
- nodes
verbs:
- list
- watch
- get
- apiGroups:
- ""
- events.k8s.io
resources:
- events
verbs:
- create
- patch
- list
- apiGroups:
- networking.k8s.aws
resources:
- policyendpoints
verbs:
- get
- list
- watch
- apiGroups:
- networking.k8s.aws
resources:
- policyendpoints/status
verbs:
- get
- apiGroups:
- vpcresources.k8s.aws
resources:
- cninodes
verbs:
- get
- list
- watch
- patch
```
また、新しいコントローラーは各 EKS クラスターのコントロールプレーンで実行されます。コントローラーは、`eks:network-policy-controller` と呼ばれる `ClusterRole` のアクセス許可を使用します。次の内容では、クラスターの `eks:network-policy-controller` が示されます。
```
kubectl get clusterrole eks:network-policy-controller -o yaml
```
```
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
labels:
app.kubernetes.io/name: amazon-network-policy-controller-k8s
name: eks:network-policy-controller
rules:
- apiGroups:
- ""
resources:
- namespaces
verbs:
- get
- list
- watch
- apiGroups:
- ""
resources:
- pods
verbs:
- get
- list
- watch
- apiGroups:
- ""
resources:
- services
verbs:
- get
- list
- watch
- apiGroups:
- networking.k8s.aws
resources:
- policyendpoints
verbs:
- create
- delete
- get
- list
- patch
- update
- watch
- apiGroups:
- networking.k8s.aws
resources:
- policyendpoints/finalizers
verbs:
- update
- apiGroups:
- networking.k8s.aws
resources:
- policyendpoints/status
verbs:
- get
- patch
- update
- apiGroups:
- networking.k8s.io
resources:
- networkpolicies
verbs:
- get
- list
- patch
- update
- watch
```
## ネットワークポリシーのログ
ネットワークポリシーによって接続が許可されるか拒否されるかについての VPC CNI による各判定は、*フローログ*に記録されます。各ノードのネットワークポリシーログにはネットワークポリシーが設定されているすべてのポッドのフローログが含まれます。ネットワークポリシーログは `/var/log/aws-routed-eni/network-policy-agent.log` に保存されます。次の例は `network-policy-agent.log` ファイルからのものです。
```
{"level":"info","timestamp":"2023-05-30T16:05:32.573Z","logger":"ebpf-client","msg":"Flow Info: ","Src
IP":"192.168.87.155","Src Port":38971,"Dest IP":"64.6.160","Dest
Port":53,"Proto":"UDP","Verdict":"ACCEPT"}
```
ネットワークポリシーログはデフォルトで無効になっています。ネットワークポリシーログを有効にするには次の手順に従います。
**注記**
ネットワークポリシーログには、VPC CNI `aws-node` `DaemonSet` マニフェストの `aws-network-policy-agent` コンテナ用に vCPU をさらに 1 つ追加する必要があります。
### Amazon EKS アドオン
** AWS マネジメントコンソール **
1. [Amazon EKS コンソール](https://console.aws.amazon.com/eks/home#/clusters)を開きます。
1. 左のナビゲーションペインで、**[クラスター]** を選択し、 Amazon VPC CNI アドオンを設定するクラスターの名前を選択してください。
1. **[アドオン]** タブを選択してください。
1. アドオンボックスの右上にあるボックスを選択し、次に **[編集]** を選択してください。
1. ***Amazon VPC CNI *の設定**ページで、次の手順に従います。
1. **[バージョン]** ドロップダウンリストで `v1.14.0-eksbuild.3` 以降のバージョンを選択してください。
1. **[オプションの構成設定]** を展開します。
1. 最上位の JSON キー `"nodeAgent":` を入力してください。値は **[設定値]** にキー `"enablePolicyEventLogs":` と `"true"` の値を持つオブジェクトです。結果のテキストは有効な JSON オブジェクトでなければなりません。次の例はネットワークポリシーとネットワークポリシーログが有効になっており、ネットワークポリシーログが CloudWatch Logs に送信されていることを示しています。
```
{
"enableNetworkPolicy": "true",
"nodeAgent": {
"enablePolicyEventLogs": "true"
}
}
```
次のスクリーンショットはこのシナリオの例を示しています。
![\[オプション設定でネットワークポリシーおよび CloudWatch ログが設定されている VPC CNI アドオンを示す 。\]](http://docs.aws.amazon.com/ja_jp/eks/latest/userguide/images/console-cni-config-network-policy-logs.png)
AWS CLI
1. 次の AWS CLI コマンドを実行してください。`my-cluster` をクラスターの名前に置き換え、IAM 役割 ARN を使用する役割に置き換えます。
```
aws eks update-addon --cluster-name my-cluster --addon-name vpc-cni --addon-version v1.14.0-eksbuild.3 \
--service-account-role-arn arn:aws:iam::123456789012:role/AmazonEKSVPCCNIRole \
--resolve-conflicts PRESERVE --configuration-values '{"nodeAgent": {"enablePolicyEventLogs": "true"}}'
```
### セルフマネージド型アドオン
Helm
`helm` を通して Amazon VPC CNI plugin for Kubernetes をインストールしている場合、設定を更新してネットワークポリシーログを記述できます。
1. 次のコマンドを実行してネットワークポリシーを有効にします。
```
helm upgrade --set nodeAgent.enablePolicyEventLogs=true aws-vpc-cni --namespace kube-system eks/aws-vpc-cni
```
kubectl
`kubectl` を通して Amazon VPC CNI plugin for Kubernetes をインストールしている場合、設定を更新してネットワークポリシーログを記述できます。
1. エディターで `aws-node``DaemonSet` を開きます。
```
kubectl edit daemonset -n kube-system aws-node
```
1. VPC CNI `aws-node` `DaemonSet` マニフェストの `aws-network-policy-agent` コンテナで、`args:` のコマンド引数 `--enable-policy-event-logs=false` で `false` を `true` に置き換えます。
```
- args:
- --enable-policy-event-logs=true
```
### ネットワークポリシーログを Amazon CloudWatch Logs に送信する
Amazon CloudWatch Logs などのサービスを使用して、ネットワークポリシーログをモニタリングできます。次の方法を使用して、ネットワークポリシーログを CloudWatch Logs に送信できます。
EKS クラスターの場合、ポリシー ログは `/aws/eks/cluster-name/cluster/` の下に配置され、セルフマネージド K8S クラスターの場合、ログは `/aws/k8s-cluster/cluster/` の下に配置されます。
#### Amazon VPC CNI plugin for Kubernetes によるネットワークポリシーログの送信
ネットワークポリシーを有効にすると、2 つ目のコンテナが*ノードエージェント*の `aws-node` ポッドに追加されます。このノードエージェントはネットワークポリシーログを CloudWatch Logs に送信できます。
**注記**
ノードエージェントはネットワークポリシーログのみを送信します。VPC CNI によって作成された他のログは含まれません。
##### 前提条件
+ VPC CNI に使用している IAM 役割に、次の権限をスタンザまたは個別のポリシーとして追加します。
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"logs:DescribeLogGroups",
"logs:CreateLogGroup",
"logs:CreateLogStream",
"logs:PutLogEvents"
],
"Resource": "*"
}
]
}
```
##### Amazon EKS アドオン
** AWS マネジメントコンソール **
1. [Amazon EKS コンソール](https://console.aws.amazon.com/eks/home#/clusters)を開きます。
1. 左のナビゲーションペインで、**[クラスター]** を選択し、 Amazon VPC CNI アドオンを設定するクラスターの名前を選択してください。
1. **[アドオン]** タブを選択してください。
1. アドオンボックスの右上にあるボックスを選択し、次に **[編集]** を選択してください。
1. ***Amazon VPC CNI *の設定**ページで、次の手順に従います。
1. **[バージョン]** ドロップダウンリストで `v1.14.0-eksbuild.3` 以降のバージョンを選択してください。
1. **[オプションの構成設定]** を展開します。
1. 最上位の JSON キー `"nodeAgent":` を入力してください。値は **[設定値]** にキー `"enableCloudWatchLogs":` と `"true"` の値を持つオブジェクトです。結果のテキストは有効な JSON オブジェクトでなければなりません。次の例はネットワークポリシーとネットワークポリシーログが有効になっており、ログが CloudWatch Logs に送信されていることを示しています。
```
{
"enableNetworkPolicy": "true",
"nodeAgent": {
"enablePolicyEventLogs": "true",
"enableCloudWatchLogs": "true",
}
}
```
次のスクリーンショットはこのシナリオの例を示しています。
![\[オプション設定でネットワークポリシーおよび CloudWatch ログが設定されている VPC CNI アドオンを示す 。\]](http://docs.aws.amazon.com/ja_jp/eks/latest/userguide/images/console-cni-config-network-policy-logs-cwl.png)
** AWSCLI**
1. 次の AWS CLI コマンドを実行してください。`my-cluster` をクラスターの名前に置き換え、IAM 役割 ARN を使用する役割に置き換えます。
```
aws eks update-addon --cluster-name my-cluster --addon-name vpc-cni --addon-version v1.14.0-eksbuild.3 \
--service-account-role-arn arn:aws:iam::123456789012:role/AmazonEKSVPCCNIRole \
--resolve-conflicts PRESERVE --configuration-values '{"nodeAgent": {"enablePolicyEventLogs": "true", "enableCloudWatchLogs": "true"}}'
```
##### セルフマネージド型アドオン
**Helm**
`helm` を通して Amazon VPC CNI plugin for Kubernetes をインストールしている場合、設定を更新してネットワークポリシーログを CloudWatch Logs に送信できます。
1. 次のコマンドを実行してネットワークポリシーログを有効にし、CloudWatch Logs に送信します。
```
helm upgrade --set nodeAgent.enablePolicyEventLogs=true --set nodeAgent.enableCloudWatchLogs=true aws-vpc-cni --namespace kube-system eks/aws-vpc-cni
```
**kubectl**
1. エディターで `aws-node``DaemonSet` を開きます。
```
kubectl edit daemonset -n kube-system aws-node
```
1. VPC CNI `aws-node` `DaemonSet` マニフェストの `aws-network-policy-agent` コンテナで、`args:` の 2 つのコマンド引数 `--enable-policy-event-logs=false` および `--enable-cloudwatch-logs=false` の `false` を `true` に置き換えます。
```
- args:
- --enable-policy-event-logs=true
- --enable-cloudwatch-logs=true
```
#### Fluent Bit `DaemonSet`と一緒にネットワークポリシーログの送信
`DaemonSet` で Fluent Bit を使用してノードからログを送信する場合、ネットワークポリシーのネットワークポリシーログを含めるように設定を追加できます。次の設定例を使用できます。
```
[INPUT]
Name tail
Tag eksnp.*
Path /var/log/aws-routed-eni/network-policy-agent*.log
Parser json
DB /var/log/aws-routed-eni/flb_npagent.db
Mem_Buf_Limit 5MB
Skip_Long_Lines On
Refresh_Interval 10
```
## eBPF SDK の内容
Amazon VPC CNI plugin for Kubernetes は、複数のツールをまとめた eBPF SDK コレクションをノードにインストールします。eBPF SDK ツールを使用して、ネットワークポリシーの問題を特定できます。例えば、次のコマンドはノードで実行されているプログラムを一覧表示します。
```
sudo /opt/cni/bin/aws-eks-na-cli ebpf progs
```
このコマンドを実行するために、任意の方法を使用してノードに接続できます。
## 既知の問題と解決策
次のセクションでは、Amazon VPC CNI ネットワークポリシーの機能に関する既知の問題とその解決策について説明します。
### enable-policy-event-logs が「false」に設定されているにも関わらず、ネットワークポリシーログが生成される
**問題**: `enable-policy-event-logs` 設定が `false` に設定されている場合でも、EKS VPC CNI によってネットワークポリシーログが生成される。
**解決策**: `enable-policy-event-logs` 設定はポリシー「決定」ログのみを無効にしますが、すべてのネットワークポリシーエージェントのログ記録が無効になるわけではありません。この動作については、GitHub の「[aws-network-policy-agent README](https://github.com/aws/aws-network-policy-agent/)」に記載されています。ログ記録を完全に無効にするには、他のログ記録設定の調整が必要な場合があります。
### ネットワークポリシーマップのクリーンアップ問題
**問題**: ポッドが削除された後も、ネットワーク `policyendpoint` が残り続けてクリーンアップされない問題。
**解決策**: この問題は、VPC CNI アドオンバージョン 1.19.3-eksbuild.1 による問題で発生しました。この問題を解決するには、VPC CNI アドオンの新しいバージョンに更新してください。
### ネットワークポリシーが適用されない
**問題**: Amazon VPC CNI プラグインでネットワークポリシー機能が有効になっているが、ネットワークポリシーが正しく適用されない。
ネットワークポリシー `kind: NetworkPolicy` を作成してもポッドに影響を与えない場合、ポリシーエンドポイントオブジェクトがポッドと同じ名前空間で作成されていることを確認します。名前空間に `policyendpoint` オブジェクトがない場合、ネットワークポリシーコントローラー (EKS クラスターの一部) が、ネットワークポリシーエージェント (VPC CNI の一部) が適用するためのネットワークポリシールールを作成できなかったということです。
**解決策**: この解決策は、VPC CNI (`ClusterRole`: `aws-node`) およびネットワークポリシーコントローラー (`ClusterRole`: `eks:network-policy-controller`) のアクセス許可を修正し、Kyverno などのポリシー実施ツールでこれらのアクションを許可することです。Kyverno ポリシーが `policyendpoint` オブジェクトの作成をブロックしていないことを確認してください。必要なアクセス許可については、「[新しい `policyendpoints` CRD とアクセス許可](#network-policies-troubleshooting-permissions)」で前のセクションを参照してください。
### strict モードでポリシーを削除してもポッドがデフォルトの拒否状態に戻らない
**問題**: ネットワークポリシーが strict モードで有効になっている場合、ポッドはデフォルト拒否ポリシーで開始されます。ポリシーが適用されると、指定されたエンドポイントへのトラフィックが許可されます。しかし、ポリシーが削除されても、ポッドがデフォルト拒否状態に戻らず、代わりにデフォルト許可状態になってしまいます。
**解決策**: この問題は、ネットワークポリシーエージェント 1.2.0 のリリースを含む VPC CNI リリース 1.19.3 で修正されました。修正後は、strict モードを有効にすると、ポリシーが削除されるとポッドは期待どおりにデフォルト拒否状態に戻ります。
### ポッドの起動レイテンシーのセキュリティグループ
**問題**: EKS でポッド機能のセキュリティグループを使用すると、ポッドの起動レイテンシーが増加する。
**解決策**: レイテンシーは、VPC リソースコントローラーがポッドのブランチ ENI を作成するために使用する `CreateNetworkInterface` API の API スロットリングによるリソースコントローラーのレート制限によるものです。このオペレーションのアカウントの API 制限を確認し、必要に応じて上限の引き上げをリクエストすることを検討してください。
### vpc.amazonaws.com/pod-eni の不足による FailedScheduling
**問題**: 以下のエラーにより、ポッドのスケジューリングが失敗する: `FailedScheduling 2m53s (x28 over 137m) default-scheduler 0/5 nodes are available: 5 Insufficient vpc.amazonaws.com/pod-eni. preemption: 0/5 nodes are available: 5 No preemption victims found for incoming pod.`
**解決策**: 前の問題と同様に、ポッドにセキュリティグループを割り当てると、ポッドスケジューリングのレイテンシーが増加し、各 ENI を追加する時間の CNI しきい値を超えて増加するため、ポッド起動が失敗する原因になります。これは、Podのセキュリティグループを使用するときに予期される動作です。ワークロードアーキテクチャを設計する際、スケジューリングの影響を考慮してください。
### IPAM の接続問題とセグメンテーション障害
**問題**: IPAM の接続問題、スロットリングのリクエスト、セグメンテーションの障害など、複数のエラーが発生する。
+ `Checking for IPAM connectivity …`
+ `Throttling request took 1.047064274s`
+ `Retrying waiting for IPAM-D`
+ `panic: runtime error: invalid memory address or nil pointer dereference`
**解決策**: AL2023 で `systemd-udev` をインストールすると、破損を引き起こすポリシーでファイルが書き換えられるため、この問題が発生します。パッケージが更新された別の `releasever` に更新する場合、またはパッケージ自体を手動で更新する場合に発生する可能性があります。AL2023 ノードでは、`systemd-udev` をインストールまたは更新しないでください。
### デバイス名による検索失敗エラー
**問題**: エラーメッセージ: `{"level":"error","ts":"2025-02-05T20:27:18.669Z","caller":"ebpf/bpf_client.go:578","msg":"failed to find device by name eni9ea69618bf0: %!w(netlink.LinkNotFoundError={0xc000115310})"}`
**解決策**: この問題は、Amazon VPC CNI ネットワークポリシーエージェント (v1.2.0) の最新バージョンで特定されて修正されています。この問題を解決するには、VPC CNI の最新バージョンに更新してください。
### Multus CNI イメージの CVE 脆弱性
**問題**: 拡張された EKS ImageScan CVE レポートで、Multus CNI イメージバージョン v4.1.4-eksbuild.2\$1thick の脆弱性が特定されている。
**解決策**: 脆弱性のない Multus CNI イメージの新しいバージョンおよび新しい Network Policy Controller イメージに更新します。スキャナーを更新することで、以前のバージョンで見つかった脆弱性に対処できます。
### ログのフロー情報の「DENY」判定
**問題**: ネットワークポリシーログに次の DENY 判定が表示される: `{"level":"info","ts":"2024-11-25T13:34:24.808Z","logger":"ebpf-client","caller":"events/events.go:193","msg":"Flow Info: ","Src IP":"","Src Port":9096,"Dest IP":"","Dest Port":56830,"Proto":"TCP","Verdict":"DENY"}`
**解決策**: この問題は、ネットワークポリシーコントローラーの新しいバージョンで解決されています。ログ記録の問題を解決するには、最新の EKS プラットフォームバージョンに更新してください。
### Calico から移行後のポッド間の通信問題
**問題**: EKS クラスターをバージョン 1.30 にアップグレードし、ネットワークポリシーを Calico から Amazon VPC CNI に切り替えた後、ネットワークポリシーが適用されるとポッド間の通信が失敗する。ネットワークポリシーを削除すると通信は回復する。
**解決策**: VPC CNI のネットワークポリシーエージェントには、Calico ほど多くのポートを指定することができません。代わりに、ネットワークポリシーでポート範囲を使用します。ネットワークポリシーの各 `ingress:` または `egress:` セレクターの各プロトコルにおけるポートの一意の組み合わせの最大数は 24 です。ポート範囲を使用して一意のポート数を減らし、この制限を回避します。
### ネットワークポリシーエージェントがスタンドアロンポッドをサポートしない
**問題**: スタンドアロンポッドに適用されるネットワークポリシーは、一貫性のない動作を示す可能性がある。
**解決策**: 現在、ネットワークポリシーエージェントは、デプロイメント/レプリカセットの一部としてデプロイされたポッドのみをサポートしています。ネットワークポリシーがスタンドアロンポッドに適用された場合、一貫性のない動作を示す可能性があります。これは、このページの上部の「[考慮事項](cni-network-policy.md#cni-network-policy-considerations)」および GitHub の「[aws-network-policy-agent の GitHub 問題 \$1327](https://github.com/aws/aws-network-policy-agent/issues/327)」に記載されています。整合性のあるネットワークポリシーの動作のため、デプロイまたはレプリカセットの一部としてポッドをデプロイします。
# Amazon EKS のネットワークポリシーの星型デモ
このデモでは、Amazon EKS クラスターにフロントエンド、バックエンド、およびクライアントサービスを作成します。また、このデモでは、各サービス間で利用可能な入力および出力のパスを示す管理グラフィカルユーザーインターフェースが作成されます。実稼働ワークロードを実行しないクラスターでデモを完了することをお勧めします。
ネットワークポリシーを作成する前に、サービスはすべて、双方向に通信できます。ネットワークポリシーを適用すると、クライアントはフロントエンドサービスとのみ通信でき、バックエンドはフロントエンドからのみトラフィックを受け付けます。
1. フロントエンド、バックエンド、クライアント、および管理ユーザーインターフェイスサービスを適用します。
```
kubectl apply -f https://raw.githubusercontent.com/aws-samples/eks-workshop/2f9d29ed3f82ed6b083649e975a0e574fb8a4058/content/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/namespace.yaml
kubectl apply -f https://raw.githubusercontent.com/aws-samples/eks-workshop/2f9d29ed3f82ed6b083649e975a0e574fb8a4058/content/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/management-ui.yaml
kubectl apply -f https://raw.githubusercontent.com/aws-samples/eks-workshop/2f9d29ed3f82ed6b083649e975a0e574fb8a4058/content/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/backend.yaml
kubectl apply -f https://raw.githubusercontent.com/aws-samples/eks-workshop/2f9d29ed3f82ed6b083649e975a0e574fb8a4058/content/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/frontend.yaml
kubectl apply -f https://raw.githubusercontent.com/aws-samples/eks-workshop/2f9d29ed3f82ed6b083649e975a0e574fb8a4058/content/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/client.yaml
```
1. クラスター上の Pod をすべて表示します。
```
kubectl get pods -A
```
出力例は次のとおりです。
出力では、次の出力に示す名前空間にポッドが表示されます。`READY` 列内のポッドの *NAMES* とポッド数は、次の出力とは異なります。似たような名前のポッドが見えて、それらがすべて `STATUS` 列内に `Running` を持つまで続けないでください。
```
NAMESPACE NAME READY STATUS RESTARTS AGE
[...]
client client-xlffc 1/1 Running 0 5m19s
[...]
management-ui management-ui-qrb2g 1/1 Running 0 5m24s
stars backend-sz87q 1/1 Running 0 5m23s
stars frontend-cscnf 1/1 Running 0 5m21s
[...]
```
1. 管理ユーザーインターフェイスに接続するには、クラスターで実行されているサービスの `EXTERNAL-IP` に接続します。
```
kubectl get service/management-ui -n management-ui
```
1. ブラウザーを開いて、前のステップの場所に移動します。管理ユーザーインターフェイスが表示されます。**[C]** ノードはクライアントサービス、**[F]** ノードはフロントエンドサービス、**[B]** ノードはバックエンドサービスを表します。各ノードには、太字の色付きの行で示されるように、他のすべてのノードへの完全な通信アクセスが含まれます。
![\[オープンネットワークポリシー\]](http://docs.aws.amazon.com/ja_jp/eks/latest/userguide/images/stars-default.png)
1. 相互にサービスを分離するには、次のネットワークポリシーを `stars` および `client` の名前空間の両方に適用します。
```
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
name: default-deny
spec:
podSelector:
matchLabels: {}
```
次のコマンドを使用して、ポリシーを両方の名前空間に適用できます。
```
kubectl apply -n stars -f https://raw.githubusercontent.com/aws-samples/eks-workshop/2f9d29ed3f82ed6b083649e975a0e574fb8a4058/content/beginner/120_network-policies/calico/stars_policy_demo/apply_network_policies.files/default-deny.yaml
kubectl apply -n client -f https://raw.githubusercontent.com/aws-samples/eks-workshop/2f9d29ed3f82ed6b083649e975a0e574fb8a4058/content/beginner/120_network-policies/calico/stars_policy_demo/apply_network_policies.files/default-deny.yaml
```
1. ブラウザを更新します。管理ユーザーインターフェイスはノードに到達できなくなるため、ユーザーインターフェイスに表示されないことがわかります。
1. 管理ユーザーインターフェイスがサービスにアクセスできるように、次の別のネットワークポリシーを適用します。このポリシーを適用して UI を許可します。
```
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
namespace: stars
name: allow-ui
spec:
podSelector:
matchLabels: {}
ingress:
- from:
- namespaceSelector:
matchLabels:
role: management-ui
```
このポリシーを適用してクライアントを許可します。
```
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
namespace: client
name: allow-ui
spec:
podSelector:
matchLabels: {}
ingress:
- from:
- namespaceSelector:
matchLabels:
role: management-ui
```
次のコマンドを使用して両方のポリシーを適用できます。
```
kubectl apply -f https://raw.githubusercontent.com/aws-samples/eks-workshop/2f9d29ed3f82ed6b083649e975a0e574fb8a4058/content/beginner/120_network-policies/calico/stars_policy_demo/apply_network_policies.files/allow-ui.yaml
kubectl apply -f https://raw.githubusercontent.com/aws-samples/eks-workshop/2f9d29ed3f82ed6b083649e975a0e574fb8a4058/content/beginner/120_network-policies/calico/stars_policy_demo/apply_network_policies.files/allow-ui-client.yaml
```
1. ブラウザを更新します。管理ユーザーインターフェイスは再びノードにアクセスできますが、ノードは相互に通信できないことがわかります。
![\[UI アクセスネットワークポリシー\]](http://docs.aws.amazon.com/ja_jp/eks/latest/userguide/images/stars-no-traffic.png)
1. フロントエンドサービスからバックエンドサービスへのトラフィックを許可するには、次のネットワークポリシーを適用します。
```
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
namespace: stars
name: backend-policy
spec:
podSelector:
matchLabels:
role: backend
ingress:
- from:
- podSelector:
matchLabels:
role: frontend
ports:
- protocol: TCP
port: 6379
```
1. ブラウザを更新します。フロントエンドがバックエンドと通信できることがわかります。
![\[フロントエンドからバックエンドまでのポリシー\]](http://docs.aws.amazon.com/ja_jp/eks/latest/userguide/images/stars-front-end-back-end.png)
1. クライアントからフロントエンドサービスへのトラフィックを許可するには、次のネットワークポリシーを適用します。
```
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
namespace: stars
name: frontend-policy
spec:
podSelector:
matchLabels:
role: frontend
ingress:
- from:
- namespaceSelector:
matchLabels:
role: client
ports:
- protocol: TCP
port: 80
```
1. ブラウザを更新します。クライアントがフロントエンドサービスと通信できることがわかります。フロントエンドサービスは、バックエンドサービスと引き続き通信できます。
![\[最終ネットワークポリシー\]](http://docs.aws.amazon.com/ja_jp/eks/latest/userguide/images/stars-final.png)
1. (オプション) デモが完了したら、そのリソースを削除することができます。
```
kubectl delete -f https://raw.githubusercontent.com/aws-samples/eks-workshop/2f9d29ed3f82ed6b083649e975a0e574fb8a4058/content/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/client.yaml
kubectl delete -f https://raw.githubusercontent.com/aws-samples/eks-workshop/2f9d29ed3f82ed6b083649e975a0e574fb8a4058/content/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/frontend.yaml
kubectl delete -f https://raw.githubusercontent.com/aws-samples/eks-workshop/2f9d29ed3f82ed6b083649e975a0e574fb8a4058/content/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/backend.yaml
kubectl delete -f https://raw.githubusercontent.com/aws-samples/eks-workshop/2f9d29ed3f82ed6b083649e975a0e574fb8a4058/content/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/management-ui.yaml
kubectl delete -f https://raw.githubusercontent.com/aws-samples/eks-workshop/2f9d29ed3f82ed6b083649e975a0e574fb8a4058/content/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/namespace.yaml
```
リソースを削除した後でも、ノード上にネットワークポリシーエンドポイントが残っている場合があり、それがクラスター内のネットワークを予期しない方法で妨げることがあります。これらのルールを削除する唯一の確実な方法は、ノードを再起動するか、すべてのノードを終了して、リサイクルすることです。すべてのノードを終了するには、Auto Scaling グループの必要数を 0 に設定してから目的数にバックアップするか、単にノードを終了します。
# カスタムネットワーキングを使用して代替サブネットに Pod をデプロイする
**適用対象**: Linux `IPv4` Fargate ノード、Amazon EC2 インスタンスを持つ Linux ノード
![\[ネットワークインターフェイスが複数あるノードの図\]](http://docs.aws.amazon.com/ja_jp/eks/latest/userguide/images/cn-image.png)
Amazon VPC CNI plugin for Kubernetes が、Amazon EC2 ノード用にセカンダリ [Elastic Network Interface](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html) (ネットワークインターフェイス) を作成する際には、デフォルトで、ノードのプライマリネットワークインターフェイスと同じサブネットがその格納先になります。また、プライマリネットワークインターフェイスに関連付けられているものと同じセキュリティグループが、セカンダリネットワークインターフェイスにも関連付けられます。以下の 1 つ以上の理由により、プラグインを使用して異なるサブネットにセカンダリネットワークインターフェイスを作成させたり、セカンダリネットワークインターフェイスに異なるセキュリティグループを関連付けたり、また、その両方を行ったりする必要性が生じることがあります。
+ プライマリネットワークインターフェイスが存在するサブネットで使用可能な `IPv4` アドレスには、数の上で制限があります。これにより、サブネット内に作成できる Pod の数に制限が生じる可能性があります。セカンダリネットワークインターフェイス用に別のサブネットを指定すると、Pod のために使用可能な `IPv4` アドレスの数を増やすことができます。
+ セキュリティ上の理由からも、ノードのプライマリネットワークインターフェイスで使用するものとは異なるセキュリティグループまたはサブネットが、Pod に必要となる場合があります。
+ ノードをパブリックサブネット内に構成した場合、Pod はプライベートサブネット内に配置します。パブリックサブネットに関連付けられているルートテーブルには、インターネットゲートウェイへのルートが含まれています。プライベートサブネットに関連付けられているルートテーブルには、インターネットゲートウェイへのルートは含まれません。
**ヒント**
また、カスタムネットワーキングを使用することなく Amazon EKS クラスターに直接新規または既存のサブネットを追加することもできます。詳細については、「[管理コンソールから既存の VPC サブネットを Amazon EKS クラスターに追加する](eks-networking.md#add-existing-subnet)」を参照してください。
## 考慮事項
この機能を使用する際の考慮事項を次に示します。
+ カスタムネットワーキングを有効にすると、プライマリネットワークインターフェイスに割り当てられた IP アドレスが、Pod に割り当てられることはなくなります。Pod には、セカンダリネットワークインターフェイスからの IP アドレスのみが割り当てられます。
+ クラスターで `IPv6` ファミリーを使用している場合は、カスタムネットワーキングを使用することはできません。
+ `IPv4` アドレスの枯渇を軽減するために、カスタムネットワーキングを使用する予定の場合は、`IPv6` ファミリーを使用してクラスターを作成することもできます。詳細については、「[クラスター、Pod、サービスに対する IPv6 アドレスの説明](cni-ipv6.md)」を参照してください。
+ サブネットにデプロイされたセカンダリネットワークインターフェイス用の Pod が、ノードのプライマリネットワークインターフェイスとは異なるサブネットおよびセキュリティグループを使用できるように設定されていても、そのサブネットとセキュリティグループは、ノードと同じ VPC 内に配置される必要があります。
+ Fargate の場合、サブネットは Fargate プロファイルを介して制御されます。詳細については、「[起動時にどの Pod が AWS Fargate を使用するのかを定義する](fargate-profile.md)」を参照してください。
# Amazon EKS ノードのセカンダリネットワークインターフェイスをカスタマイズする
このチュートリアルを開始する前に以下を完了してください：
+ 考慮事項を確認する
+ Amazon VPC CNI plugin for Kubernetes によるセカンダリネットワークインターフェイスの作成と、Pod への IP アドレス割り当て方法に関する知識。詳細については、GitHub の「[ENI Allocation](https://github.com/aws/amazon-vpc-cni-k8s#eni-allocation)」(ENI 割り当て) を参照してください。
+ ご使用のデバイスまたは AWS クラウドシェル で、バージョン `2.12.3` 以降、または AWS コマンドラインインターフェイス (AWS CLI のバージョン `1.27.160` 以降がインストールおよび設定されていること。現在のバージョンを確認するには「`aws --version | cut -d / -f2 | cut -d ' ' -f1`」を参照してください。`yum`、`apt-get`、macOS 用の Homebrew などのパッケージマネージャーは、多くの場合 AWS CLI の最新バージョンより数バージョン古くなっています。最新バージョンをインストールするには「*AWS コマンドラインインターフェイスユーザーガイド*」の「[インストール](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html)」および「[aws configure を使用したクイック設定](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config)」を参照してください。AWS クラウドシェル にインストールされている AWS CLI バージョンも最新バージョンより数バージョン遅れることがあります。更新するには、「*AWS CloudShell ユーザーガイド*」の「[ホームディレクトリへの AWS CLI のインストール](https://docs.aws.amazon.com/cloudshell/latest/userguide/vm-specs.html#install-cli-software)」を参照してください。
+ デバイスまたは AWS クラウドシェル に、`kubectl` コマンドラインツールがインストールされていること。`kubectl` をインストールまたはアップグレードする方法については「[`kubectl` および `eksctl` のセットアップ](install-kubectl.md)」を参照してください。
+ このトピック内のステップはBash シェル内で実行することが推奨されます。Bash シェルを使用していない場合、行継続文字や、変数の設定と使用に関する方法など、一部のスクリプトコマンドのためにシェルの調整が必要となります。さらに、シェルの引用規則とエスケープ規則は異なる場合があります。詳細については「AWS コマンドラインインターフェイスのユーザーガイド」の「[AWS CLI での文字列への引用符の使用](https://docs.aws.amazon.com/cli/latest/userguide/cli-usage-parameters-quoting-strings.html)」を参照してください。
このチュートリアルでは置き換えが必要だと明記されている場合を除き、サンプル値をそのまま使用することをお勧めします。本番向けクラスター向けにステップを完了する際には例値 を任意の値に置き換えることができます。すべてのステップは同一のターミナルで実行することをお勧めします。設定された変数はステップ全体で使用され、また、これらは異なるターミナルには存在しないためです。
このトピックのコマンドは「[AWS CLI 使用例を使用する](https://docs.aws.amazon.com/cli/latest/userguide/welcome-examples.html)」に記載されている規則に従ってフォーマットされています。使用している AWS CLI [プロファイル](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-profiles)で定義されているデフォルトの AWS リージョンとは異なる AWS リージョンにあるリソースに対してコマンドラインからコマンドを実行する場合はコマンドに `--region us-west-2` を追加する必要があります。`us-west-2` は自分の AWS リージョンに置き換えます。
カスタムネットワーキングを本番用クラスターにデプロイする場合は、[ステップ 2: VPC を設定する](#custom-networking-configure-vpc) にスキップします。
## ステップ 1: テスト VPC およびクラスターを作成する
次の手順により、テスト VPC とクラスターを作成し、そのたクラスターのためにカスタムネットワークを構成できます。本番向けのクラスターで必要になるいくつかの機能で、このトピックに関連のないものについては説明していません。そのため、本番ワークロード向けに、このテストクラスターを使用することはお勧めしません。詳細については、「[Amazon EKS クラスターを作成します。](create-cluster.md)」を参照してください。
1. 以下のコマンドを実行して、`account_id` 変数を定義します。
```
account_id=$(aws sts get-caller-identity --query Account --output text)
```
1. VPC を作成します。
1. テストシステムにデプロイする場合は Amazon EKS AWS クラウドフォーメーション テンプレートを使用して VPC を作成します。
```
aws cloudformation create-stack --stack-name my-eks-custom-networking-vpc \
--template-url https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2020-10-29/amazon-eks-vpc-private-subnets.yaml \
--parameters ParameterKey=VpcBlock,ParameterValue=192.168.0.0/24 \
ParameterKey=PrivateSubnet01Block,ParameterValue=192.168.0.64/27 \
ParameterKey=PrivateSubnet02Block,ParameterValue=192.168.0.96/27 \
ParameterKey=PublicSubnet01Block,ParameterValue=192.168.0.0/27 \
ParameterKey=PublicSubnet02Block,ParameterValue=192.168.0.32/27
```
1. AWS クラウドFormation スタックが作成されるまで数分かかります。次のコマンドを実行して、スタックのデプロイステータスを確認します。
```
aws cloudformation describe-stacks --stack-name my-eks-custom-networking-vpc --query Stacks\[\].StackStatus --output text
```
コマンドの出力が「`CREATE_COMPLETE`」になるまで、次のステップに進まないでください。
1. テンプレートによって作成された、プライベートサブネット ID の値により変数を定義します。
```
subnet_id_1=$(aws cloudformation describe-stack-resources --stack-name my-eks-custom-networking-vpc \
--query "StackResources[?LogicalResourceId=='PrivateSubnet01'].PhysicalResourceId" --output text)
subnet_id_2=$(aws cloudformation describe-stack-resources --stack-name my-eks-custom-networking-vpc \
--query "StackResources[?LogicalResourceId=='PrivateSubnet02'].PhysicalResourceId" --output text)
```
1. 前のステップで取得した、サブネットのアベイラビリティーゾーンを使用して変数を定義します。
```
az_1=$(aws ec2 describe-subnets --subnet-ids $subnet_id_1 --query 'Subnets[*].AvailabilityZone' --output text)
az_2=$(aws ec2 describe-subnets --subnet-ids $subnet_id_2 --query 'Subnets[*].AvailabilityZone' --output text)
```
1. クラスターの IAM ロールを作成します。
1. IAM 信頼ポリシー用の JSON ファイルを作成するには次のコマンドを実行してください。
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "eks.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
1. Amazon EKS クラスター の IAM ロールを作成します。必要に応じて、`eks-cluster-role-trust-policy.json` の前に、ステップでファイルの書き込み先となったコンピュータ上のパスを追加します。このコマンドは前のステップで作成した信頼ポリシーをロールに関連付けます。IAM ロールを作成するにはロールを作成する [IAM プリンシパル](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal)に `iam:CreateRole` アクション (許可) を割り当てる必要があります。
```
aws iam create-role --role-name myCustomNetworkingAmazonEKSClusterRole --assume-role-policy-document file://"eks-cluster-role-trust-policy.json"
```
1. [AmazonEKSClusterPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSClusterPolicy.html#AmazonEKSClusterPolicy-json) という名前の Amazon EKS マネージド型ポリシーをロールにアタッチします。IAM ポリシーを [IAM プリンシパル](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal)にアタッチするにはポリシーのアタッチを行っているプリンシパルに、次のいずれかの IAM アクション (許可) を割り当てる必要があります: `iam:AttachUserPolicy` または `iam:AttachRolePolicy`
```
aws iam attach-role-policy --policy-arn arn:aws:iam::aws:policy/AmazonEKSClusterPolicy --role-name myCustomNetworkingAmazonEKSClusterRole
```
1. Amazon EKS クラスターを作成し、このクラスターとデバイスの間の通信を設定します。
1. クラスターを作成する。
```
aws eks create-cluster --name my-custom-networking-cluster \
--role-arn arn:aws:iam::$account_id:role/myCustomNetworkingAmazonEKSClusterRole \
--resources-vpc-config subnetIds="$subnet_id_1","$subnet_id_2"
```
**注記**
リクエストで指定したアベイラビリティーゾーンのいずれかに、Amazon EKS クラスターの作成に十分な容量がない場合にはエラーが表示されることがあります。このエラー出力には新しいクラスターをサポートできるアベイラビリティーゾーンが表示されます。アカウント向けにサポートされているアベイラビリティーゾーンにある 2 つ以上のサブネットを使用して、クラスターを作成します。詳細については「[容量不足](troubleshooting.md#ice)」を参照してください。
1. クラスターが作成されるまでに数分かかります。次のコマンドを実行して、クラスターのデプロイステータスを確認します。
```
aws eks describe-cluster --name my-custom-networking-cluster --query cluster.status
```
コマンドの出力が「`"ACTIVE"`」になるまで、次のステップに進まないでください。
1. クラスターと通信するために `kubectl` を設定します。
```
aws eks update-kubeconfig --name my-custom-networking-cluster
```
## ステップ 2: VPC を設定する
このチュートリアルでは、[ステップ 1: テスト VPC およびクラスターを作成する](#custom-networking-create-cluster) で作成した VPC が必要です。本番向けクラスターの場合は、example values をすべて実際の値に置き換えて、VPC に合うように各ステップを調整します。
1. 現在インストールされている Amazon VPC CNI plugin for Kubernetes が最新バージョンであることを確認します。Amazon EKS アドオンタイプの最新バージョンを確認し、そのバージョンに更新するには「[Amazon EKS アドオンを更新する](updating-an-add-on.md)」を参照してください。セルフマネージドアドオンタイプの最新バージョンを確認し、そのバージョンに更新するには「[Amazon VPC CNI を使用して Pod に IP を割り当てる](managing-vpc-cni.md)」を参照してください。
1. クラスター VPC の ID を取得し、後のステップで使用するために変数に格納します。
```
vpc_id=$(aws eks describe-cluster --name my-custom-networking-cluster --query "cluster.resourcesVpcConfig.vpcId" --output text)
```
1. 追加の Classless Inter-Domain Routing (CIDR ブロックを、クラスターの VPC に関連付けます。CIDR ブロックは既存の関連付けられた CIDR ブロックと重複することはできません。
1. 現在 VPC に関連付けられている CIDR ブロックを表示します。
```
aws ec2 describe-vpcs --vpc-ids $vpc_id \
--query 'Vpcs[*].CidrBlockAssociationSet[*].{CIDRBlock: CidrBlock, State: CidrBlockState.State}' --out table
```
出力例は次のとおりです。
```
----------------------------------
| DescribeVpcs |
+-----------------+--------------+
| CIDRBlock | State |
+-----------------+--------------+
| 192.168.0.0/24 | associated |
+-----------------+--------------+
```
1. 追加の CIDR ブロックを VPC に関連付けます。次のコマンドで CIDR ブロック値を置き換えます。詳細については「Amazon VPC ユーザーガイド」の「[追加の IPv4 CIDR ブロックと VPC の関連付け](https://docs.aws.amazon.com/vpc/latest/userguide/modify-vpcs.html#add-ipv4-cidr)」を参照してください。
```
aws ec2 associate-vpc-cidr-block --vpc-id $vpc_id --cidr-block 192.168.1.0/24
```
1. 新しいブロックが関連付けられていることを確認します。
```
aws ec2 describe-vpcs --vpc-ids $vpc_id --query 'Vpcs[*].CidrBlockAssociationSet[*].{CIDRBlock: CidrBlock, State: CidrBlockState.State}' --out table
```
出力例は次のとおりです。
```
----------------------------------
| DescribeVpcs |
+-----------------+--------------+
| CIDRBlock | State |
+-----------------+--------------+
| 192.168.0.0/24 | associated |
| 192.168.1.0/24 | associated |
+-----------------+--------------+
```
新しい CIDR ブロックの `State` が `associated` に遷移するまで、次のステップには進まないでください。
1. 既存のサブネットが存在する各アベイラビリティーゾーン内で、使用するサブネットを必要な数だけ作成します。前のステップで VPC に関連付けた、CIDR ブロック内にある CIDR ブロックを指定します。
1. 新しいサブネットを作成します。次のコマンドで CIDR ブロック値を置き換えます。サブネットは既存のサブネットが置かれているものとは異なる VPC CIDR ブロックの中に作成する必要があり、作成するアベイラビリティーゾーンは既存のサブネットと同じにする必要があります。この例では現在のプライベートサブネットが存在する各アベイラビリティーゾーンにある新しい CIDR ブロックの中に、1 つのサブネットが作成されます。作成されたサブネットの ID は後のステップで使用するために変数に格納されます。`Name` の値は前のステップで Amazon EKS VPC テンプレートを使用して作成されたサブネットに、割り当てられている値と一致します。名前は必須ではありません。名前には異なる値を使用できます。
```
new_subnet_id_1=$(aws ec2 create-subnet --vpc-id $vpc_id --availability-zone $az_1 --cidr-block 192.168.1.0/27 \
--tag-specifications 'ResourceType=subnet,Tags=[{Key=Name,Value=my-eks-custom-networking-vpc-PrivateSubnet01},{Key=kubernetes.io/role/internal-elb,Value=1}]' \
--query Subnet.SubnetId --output text)
new_subnet_id_2=$(aws ec2 create-subnet --vpc-id $vpc_id --availability-zone $az_2 --cidr-block 192.168.1.32/27 \
--tag-specifications 'ResourceType=subnet,Tags=[{Key=Name,Value=my-eks-custom-networking-vpc-PrivateSubnet02},{Key=kubernetes.io/role/internal-elb,Value=1}]' \
--query Subnet.SubnetId --output text)
```
**重要**
デフォルトで新しいサブネットはVPC の[メインルートテーブル](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Route_Tables.html#RouteTables)に暗黙的に関連付けられます。このルートテーブルにより、その VPC にデプロイされているすべてのリソース間の通信が可能になります。ただし、VPC に関連付けられた CIDR ブロックの外部にある IP アドレスが割り当てられたリソースとの通信は許可されません。この動作を変更するには独自のルートテーブルをサブネットに関連付けます。詳細については「Amazon VPC ユーザーガイド」の「[サブネットルートテーブル](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Route_Tables.html#subnet-route-tables)」を参照してください。
1. 使用している VPC の現在のサブネットを表示します。
```
aws ec2 describe-subnets --filters "Name=vpc-id,Values=$vpc_id" \
--query 'Subnets[*].{SubnetId: SubnetId,AvailabilityZone: AvailabilityZone,CidrBlock: CidrBlock}' \
--output table
```
出力例は次のとおりです。
```
----------------------------------------------------------------------
| DescribeSubnets |
+------------------+--------------------+----------------------------+
| AvailabilityZone | CidrBlock | SubnetId |
+------------------+--------------------+----------------------------+
| us-west-2d | 192.168.0.0/27 | subnet-example1 |
| us-west-2a | 192.168.0.32/27 | subnet-example2 |
| us-west-2a | 192.168.0.64/27 | subnet-example3 |
| us-west-2d | 192.168.0.96/27 | subnet-example4 |
| us-west-2a | 192.168.1.0/27 | subnet-example5 |
| us-west-2d | 192.168.1.32/27 | subnet-example6 |
+------------------+--------------------+----------------------------+
```
作成した `192.168.1.0` CIDR ブロック内のサブネットが、`192.168.0.0` CIDR ブロック内のサブネットと同じアベイラビリティーゾーンに置かれていることが確認できます。
## ステップ 3: Kubernetes リソースを設定する
1. `aws-node` DaemonSet で `AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG` 環境変数を `true` に設定します。
```
kubectl set env daemonset aws-node -n kube-system AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG=true
```
1. [クラスターのセキュリティグループ](sec-group-reqs.md)の ID を取得し、次のステップで使用するために変数に格納します。このセキュリティグループはクラスターの作成時に Amazon EKS により自動的に作成されます。
```
cluster_security_group_id=$(aws eks describe-cluster --name my-custom-networking-cluster --query cluster.resourcesVpcConfig.clusterSecurityGroupId --output text)
```
1. Pod をデプロイするサブネットごとに `ENIConfig` カスタムリソースを作成します。
1. 各ネットワークインターフェイス設定に固有のファイルを作成します。
次のコマンドでは、前のステップで作成した 2 つのサブネットのそれぞれに、個別の `ENIConfig` ファイルが作成されます。`name` の値は一意である必要があります。これらの名前はサブネットが存在するアベイラビリティーゾーンと同じものが付けられます。クラスターセキュリティグループは、`ENIConfig` に割り当てられます。
```
cat >$az_1.yaml <$az_2.yaml <
1. ノードの IAM ロールを作成します。
1. IAM 信頼ポリシー用の JSON ファイルを作成するには次のコマンドを実行してください。
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "ec2.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
1. IAM ロールを作成し、返された Amazon リソースネーム (ARN) を、後のステップで使用するために変数に格納します。
```
node_role_arn=$(aws iam create-role --role-name myCustomNetworkingNodeRole --assume-role-policy-document file://"node-role-trust-relationship.json" \
--query Role.Arn --output text)
```
1. IAM ロールに、3 つの必須な IAM マネージドポリシーをアタッチします。
```
aws iam attach-role-policy \
--policy-arn arn:aws:iam::aws:policy/AmazonEKSWorkerNodePolicy \
--role-name myCustomNetworkingNodeRole
aws iam attach-role-policy \
--policy-arn arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryReadOnly \
--role-name myCustomNetworkingNodeRole
aws iam attach-role-policy \
--policy-arn arn:aws:iam::aws:policy/AmazonEKS_CNI_Policy \
--role-name myCustomNetworkingNodeRole
```
**重要**
分かりやすくするため、このチュートリアルでは[AmazonEKS\$1CNI\$1Policy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKS_CNI_Policy.html) ポリシーはノードの IAM ロールにアタッチされています。ただし、本番向けクラスターの場合は、Amazon VPC CNI plugin for Kubernetes のみで使用される IAM ロールに、個別にポリシーをアタッチすることをお勧めします。詳細については、「[IRSA を使用するように Amazon VPC CNI プラグインを設定する](cni-iam-role.md)」を参照してください。
1. 次のいずれかのタイプのノードグループを作成します。デプロイするインスタンスタイプを確認するには「[最適な Amazon EC2 ノードインスタンスタイプを選択する](choosing-instance-type.md)」を参照してください。このチュートリアルのために、**マネージド型**、および**起動テンプレートを使用しない、または AMI ID が指定されていない起動テンプレートを使用する**オプションを完了します。本番ワークロードでノードグループを使用する場合はそのグループをデプロイする前に、[マネージドノードグループ](create-managed-node-group.md)および[セルフマネージドノードグループ](worker.md)のすべてのオプションについて理解しておくことをお勧めします。
+ **マネージド型** — 次のいずれかのオプションを使用して、ノードグループをデプロイします：
+ **起動テンプレートを使用しない、または AMI ID が指定されていない起動テンプレートを使用する** — 次のコマンドを実行してください。このチュートリアルではサンプルの値を使用します。本番向けのノードグループの場合はすべてのサンプルの値を、実際の値に置き換えてください。ノードグループ名は 63 文字以下である必要があります。先頭は文字または数字でなければなりませんが、残りの文字にはハイフンおよびアンダースコアを含めることもできます。
```
aws eks create-nodegroup --cluster-name my-custom-networking-cluster --nodegroup-name my-nodegroup \
--subnets $subnet_id_1 $subnet_id_2 --instance-types t3.medium --node-role $node_role_arn
```
+ **指定された AMI ID を持つ起動テンプレートを使用**
1. ノードでの Pod について、Amazon EKS で推奨される最大数を決定します。「」の指示に従い、そのトピックのステップ 3 で `--cni-custom-networking-enabled` を追加します。後のステップで使用するために、この出力を書き留めます。
1. 起動テンプレートで、Amazon EKS 最適化 AMI ID を指定するか、Amazon EKS 最適化 AMI から構築されたカスタム AMI を指定します。その後、[起動テンプレートを使用してノードグループをデプロイ](launch-templates.md)し、さらに、起動テンプレートにある次のユーザーデータを指定します。このユーザーデータは、引数を `NodeConfig` 仕様に渡します。NodeConfig の詳細については、「[NodeConfig API リファレンス](https://awslabs.github.io/amazon-eks-ami/nodeadm/doc/api/#nodeconfig)」を参照してください。`20` は、前のステップで使用した値 (推奨) か、または独自の値に置き換えることができます。
```
---
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="BOUNDARY"
--BOUNDARY
Content-Type: application/node.eks.aws
---
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
cluster:
name: my-cluster
...
kubelet:
config:
maxPods: 20
```
Amazon EKS 最適化 AMI から構築されていないカスタム AMI を作成した場合は自分で設定をカスタム作成する必要があります。
+ **セルフマネージド型**
1. ノードでの Pod について、Amazon EKS で推奨される最大数を決定します。 の手順に従います (`--cni-custom-networking-enabled` をステップ 3 に追加してください)。後のステップで使用するために、この出力を書き留めます。
1. [セルフマネージド Amazon Linux ノードを作成する](launch-workers.md) の手順に従ってノードグループをデプロイします。
**注記**
本番クラスター内のノードで、非常に大量の Pod をサポートさせる場合には、「」のスクリプトを再度実行します。また、このコマンドには `--cni-prefix-delegation-enabled` オプションを追加します。例えば、`m5.large` インスタンスタイプの場合は `110` が返されます。この機能を有効化する方法については「[プレフィックスを使用して Amazon EKS ノードに割り当てる IP アドレスを増やす](cni-increase-ip-addresses.md)」を参照してください。この機能はカスタムネットワーキングで使用できます。
1. ノードグループの作成には数分かかります。次のコマンドを使用すると、マネージド型のノードグループ作成のステータスを確認できます。
```
aws eks describe-nodegroup --cluster-name my-custom-networking-cluster --nodegroup-name my-nodegroup --query nodegroup.status --output text
```
出力が「`ACTIVE`」を返すまで、次のステップに進まないでください。
1. このチュートリアルではこのステップをスキップできます。
本番向けのクラスターにおいて、`ENIConfigs` の名前を、それが使用されているアベイラビリティーゾーンと同じにしなかった場合にはノードに対し、そのノードで使用すべき `ENIConfig` の名前をアノテーションします。各アベイラビリティーゾーンにサブネットが 1 つしかなく、`ENIConfigs` にアベイラビリティーゾーンと同じ名前を付けている場合にはこのステップは必要ありません。[前のステップ](#custom-networking-automatically-apply-eniconfig)でその設定を有効にしている場合、Amazon VPC CNI plugin for Kubernetes が適切な `ENIConfig` をノードに対し自動的に関連付けるためです。
1. クラスター内のノードのリストを取得します。
```
kubectl get nodes
```
出力例は次のとおりです。
```
NAME STATUS ROLES AGE VERSION
ip-192-168-0-126.us-west-2.compute.internal Ready 8m49s v1.22.9-eks-810597c
ip-192-168-0-92.us-west-2.compute.internal Ready 8m34s v1.22.9-eks-810597c
```
1. 各ノードが属するアベイラビリティーゾーンを決定します。前の出力に基づいて IP アドレスを置き換えて、前のステップで返されたノードごとに次のコマンドを実行します。
```
aws ec2 describe-instances --filters Name=network-interface.private-dns-name,Values=ip-192-168-0-126.us-west-2.compute.internal \
--query 'Reservations[].Instances[].{AvailabilityZone: Placement.AvailabilityZone, SubnetId: SubnetId}'
```
出力例は次のとおりです。
```
[
{
"AvailabilityZone": "us-west-2d",
"SubnetId": "subnet-Example5"
}
]
```
1. 各ノードを、サブネット ID とアベイラビリティーゾーンのために作成した `ENIConfig` でアノテーションします。各ノードのアノテーションに使用できる `ENIConfig` は 1 つだけです。ただし、複数のノードに対し同じ `ENIConfig` でアノテーションすることは可能です。値の例 は実際に使用する値に置き換えます。
```
kubectl annotate node ip-192-168-0-126.us-west-2.compute.internal k8s.amazonaws.com/eniConfig=EniConfigName1
kubectl annotate node ip-192-168-0-92.us-west-2.compute.internal k8s.amazonaws.com/eniConfig=EniConfigName2
```
1. カスタムネットワーキング機能の使用に切り替える前に、Pod を実行している本稼働クラスターにノードがあった場合は、以下のタスクを完了してください。
1. カスタムネットワーク機能を使用しているノードが、使用可能であることを確認します。
1. ノードを遮断およびドレインして、Pod をスムーズにシャットダウンします。詳細については、Kubernetes ドキュメントの「[Safely Drain a Node](https://kubernetes.io/docs/tasks/administer-cluster/safely-drain-node/)」(ノードを安全にドレインする) を参照してください。
1. ノードを終了します。ノードが既存のマネージド型ノードグループ内にある場合はそのノードグループを削除できます。以下のコマンドを実行してください。
```
aws eks delete-nodegroup --cluster-name my-custom-networking-cluster --nodegroup-name my-nodegroup
```
カスタムネットワーク機能は`k8s.amazonaws.com/eniConfig` ラベルで登録されている新しいノードでのみ使用されます。
1. Pod に、前の手順で作成したサブネットの 1 つに関連付けられた CIDR ブロックから、IP アドレスが割り当てられていることを確認します。
```
kubectl get pods -A -o wide
```
出力例は次のとおりです。
```
NAMESPACE NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
kube-system aws-node-2rkn4 1/1 Running 0 7m19s 192.168.0.92 ip-192-168-0-92.us-west-2.compute.internal
kube-system aws-node-k96wp 1/1 Running 0 7m15s 192.168.0.126 ip-192-168-0-126.us-west-2.compute.internal
kube-system coredns-657694c6f4-smcgr 1/1 Running 0 56m 192.168.1.23 ip-192-168-0-92.us-west-2.compute.internal
kube-system coredns-657694c6f4-stwv9 1/1 Running 0 56m 192.168.1.28 ip-192-168-0-92.us-west-2.compute.internal
kube-system kube-proxy-jgshq 1/1 Running 0 7m19s 192.168.0.92 ip-192-168-0-92.us-west-2.compute.internal
kube-system kube-proxy-wx9vk 1/1 Running 0 7m15s 192.168.0.126 ip-192-168-0-126.us-west-2.compute.internal
```
VPC に追加した `192.168.1.0` CIDR ブロックからの IP アドレスが、coredns Pod に割り当てられていることが確認できます。カスタムネットワーキングを使用していない場合はここに `192.168.0.0` CIDR ブロックからのアドレスが割り当てられています。この CIDR ブロックが、元々 VPC に関連付けられている唯一のブロックであるためです。
Pod の `spec` が `hostNetwork=true` を含む場合には、ノードのプライマリ IP アドレスが割り当てられます。追加したサブネットのアドレスは割り当てられません。デフォルトではこの値は `false` に設定されます。クラスターで実行される `kube-proxy` および Amazon VPC CNI plugin for Kubernetes (`aws-node`) の Pod に対して、この値は `true` に設定されます。これが、`kube-proxy` とプラグインの `aws-node` の Pod に、前の出力にある 192.168.1.x アドレスが割り当てられない理由です。Pod の `hostNetwork` 設定の詳細については、Kubernetes API リファレンスの「[PodSpec v1 core](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.35/#podspec-v1-core)」を参照してください。
## ステップ 5: チュートリアルでのリソースを削除する
このチュートリアル完了後は作成したリソースを削除することをお勧めします。その後、ここでのステップを調整して、本番向けクラスターのカスタムネットワーキングを有効化することができます。
1. 作成したノードグループが完全にテスト向けである場合はそれを削除してください。
```
aws eks delete-nodegroup --cluster-name my-custom-networking-cluster --nodegroup-name my-nodegroup
```
1. AWS CLI から、クラスターが削除済みだと出力された場合でも、実際にはその削除プロセスが完了していない場合があります。削除のプロセスには数分かかります。次のコマンドを実行して、処理の完了を確認します。
```
aws eks describe-nodegroup --cluster-name my-custom-networking-cluster --nodegroup-name my-nodegroup --query nodegroup.status --output text
```
次のように出力されるまで、次に進まないでください。
```
An error occurred (ResourceNotFoundException) when calling the DescribeNodegroup operation: No node group found for name: my-nodegroup.
```
1. 作成したノードグループが完全にテスト向けである場合はノードの IAM ロールを削除します。
1. ロールからポリシーをデタッチします。
```
aws iam detach-role-policy --role-name myCustomNetworkingNodeRole --policy-arn arn:aws:iam::aws:policy/AmazonEKSWorkerNodePolicy
aws iam detach-role-policy --role-name myCustomNetworkingNodeRole --policy-arn arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryReadOnly
aws iam detach-role-policy --role-name myCustomNetworkingNodeRole --policy-arn arn:aws:iam::aws:policy/AmazonEKS_CNI_Policy
```
1. ロールを削除します。
```
aws iam delete-role --role-name myCustomNetworkingNodeRole
```
1. クラスターを削除します。
```
aws eks delete-cluster --name my-custom-networking-cluster
```
以下のコマンドを使用して、クラスターが削除されたことを確認します。
```
aws eks describe-cluster --name my-custom-networking-cluster --query cluster.status --output text
```
次のような出力が返された場合はクラスターが正常に削除されています。
```
An error occurred (ResourceNotFoundException) when calling the DescribeCluster operation: No cluster found for name: my-custom-networking-cluster.
```
1. クラスターの IAM ロールを削除します。
1. ロールからポリシーをデタッチします。
```
aws iam detach-role-policy --role-name myCustomNetworkingAmazonEKSClusterRole --policy-arn arn:aws:iam::aws:policy/AmazonEKSClusterPolicy
```
1. ロールを削除します。
```
aws iam delete-role --role-name myCustomNetworkingAmazonEKSClusterRole
```
1. 前のステップで作成したサブネットを削除します。
```
aws ec2 delete-subnet --subnet-id $new_subnet_id_1
aws ec2 delete-subnet --subnet-id $new_subnet_id_2
```
1. 作成した VPC を削除します。
```
aws cloudformation delete-stack --stack-name my-eks-custom-networking-vpc
```
# プレフィックスを使用して Amazon EKS ノードに割り当てる IP アドレスを増やす
**適用対象**: Amazon EC2 インスタンスを持つ Linux および Windows ノード
**適用対象**: パブリックサブネットおよびプライベートサブネット
各 Amazon EC2 インスタンスではエラスティックネットワークインターフェイス の最大数と、各ネットワークインターフェイスに割り当て可能な IP アドレスの最大数がサポートされています。各ノードにはネットワークインターフェースごとに 1 つの IP アドレスが必要です。その他の使用可能な IP アドレスはすべて `Pods` に割り当てることができます。`Pod` それぞれに固有の IP アドレスが必要です。その結果、使用可能なコンピューティングリソースとメモリリソースはあるが、`Pods` に割り当てる IP アドレスが不足しているために追加の `Pods` に対応できないノードが存在する可能性があります。
個別のセカンダリ IP アドレスではなく、IP プレフィックスをノードに割り当てて、ノードで`Pods`に割り当て可能な IP アドレスの数を増やす方法について説明します。各プレフィックスには複数の IP アドレスが含まれます。IP プレフィックスが割り当てられるようにクラスターを設定しない場合、クラスターは Pod 接続に必要なネットワークインターフェイスと IP アドレスを設定するために Amazon EC2 アプリケーションプログラミングインターフェイス (API) の呼び出しをさらに実行する必要があります。クラスターのサイズが大きくなるにつれて、これらの API コールの頻度が高くなるため、Pod とインスタンスの起動時間が長くなる場合があります。これにより、大規模でスパイク的なワークロードの需要を満たすためにスケーリングの遅延が発生します。また、スケーリング要件を満たすためには追加のクラスターと VPC をプロビジョニングする必要があるため、コストと管理オーバーヘッドも増加します。詳細については「GitHub」の「[Kubernetes スケーラビリティ閾値](https://github.com/kubernetes/community/blob/master/sig-scalability/configs-and-limits/thresholds.md)」を参照してください。
## Amazon VPC CNI plugin for Kubernetes 機能との互換性
次の機能で IP プレフィックスを使用できます：
+ IPv4 ソースネットワークアドレス変換 - 詳細については「[Pod のアウトバウンドインターネットアクセスを有効にする](external-snat.md)」を参照してください。
+ クラスター、ポッド、サービスへの IPv6 アドレス - 詳細については「[クラスター、Pod、サービスに対する IPv6 アドレスの説明](cni-ipv6.md)」を参照してください。
+ Kubernetes ネットワークポリシーを使用したトラフィックの制限 - 詳細については、「[Kubernetes ネットワークポリシーにより Pod トラフィックを制限する](cni-network-policy.md)」を参照してください。
次のリストは適用される Amazon VPC CNI プラグイン設定に関する情報を示しています。各設定の詳細については、GitHub の「[amazon-vpc-cni-k8s](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/README.md)」を参照してください。
+ `WARM_IP_TARGET`
+ `MINIMUM_IP_TARGET`
+ `WARM_PREFIX_TARGET`
## 考慮事項
この機能を使用する場合は以下を考慮してください：
+ 各 Amazon EC2 インスタンスタイプでは、Pod の最大数がサポートされています。マネージドノードグループが複数のインスタンスタイプで構成されている場合、クラスターのインスタンスで指定する Pod の最大数の内、最小の値がクラスター内のすべてのノードに適用されます。
+ デフォルトでは1 つのノードで実行できる `Pods` の最大数は 110 ですが、この値は変更できます。数値を変更し、既存のマネージド型ノードグループがある場合、ノードグループの AMI または起動テンプレートを次に更新するときに、新しいノードで変更済みの値が適用されるようになります。
+ IP アドレスの割り当てから IP プレフィックスの割り当てに移行する場合は既存のノードにローリング置換を実行するのではなく、新しいノードグループを作成して使用可能な IP アドレスの数を増やすことをお勧めします。IP アドレスと IP プレフィックスの両方が割り当てられているノードで Pod を実行すると、アドバタイズされた IP アドレスの容量に不一致が生じ、ノード上の将来のワークロードに影響する可能性があります。推奨される移行方法については、「*Amazon EKS Best Practices Guide*」の「[Prefix Delegation mode for Linux](https://docs.aws.amazon.com/eks/latest/best-practices/prefix-mode-linux.html)」を参照してください。
+ セキュリティグループのスコープはノードレベル - 詳細については「[セキュリティグループ](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html)」を参照してください。
+ ネットワークインターフェイスに割り当てられた IP プレフィックスはノードあたりの高い Pod 密度をサポートし、最適な起動時間になっています。
+ IP プレフィックスと IP アドレスは標準の Amazon EC2 Elastic ネットワークインターフェイスに関連付けられています。特定のセキュリティグループを必要とする Pod には、ブランチネットワークインターフェイスのプライマリ IP アドレスが割り当てられます。IP アドレスを取得するポッド、または IP プレフィックスからの IP アドレスを、同じノード上のブランチネットワークインターフェイスを取得する Pod と混在させることができます。
+ Linux ノードのみを含むクラスターの場合。
+ ネットワークインターフェイスにプレフィックスを割り当てるようにアドオンを設定すると、クラスター内のすべてのノードグループにあるすべてのノードを削除しない限り、Amazon VPC CNI plugin for Kubernetes アドオンを `1.9.0` (または `1.10.1`) より前のバージョンにダウングレードすることはできません。
+ Pod のセキュリティグループ (`POD_SECURITY_GROUP_ENFORCING_MODE`=`standard` および `AWS_VPC_K8S_CNI_EXTERNALSNAT`=`false` に設定) も使用している場合、Pod が VPC の外部のエンドポイントと通信するときに、Pod に割り当てた任意のセキュリティグループではなく、ノードのセキュリティグループが使用されます。
[セキュリティグループ](security-groups-for-pods.md) (`POD_SECURITY_GROUP_ENFORCING_MODE`=`strict` に設定) も使用している場合、`Pods` が VPC の外部のエンドポイントと通信するときに、`Pod’s` セキュリティグループが使用されます。
# Amazon EKS ノードで使用可能な IP アドレスを増やす
個別のセカンダリ IP アドレスではなく、IP プレフィックスをノードに割り当てて、ノードで Pod に割り当て可能な IP アドレスの数を増やす方法について説明します。
## 前提条件
+ 既存のクラスターが必要です。デプロイするには「[Amazon EKS クラスターを作成します。](create-cluster.md)」を参照してください。
+ Amazon EKS ノードが配置されているサブネットでは、`/28` 個の連続ブロック (`IPv4` クラスターの場合)、または `/80` 個の Classless Inter-Domain Routing (CIDR) ブロック (`IPv6` クラスターの場合) が十分な数として必要になります。`IPv6` クラスターに含めることができるのは Linux ノードだけです。IP アドレスがサブネット CIDR 全体に分散している場合、IP プレフィックスを使用すると失敗する可能性があります。次の構成を推奨します。
+ サブネット CIDR 予約を使用すると、予約された範囲内の IP アドレスがまだ使用されている場合でも、解放時に IP アドレスが再割り当てされません。これにより、セグメンテーションなしでプレフィックスを割り当てることができます。
+ IP プレフィックスが割り当てられているワークロードの実行に特に使用される新しいサブネットを使用してください。IP プレフィックスを割り当てると、Windows と Linux 両方のワークロードを同じサブネットで実行できます。
+ ノードに IP プレフィックスを割り当てるには、ノードが AWS Nitro ベースである必要があります。Nitro ベースではないインスタンスでは、引き続き個別のセカンダリ IP アドレスが割り当てられますが、Pod に割り当てることのできる IP アドレスの数は Nitro ベースのインスタンスよりも大幅に少なくなります。
+ **Linux ノードのみのクラスターの場合** – クラスターが `IPv4` ファミリーで設定されている場合は、バージョン `1.9.0` 以降の Amazon VPC CNI plugin for Kubernetes アドオンがインストールされている必要があります。現在のバージョンは、次のコマンドで確認できます。
```
kubectl describe daemonset aws-node --namespace kube-system | grep Image | cut -d "/" -f 2
```
クラスターが `IPv6` ファミリーで設定されている場合は、バージョン `1.10.1` のアドオンがインストールされている必要があります。プラグインバージョンが必要なバージョンよりも古い場合は、更新する必要があります。詳細については、「[Amazon VPC CNI を使用してポッドに IP を割り当てる](managing-vpc-cni.md)」の更新セクションを参照してください。
+ **Windows ノードのみのクラスターの場合**
+ クラスターで Windows サポートを有効にする必要があります。詳細については、「[EKS クラスターに WiWindows ノードをデプロイする](windows-support.md)」を参照してください。
## ノードに IP アドレスプレフィックスを割り当てる
ノードに IP アドレスプレフィックスを割り当てるようにクラスターを設定します。ノードのオペレーティングシステムに対応する手順を完了します。
### Linux
1. パラメータを有効にして、Amazon VPC CNI DaemonSet のネットワークインターフェイスにプレフィックスを割り当てます。クラスターをデプロイすると、バージョン `1.10.1` 以降の Amazon VPC CNI plugin for Kubernetes アドオンも同時にデプロイされます。`IPv6` ファミリーを使用してクラスターを作成している場合、この設定はデフォルトで `true` に設定されています。`IPv4` ファミリーを使用してクラスターを作成している場合、この設定はデフォルトで `false` に設定されています。
```
kubectl set env daemonset aws-node -n kube-system ENABLE_PREFIX_DELEGATION=true
```
**重要**
サブネットに使用可能な IP アドレスがある場合でも、サブネットに使用可能な `/28` 個の連続したブロックがない場合には、Amazon VPC CNI plugin for Kubernetes ログに次のエラーが記述されます。
```
InsufficientCidrBlocks: The specified subnet does not have enough free cidr blocks to satisfy the request
```
これは、サブネット全体に広がる既存のセカンダリ IP アドレスの断片化が原因で発生する可能性があります。このエラーを解決するには、新しいサブネットを作成してそこに Pod を起動するか、Amazon EC2 サブネットの CIDR 予約を使用して、プレフィックス割り当てで使用するサブネット内の領域を予約します。詳細については、Amazon VPC ユーザーガイドの「[サブネット CIDR の予約](https://docs.aws.amazon.com/vpc/latest/userguide/subnet-cidr-reservation.html)」を参照してください。
1. 前提条件のリストに記載されたバージョン以降の Amazon VPC CNI plugin for Kubernetes を使用しながら、起動テンプレートなしでマネージドノードグループをデプロイする場合、または AMI ID を指定していない起動テンプレートを使用してデプロイする場合には、このまま次のステップに進みます。マネージド型ノードグループは、Pod の最大数を自動的に計算します。
AMI ID を指定した起動テンプレートを使用して、セルフマネージド型ノードグループまたはマネージド型ノードグループをデプロイする場合は、Amazon EKS でノードの推奨最大 Pod 数を決定する必要があります。「」の指示に従い、ステップ 3 に `--cni-prefix-delegation-enabled` を追加します。後のステップで使用するために、出力に注意してください。
**重要**
マネージド型ノードグループは、`maxPods` の値に最大数を適用します。vCPUs が 30 未満のインスタンスの場合、最大数は 110 で、その他すべてのインスタンスの最大数は 250 です。この最大数は、プレフィックス委任が有効かどうかにかかわらず適用されます。
1. `IPv6` 用に設定されたクラスターを使用している場合は、このまま次のステップに進みます。
以下のオプションの内の 1 つでパラメータを指定します。どのオプションが適切で、どの値を提供するかを決定するには、GitHub の「[WARM\$1PREFIX\$1TARGET, WARM\$1IP\$1TARGET, and MINIMUM\$1IP\$1TARGET](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/docs/prefix-and-ip-target.md)」を参照してください。
example values は、ゼロより大きい値で置き換えます。
+ `WARM_PREFIX_TARGET`
```
kubectl set env ds aws-node -n kube-system WARM_PREFIX_TARGET=1
```
+ `WARM_IP_TARGET` または `MINIMUM_IP_TARGET` – この値を設定した場合、`WARM_PREFIX_TARGET` に対し設定されている値はすべて上書きされます。
```
kubectl set env ds aws-node -n kube-system WARM_IP_TARGET=5
```
```
kubectl set env ds aws-node -n kube-system MINIMUM_IP_TARGET=2
```
1. 少なくとも 1 つの Amazon EC2 Nitro Amazon Linux 2023 インスタンスタイプを使用して、次のいずれかのタイプのノードグループを作成します。Nitro インスタンスタイプのリストについては、「Amazon EC2 ユーザーガイド」の「[Instances built on the Nitro System](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html#ec2-nitro-instances)」を参照してください。この機能は Windows ではサポートされていません。*110* が含まれているオプションの場合は、ステップ 3 の値 (推奨) または独自の値に置き換えてください。
+ **セルフマネージド** –「[セルフマネージド Amazon Linux ノードを作成する](launch-workers.md)」の手順に従い、ノードグループをデプロイします。CloudFormation スタックを作成する前に、テンプレートファイルを開き、次のように `UserData` の `NodeLaunchTemplate` を調整します。
```
...
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
cluster:
name: ${ClusterName}
apiServerEndpoint: ${ApiServerEndpoint}
certificateAuthority: ${CertificateAuthorityData}
cidr: ${ServiceCidr}
kubelet:
config:
maxPods: 110
...
```
`eksctl` を使用してノードグループを作成する場合は、次のコマンドを使用できます。
```
eksctl create nodegroup --cluster my-cluster --managed=false --max-pods-per-node 110
```
+ **マネージド型** — 次のいずれかのオプションを使用して、ノードグループをデプロイします：
+ **起動テンプレートがない場合、または AMI ID が指定されていない起動テンプレートを使用する場合** –「[クラスターのマネージドノードグループを作成する](create-managed-node-group.md)」の手順を完了します。マネージド型ノードグループは、Amazon EKS で推奨される `max-pods` の値を自動的に計算します。
+ **指定した AMI ID を持つ起動テンプレート** — 起動テンプレートで Amazon EKS 最適化 AMI ID を指定するか、Amazon EKS 最適化 AMI から構築されたカスタム AMI を指定してから、[起動テンプレートを使用してノードグループをデプロイ](launch-templates.md)起動テンプレートでは、次のユーザーデータを指定します。このユーザーデータが `NodeConfig` オブジェクトを渡してノードの `nodeadm` ツールによって読み取られます。`nodeadm` の詳細については、[nodeadm のドキュメント](https://awslabs.github.io/amazon-eks-ami/nodeadm)を参照してください。
```
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="//"
--//
Content-Type: application/node.eks.aws
---
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
cluster:
apiServerEndpoint: [.replaceable]`my-cluster`
certificateAuthority: [.replaceable]`LS0t...`
cidr: [.replaceable]`10.100.0.0/16`
name: [.replaceable]`my-cluster
kubelet:
config:
maxPods: [.replaceable]`110`
--//--
```
`eksctl` を使用してノードグループを作成する場合は、次のコマンドを使用できます。
```
eksctl create nodegroup --cluster my-cluster --max-pods-per-node 110
```
Amazon EKS 最適化 AMI から構築されていないカスタム AMI を作成した場合は、自分で設定をカスタム作成する必要があります。
**注記**
また、インスタンスとは異なるサブネットの Pod に IP アドレスを割り当てる場合は、このステップで機能を有効化する必要があります。詳細については、「[カスタムネットワーキングを使用して代替サブネットに Pod をデプロイする](cni-custom-network.md)」を参照してください。
### Server
1. IP プレフィックスの割り当てを有効にします。
1. 編集する `amazon-vpc-cni` `ConfigMap` を開きます。
```
kubectl edit configmap -n kube-system amazon-vpc-cni -o yaml
```
1. `data` セクションに次の行を追加します。
```
enable-windows-prefix-delegation: "true"
```
1. ファイルを保存し、エディタを閉じます。
1. `ConfigMap` に行が追加されたことを確認します。
```
kubectl get configmap -n kube-system amazon-vpc-cni -o "jsonpath={.data.enable-windows-prefix-delegation}"
```
返された出力が `true` でない場合は、エラーが発生した可能性があります。ステップをもう一度実行してみてください。
**重要**
サブネットに使用可能な IP アドレスがある場合でも、サブネットに使用可能な `/28` 個の連続したブロックがない場合には、Amazon VPC CNI plugin for Kubernetes ログに次のエラーが記述されます。
```
InsufficientCidrBlocks: The specified subnet does not have enough free cidr blocks to satisfy the request
```
これは、サブネット全体に広がる既存のセカンダリ IP アドレスの断片化が原因で発生する可能性があります。このエラーを解決するには、新しいサブネットを作成してそこに Pod を起動するか、Amazon EC2 サブネットの CIDR 予約を使用して、プレフィックス割り当てで使用するサブネット内の領域を予約します。詳細については、Amazon VPC ユーザーガイドの「[サブネット CIDR の予約](https://docs.aws.amazon.com/vpc/latest/userguide/subnet-cidr-reservation.html)」を参照してください。
1. (オプション) クラスターの事前スケーリング動作と動的スケーリング動作を制御するための追加設定を指定します。詳細については、「GitHub」の「[ Windows でのプレフィックス委任モードの設定オプション](https://github.com/aws/amazon-vpc-resource-controller-k8s/blob/master/docs/windows/prefix_delegation_config_options.md)」を参照してください。
1. 編集する `amazon-vpc-cni` `ConfigMap` を開きます。
```
kubectl edit configmap -n kube-system amazon-vpc-cni -o yaml
```
1. サンプル値を 0 より大きい値に置き換え、必要なエントリを `ConfigMap` の `data` セクションに追加します。`warm-ip-target` または `minimum-ip-target` のいずれかに値を設定した場合、その値は `warm-prefix-target` に設定された値をオーバーライドします。
```
warm-prefix-target: "1"
warm-ip-target: "5"
minimum-ip-target: "2"
```
1. ファイルを保存し、エディタを閉じます。
1. 少なくとも 1 つの Amazon EC2 Nitro インスタンスタイプで Windows ノードグループを作成します。Nitro インスタンスタイプのリストについては、「Amazon EC2 ユーザーガイド」の「[Instances built on the Nitro System](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/instance-types.html#ec2-nitro-instances)」を参照してください。デフォルトでは、1 つのノードにデプロイできる Pod の最大数は 110 です。この数値を増減させる場合は、ブートストラップ設定のユーザーデータに以下を指定します。*max-pods-quantity* を最大ポッド値に置き換えます。
```
-KubeletExtraArgs '--max-pods=max-pods-quantity'
```
マネージド型ノードグループをデプロイする場合は、この設定を起動テンプレートに追加する必要があります。詳細については、「[起動テンプレートを使用してマネージドノードをカスタマイズする](launch-templates.md)」を参照してください。Windows ブートストラップスクリプトの設定パラメータの詳細については、「[ブートストラップスクリプトの設定パラメータ](eks-optimized-windows-ami.md#bootstrap-script-configuration-parameters)」を参照してください。
## 最大 Pod 数と使用可能な IP アドレスを決定する
1. ノードがデプロイされると、クラスター内のノードの表示が可能になります。
```
kubectl get nodes
```
出力例は次のとおりです。
```
NAME STATUS ROLES AGE VERSION
ip-192-168-22-103.region-code.compute.internal Ready 19m v1.XX.X-eks-6b7464
ip-192-168-97-94.region-code.compute.internal Ready 19m v1.XX.X-eks-6b7464
```
1. いずれかのノードを記述して、そのノードの `max-pods` 値と使用可能な IP アドレスの数を決定します。*192.168.30.193* を、前の出力で返されたいずれかのノードの名前の `IPv4` アドレスに置き換えます。
```
kubectl describe node ip-192-168-30-193.region-code.compute.internal | grep 'pods\|PrivateIPv4Address'
```
出力例は次のとおりです。
```
pods: 110
vpc.amazonaws.com/PrivateIPv4Address: 144
```
前の出力にある `110` は、*144* 個の IP アドレスが使用可能であるにもかかわらず、Kubernetes がノードにデプロイする Pod の最大数です。
# セキュリティグループを個別の Pod に割り当てる
**適用対象**: Amazon EC2 インスタンスを持つ Linux ノード
**適用対象**: プライベートサブネット
Pod のセキュリティグループは、Amazon EC2 セキュリティグループを Kubernetes Pod と統合します。Amazon EC2 セキュリティグループを使用して、多くの Amazon EC2 インスタンスタイプと Fargate で実行されているノードにデプロイする Pod との間で送受信されるインバウンドおよびアウトバウンドネットワークトラフィックを許可するルールを定義できます。この機能の詳細な説明については「[ポッドのセキュリティグループの紹介](https://aws.amazon.com/blogs/containers/introducing-security-groups-for-pods)」の投稿を参照してください。
## Amazon VPC CNI plugin for Kubernetes 機能との互換性
Pod のセキュリティグループは、以下の機能で使用できます。
+ IPv4 ソースネットワークアドレス変換 - 詳細については「[Pod のアウトバウンドインターネットアクセスを有効にする](external-snat.md)」を参照してください。
+ クラスター、ポッド、サービスへの IPv6 アドレス - 詳細については「[クラスター、Pod、サービスに対する IPv6 アドレスの説明](cni-ipv6.md)」を参照してください。
+ Kubernetes ネットワークポリシーを使用したトラフィックの制限 - 詳細については、「[Kubernetes ネットワークポリシーにより Pod トラフィックを制限する](cni-network-policy.md)」を参照してください。
## 考慮事項
Pod のセキュリティグループをデプロイする前に、次の制限事項と条件を考慮してください。
+ Pod のセキュリティグループは、Windows ノードまたは EKS Auto Mode では使用できません。
+ Pod のセキュリティグループは、バージョン 1.16.0 以降の Amazon VPC CNI プラグインを使用して、Amazon EC2 ノードを含む `IPv6` ファミリー用に設定されたクラスターで使用できます。バージョン 1.7.7 以降の Amazon VPC CNI プラグインを使用すると、Fargate ノードのみを含むクラスター設定の `IPv6` ファミリーで Pod のセキュリティグループを使用できます。詳細については、[クラスター、Pod、サービスに対する IPv6 アドレスの説明](cni-ipv6.md)を参照してください。
+ Pod のセキュリティグループはほとんどの [Nitro ベース](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html#ec2-nitro-instances)の Amazon EC2 インスタンスファミリーでサポートされていますが、ファミリーの全世代がサポートしているわけではありません。例えば、`m5`、`c5`、`r5`、`m6g`、、`c6g`、`r6g` インスタンスファミリーと世代ではサポートされています。`t` ファミリーのインスタンスタイプは一切サポートされていません。サポートされているインスタンスタイプの詳細なリストについては、GitHub で [limits.go](https://github.com/aws/amazon-vpc-resource-controller-k8s/blob/v1.5.0/pkg/aws/vpc/limits.go) ファイルを参照してください。ノードはそのファイルで一覧表示されているインスタンスタイプのうち、`IsTrunkingCompatible: true` を含むものである必要があります。
+ カスタムネットワークと Pod のセキュリティグループを組み合わせて使用している場合、`ENIConfig` で指定されたセキュリティグループではなく、Pod のセキュリティグループによって指定されたセキュリティグループが使用されます。
+ Amazon VPC CNI プラグインのバージョン `1.10.2` 以前を使用していて、Pod の仕様に `terminationGracePeriodSeconds` 設定を含める場合は、設定の値を「0」にすることはできません。
+ Amazon VPC CNI プラグインのバージョン `1.10` 以前、またはデフォルト設定が `POD_SECURITY_GROUP_ENFORCING_MODE`=`strict` のバージョン `1.11` を使用している場合、`externalTrafficPolicy` が `Local` に設定されたインスタンスターゲットを使用するタイプ `NodePort` および `LoadBalancer` の Kubernetes サービスは、セキュリティグループを割り当てる Pod ではサポートされていません。インスタンスターゲットでのロードバランサーの使用の詳細については「[Network Load Balancer を使用して TCP および UDP トラフィックをルーティングする](network-load-balancing.md)」を参照してください。
+ Amazon VPC CNI プラグインのバージョン `1.10` 以前、またはデフォルト設定が `POD_SECURITY_GROUP_ENFORCING_MODE`=`strict` のバージョン `1.11` を使用している場合、セキュリティグループが割り当てられた Pod からのアウトバウンドトラフィックに対してソース NAT が無効になり、その結果アウトバウンドセキュリティグループルールが適用されます。インターネットにアクセスするには、セキュリティグループが割り当てられた Pod を、NAT ゲートウェイまたはインスタンスで構成されたプライベートサブネットにデプロイされたノードで起動する必要があります。パブリックサブネットにデプロイされたセキュリティグループが割り当てられたポッドは、インターネットにアクセスできません。
`POD_SECURITY_GROUP_ENFORCING_MODE`=`standard` に設定されたプラグインのバージョン `1.11` 以降を使用している場合、VPC の外部を送信先とする Pod トラフィックはインスタンスのプライマリネットワークインターフェイスの IP アドレスに変換されます。このトラフィックには Pod のセキュリティグループ内のルールではなく、プライマリネットワークインターフェイスのセキュリティグループ内のルールが使用されます。
+ セキュリティグループが関連付けられている Pod で Calico ネットワークポリシーを使用するには、Amazon VPC CNI プラグインのバージョン `1.11.0` 以降を使用し、かつ `POD_SECURITY_GROUP_ENFORCING_MODE`=`standard` に設定することが必要になります。それ以外の場合は、セキュリティグループが関連付けられている Pod との間のトラフィックフローに Calico ネットワークポリシーは適用されず、Amazon EC2 セキュリティグループの適用のみに限定されます。Amazon VPC CNI バージョンを更新するには「[Amazon VPC CNI を使用して Pod に IP を割り当てる](managing-vpc-cni.md)」を参照してください
+ [NodeLocal DNSCache](https://kubernetes.io/docs/tasks/administer-cluster/nodelocaldns/) を使用するクラスターのセキュリティグループを使用する Amazon EC2 ノードで実行されている Pod は、Amazon VPC CNI プラグインのバージョンが `1.11.0` 以降で `POD_SECURITY_GROUP_ENFORCING_MODE`=`standard` に設定されている場合にのみサポートされます。Amazon VPC CNI プラグインのバージョンを更新するには「[Amazon VPC CNI を使用して Pod に IP を割り当てる](managing-vpc-cni.md)」を参照してください
+ Pod のセキュリティグループは、解約率が高い Pod の場合、Pod の起動レイテンシーがより高くなる可能性があります。これはリソースコントローラーのレート制限によるものです。
+ EC2 セキュリティグループのスコープは Pod レベル - 詳細については「[セキュリティグループ](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html)」を参照してください。
`POD_SECURITY_GROUP_ENFORCING_MODE=standard` および `AWS_VPC_K8S_CNI_EXTERNALSNAT=false` を設定した場合、VPC 外部のエンドポイント宛てのトラフィックは、Pod のセキュリティグループではなくノードのセキュリティグループを使用します。
# Amazon EKS Pod のセキュリティグループ用に Amazon VPC CNI Plugin for Kubernetes を設定する
Amazon EC2 インスタンスで Pod を使用する場合は、セキュリティグループ用に Amazon VPC CNI Plugin for Kubernetes を設定する必要があります。
Fargate Pod のみを使用し、クラスターに Amazon EC2 ノードがない場合は、「[Amazon EKS Pod のセキュリティグループポリシーを使用する](sg-pods-example-deployment.md)」を参照してください。
1. 次のコマンドを使用して、現在の Amazon VPC CNI Plugin for Kubernetes のバージョンをチェックします。
```
kubectl describe daemonset aws-node --namespace kube-system | grep amazon-k8s-cni: | cut -d : -f 3
```
出力例は次のとおりです。
```
v1.7.6
```
Amazon VPC CNI Plugin for Kubernetes のバージョンが `1.7.7` より前の場合は、プラグインをバージョン `1.7.7` 以降に更新してください。詳細については、[Amazon VPC CNI を使用して Pod に IP を割り当てる](managing-vpc-cni.md)を参照してください。
1. [AmazonEKSVPCResourceController](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AmazonEKSVPCResourceController) マネージド IAM ポリシーを Amazon EKS クラスターに関連付けられている[クラスターロール](cluster-iam-role.md#create-service-role)に追加します。ポリシーにより、ロールはネットワークインターフェイス、プライベート IP アドレス、およびネットワークインスタンスへのアタッチとデタッチを管理できます。
1. クラスター IAM ロールの名前を取得し、変数に格納します。*マイクラスター* の部分は自分のクラスター名に置き換えます。
```
cluster_role=$(aws eks describe-cluster --name my-cluster --query cluster.roleArn --output text | cut -d / -f 2)
```
1. ロールへのポリシーの付与
```
aws iam attach-role-policy --policy-arn arn:aws:iam::aws:policy/AmazonEKSVPCResourceController --role-name $cluster_role
```
1. Amazon VPC CNI アドオンを有効にして Pod のネットワークインターフェイスを管理するには、`aws-node` DaemonSet で `ENABLE_POD_ENI` 変数を `true` に設定します。この設定が `true` になると、クラスター内の各ノードについて、アドオンにより `cninode` カスタムリソースが作成されます。VPC リソースコントローラーは、1 つの特別なネットワークインターフェイスを作成してアタッチします。これは、*トランクネットワークインターフェイス*と呼ばれ、説明は `aws-k8s-trunk-eni` です。
```
kubectl set env daemonset aws-node -n kube-system ENABLE_POD_ENI=true
```
**注記**
トランクネットワークインターフェイスは、インスタンスタイプでサポートされているネットワークインターフェイスの最大数に含まれます。各インスタンスタイプによりサポートされるネットワークインターフェイスの最大数のリストについては、「Amazon EC2 ユーザーガイド」の「[各インスタンスタイプのネットワークインターフェイスあたりの IP アドレス数](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html#AvailableIpPerENI)」を参照してください。ノードにすでに最大数の標準ネットワークインターフェイスがアタッチされている場合、VPC リソースコントローラーはスペースを予約します。コントローラーが標準ネットワークインターフェイスをデタッチして削除し、トランクネットワークインターフェイスを作成し、インスタンスにアタッチできるように、実行中の Pod をスケールダウンする必要があります。
1. `CNINode` カスタムリソースがどのノードにあるか、次のコマンドで確認できます。[`No resources found`] が返された場合、数秒待ってから、もう一度試してください。前のステップで、Amazon VPC CNI Plugin for Kubernetes Pod を再起動する必要があります。再起動には数秒かかります。
```
kubectl get cninode -A
NAME FEATURES
ip-192-168-64-141.us-west-2.compute.internal [{"name":"SecurityGroupsForPods"}]
ip-192-168-7-203.us-west-2.compute.internal [{"name":"SecurityGroupsForPods"}]
```
`1.15` より古いバージョンの VPC CNI バージョンを使用している場合は、`CNINode` カスタムリソースの代わりにノードラベルが使用されていました。`true` に設定されているノードラベル `aws-k8s-trunk-eni` がどのノードにあるか、次のコマンドで確認できます。[`No resources found`] が返された場合、数秒待ってから、もう一度試してください。前のステップで、Amazon VPC CNI Plugin for Kubernetes Pod を再起動する必要があります。再起動には数秒かかります。
```
kubectl get nodes -o wide -l vpc.amazonaws.com/has-trunk-attached=true
```
トランクネットワークインターフェイスが作成されると、Pod にはトランクネットワークインターフェイスまたは標準ネットワークインターフェイスのセカンダリ IP アドレスが割り当てられます。ノードが削除されると、トランクインターフェイスは自動的に削除されます。
後のステップで Pod のセキュリティグループをデプロイすると、VPC リソースコントローラーは*ブランチネットワークインターフェイス*と呼ばれる特別なインターフェイスを `aws-k8s-branch-eni` の説明と共に作成し、セキュリティグループを関連付けます。ノードにアタッチされた標準ネットワークインターフェイスとトランクネットワークインターフェイスに加えて、ブランチネットワークインターフェイスが作成されます。
Liveness プローブまたは Readiness プローブを使用している場合は、*TCP Early Demux* も無効にする必要があります。これにより、`kubelet` は TCP を使用してブランチネットワークインターフェイス上の Pod に接続できます。TCP Early Demux を無効にするには、次のコマンドを実行します。
```
kubectl patch daemonset aws-node -n kube-system \
-p '{"spec": {"template": {"spec": {"initContainers": [{"env":[{"name":"DISABLE_TCP_EARLY_DEMUX","value":"true"}],"name":"aws-vpc-cni-init"}]}}}}'
```
**注記**
Amazon VPC CNI Plugin for Kubernetes アドオンのバージョン `1.11.0` 以降を使用し、かつ `POD_SECURITY_GROUP_ENFORCING_MODE`=`standard` に設定している場合、次のステップで説明されているように、前のコマンドを実行する必要はありません。
1. クラスターで `NodeLocal DNSCache` が使用されている場合、独自のセキュリティグループを持つ Pod で Calico ネットワークポリシーを使用する場合、またはセキュリティグループを割り当てる Pod に対して `externalTrafficPolicy` を `Local` に設定したインスタンスターゲットを使用するタイプ `NodePort` および `LoadBalancer` の Kubernetes サービスがある場合、バージョン `1.11.0` 以降の Amazon VPC CNI Plugin for Kubernetes アドオンを使用して次の設定を有効にする必要があります。
```
kubectl set env daemonset aws-node -n kube-system POD_SECURITY_GROUP_ENFORCING_MODE=standard
```
重要: **Pod のセキュリティグループルールは、`kubelet` や `nodeLocalDNS` など、同じノードにある Pod とサービスの間のトラフィックまたは Pod 間のトラフィックには適用されません。同じノードで異なるセキュリティグループを使用するポッドは、異なるサブネットに設定されているため通信できません。また、これらのサブネット間のルーティングは無効になっています。**Pod から VPC の外部のアドレスへのアウトバウンドトラフィックは、インスタンスのプライマリネットワークインターフェイスの IP アドレスに変換されたネットワークアドレスです (`AWS_VPC_K8S_CNI_EXTERNALSNAT=true` に設定していない場合)。このトラフィックには Pod のセキュリティグループ内のルールではなく、プライマリネットワークインターフェイスのセキュリティグループ内のルールが使用されます。\$1\$1 この設定を既存のPod に適用するには、Pod または Pod が実行されているノードを再起動する必要があります。
1. Pod のセキュリティグループポリシーの使用方法については、「[Amazon EKS Pod のセキュリティグループポリシーを使用する](sg-pods-example-deployment.md)」を参照してください。
# Amazon EKS Pod のセキュリティグループポリシーを使用する
Pod のセキュリティグループを使用するには、既存のセキュリティグループが必要です。次のステップは、Pod に対してセキュリティグループポリシーを使用する方法を示しています。次のステップではターミナル間で保持されない変数が使用されるため、特に明記されていない限り、同じターミナルからすべてのステップを完了してください。
Amazon EC2 インスタンスを持つ Pod がある場合は、この手順を使用する前にプラグインを設定する必要があります。詳細については、「[Amazon EKS Pod のセキュリティグループ用に Amazon VPC CNI Plugin for Kubernetes を設定する](security-groups-pods-deployment.md)」を参照してください。
1. リソースをデプロイする Kubernetes 名前空間を作成します。*my-namespace* は使用する名前空間の名前に置き換えることができます。
```
kubectl create namespace my-namespace
```
1. アマゾン EKS `SecurityGroupPolicy` をクラスターにデプロイします。
1. 次のコンテンツをデバイスにコピーします。サービスアカウントラベルに基づいて Pod を選択したい場合は、*podSelector* を `serviceAccountSelector` で置き換えることができます。セレクターをどちらか 1 つ指定する必要があります。`podSelector` が空 (例: `podSelector: {}`) であると、名前空間内のすべての Pod が選択されます。*my-role* は自分の役割名に変更できます。`serviceAccountSelector` が空であると、名前空間内のすべてのサービスアカウントが選択されます。*my-security-group-policy* を自分の `SecurityGroupPolicy` の名前に置き換え、*my-namespace* は `SecurityGroupPolicy` を作成する名前空間に置き換えることができます。
*my\$1pod\$1security\$1group\$1id* を既存のセキュリティグループの ID に置き換える必要があります。既存のセキュリティグループがない場合は作成する必要があります。詳細については「[アマゾン EC2 ユーザーガイド](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/)」の「[アマゾン EC2 security groups for リナックス instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-security-groups.html)」(リナックス インスタンス用の アマゾン EC2 セキュリティグループ) を参照してください。1～5 個のセキュリティグループ ID を指定できます。複数の ID を指定した場合、すべてのセキュリティグループ内のすべてのルールの組み合わせが、選択した Pod に対して有効になります。
```
cat >my-security-group-policy.yaml <sample-application.yaml <
my-deployment-5df6f7687b-j9fl4 1/1 Running 0 7m51s 192.168.70.145 ip-192-168-92-33.region-code.compute.internal
my-deployment-5df6f7687b-rjxcz 1/1 Running 0 7m51s 192.168.73.207 ip-192-168-92-33.region-code.compute.internal
my-deployment-5df6f7687b-zmb42 1/1 Running 0 7m51s 192.168.63.27 ip-192-168-33-28.region-code.compute.internal
```
**注記**
Pod がスタックしている場合は次のヒントをお試しください。
`Waiting` 状態でスタックした Pod があれば、`kubectl describe pod my-deployment-xxxxxxxxxx-xxxxx -n my-namespace ` を実行してください。`Insufficient permissions: Unable to create Elastic Network Interface.` が表示された場合、前のステップで IAM クラスター役割に IAM ポリシーを追加したことを確認します。
Pod が `Pending` 状態でスタックした場合、ノードのインスタンスタイプが [limits.go](https://github.com/aws/amazon-vpc-resource-controller-k8s/blob/master/pkg/aws/vpc/limits.go) のリストに含まれていることを確認します。そのうえで、インスタンスタイプでサポートされるブランチネットワークインターフェイスの最大製品数とノードグループ内のノード数を乗算した数にまだ達していないことを確認します。例えば、`m5.large` インスタンスでは9 つのブランチネットワークインターフェイスがサポートされています。ノードグループに 5 つのノードがある場合、ノードグループに対して最大 45 のブランチネットワークインターフェイスを作成できます。46 番目の Pod をデプロイしようとすると、セキュリティグループに関連付けられた別の Pod が削除されるまで `Pending` 状態のままになります。
`kubectl describe pod my-deployment-xxxxxxxxxx-xxxxx -n my-namespace ` を実行したときに次のようなメッセージが表示されている場合は、無視しても問題ありません。このメッセージは、Amazon VPC CNI Plugin for Kubernetes がホストネットワークの設定を試み、ネットワークインターフェイスの作成中に失敗したときに表示される場合があります。プラグインはネットワークインターフェイスが作成されるまで、このイベントをログに記録します。
```
Failed to create Pod sandbox: rpc error: code = Unknown desc = failed to set up sandbox container "e24268322e55c8185721f52df6493684f6c2c3bf4fd59c9c121fd4cdc894579f" network for Pod "my-deployment-5df6f7687b-4fbjm": networkPlugin
cni failed to set up Pod "my-deployment-5df6f7687b-4fbjm-c89wx_my-namespace" network: add cmd: failed to assign an IP address to container
```
インスタンスタイプで実行できる Pod の最大数を超えることはできません。各インスタンスタイプで実行できるポッドの最大数の一覧については、GitHub の「[eni-max-pods.txt](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/misc/eni-max-pods.txt)」を参照してください。セキュリティグループが関連付けられているポッドを削除するか、ポッドが実行されているノードを削除すると、VPC リソースコントローラーによってブランチネットワークインターフェイスが削除されます。セキュリティグループ用に Pod を含むクラスターを Pod で削除する場合、コントローラーではブランチネットワークインターフェイスを削除しないため、自分で削除する必要があります。ネットワークインターフェイスの削除方法の詳細については「Amazon EC2 ユーザーガイド」の「[ネットワークインターフェイスの削除](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html#delete_eni)」を参照してください。
1. 別のターミナルで、Pod のいずれかをシェルで操作します。このトピックの以降の説明ではこのターミナルを `TerminalB` と呼びます。*5df6f7687b-4fbjm* を、前の手順の出力で返された Pod のいずれかの ID に置き換えます。
```
kubectl exec -it -n my-namespace my-deployment-5df6f7687b-4fbjm -- /bin/bash
```
1. `TerminalB` のシェルから、サンプルアプリケーションが動作することを確認します。
```
curl my-app
```
出力例は次のとおりです。
```
Welcome to nginx!
[...]
```
アプリケーションを実行しているすべての Pod が作成したセキュリティグループに関連付けられているため、出力を受信できます。そのグループにはセキュリティグループが関連付けられているすべての Pod 間のすべてのトラフィックを許可するルールが含まれています。DNS トラフィックはそのセキュリティグループからノードに関連付けられているクラスターセキュリティグループへのアウトバウンドで許可されます。ノードは、Pod が名前のルックアップを実行した CoreDNS Pod を実行しています。
1. `TerminalA` で、クラスターセキュリティグループへの DNS 通信を許可するセキュリティグループルールを、セキュリティグループから削除します。前のステップで DNS ルールをクラスターセキュリティグループに追加しなかった場合は*\$1my\$1cluster\$1security\$1group\$1id* を、ルールを作成したセキュリティグループの ID で置き換えます。
```
aws ec2 revoke-security-group-ingress --group-id $my_cluster_security_group_id --security-group-rule-ids $my_tcp_rule_id
aws ec2 revoke-security-group-ingress --group-id $my_cluster_security_group_id --security-group-rule-ids $my_udp_rule_id
```
1. `TerminalB` で、アプリケーションにもう一度アクセスしてみます。
```
curl my-app
```
出力例は次のとおりです。
```
curl: (6) Could not resolve host: my-app
```
クラスターセキュリティグループが関連付けられている CoreDNS Pod に Pod がアクセスできなくなったため、この試行は失敗します。クラスターセキュリティグループから、Pod に関連付けられたセキュリティグループからの DNS 通信を許可するセキュリティグループルールがなくなりました。
前のステップで、いずれかの Pod に返された IP アドレスを使用してアプリケーションにアクセスしようとすると、セキュリティグループが関連付けられており、名前のルックアップが不要な Pod 間ですべてのポートが許可されているため、引き続き応答を受信します。
1. 試行し終えたら、作成したサンプルのセキュリティグループポリシー、アプリケーション、およびセキュリティグループを削除できます。`TerminalA` から、次のコマンドを実行してください。
```
kubectl delete namespace my-namespace
aws ec2 revoke-security-group-ingress --group-id $my_pod_security_group_id --security-group-rule-ids $my_inbound_self_rule_id
wait
sleep 45s
aws ec2 delete-security-group --group-id $my_pod_security_group_id
```
# 複数のネットワークインターフェイスをポッドにアタッチする
デフォルトでは、Amazon VPC CNI プラグインは各ポッドに 1 つの IP アドレスを割り当てます。この IP アドレスは、ポッドのすべての送受信トラフィックを処理する *Elastic Network Interface* にアタッチされます。帯域幅とパケット/秒レートのパフォーマンスを向上させるには、VPC CNI の*マルチ NIC 機能*を使用してマルチホームポッドを設定できます。マルチホームポッドは、複数のネットワークインターフェイス (および複数の IP アドレス) を使用する単一の Kubernetes ポッドです。マルチホームポッドを実行すると、同時接続を使用してアプリケーショントラフィックを複数のネットワークインターフェイスに分散できます。これは、人工知能 (AI)、機械学習 (ML)、ハイパフォーマンスコンピューティング (HPC) のユースケースに特に役立ちます。
次の図は、複数のネットワークインターフェイスカード (NIC) が使用されているワーカーノードで実行されているマルチホームポッドを示しています。
![\[2 つのネットワークインターフェイスが接続されたマルチホームポッドで、一方のネットワークインターフェイスには ENA、もう一方のネットワークインターフェイスには ENA と EFA を備えているもの\]](http://docs.aws.amazon.com/ja_jp/eks/latest/userguide/images/multi-homed-pod.png)
## 背景
Amazon EC2 では、*Elastic Network Interface* は仮想ネットワークカードを表す VPC 内の論理ネットワーキングコンポーネントです。多くの EC2 インスタンスタイプでは、ネットワークインターフェイスはハードウェア内で単一のネットワークインターフェイスカード (NIC) を共有します。この単一の NIC には、最大帯域幅とパケット毎秒レートがあります。
マルチ NIC 機能が有効になっている場合、VPC CNI は、デフォルトでは行われる IP アドレスの一括割り当てを行いません。代わりに、VPC CNI は、新しいポッドの起動時に、各ネットワークカードのネットワークインターフェイスに 1 つの IP アドレスをオンデマンドで割り当てます。この動作により、マルチホームポッドを使用することで増加する IP アドレスの枯渇率が低下します。VPC CNI はオンデマンドで IP アドレスを割り当てるため、マルチ NIC 機能が有効になっているインスタンスではポッドが起動するまでに時間がかかる場合があります。
## 考慮事項
+ Kubernetes クラスターで VPC CNI バージョン `1.20.0` 以降が実行されていることを確認します。マルチ NIC 機能は、VPC CNI のバージョン `1.20.0` 以降でのみ使用できます。
+ VPC CNI プラグインで `ENABLE_MULTI_NIC` 環境変数を有効にします。次のコマンドを実行して変数を設定し、DaemonSet のデプロイを開始できます。
+ `kubectl set env daemonset aws-node -n kube-system ENABLE_MULTI_NIC=true`
+ 複数のネットワークインターフェイスカード (NIC) を持つワーカーノードを作成してください。複数のネットワークインターフェイスカードを持つ EC2 インスタンスのリストについては、「**Amazon EC2 ユーザーガイド**」の「[ネットワークカード](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html#network-cards)」を参照してください。
+ マルチ NIC 機能が有効になっている場合、VPC CNI は、デフォルトでは行われる IP アドレスの一括割り当てを行いません。VPC CNI はオンデマンドで IP アドレスを割り当てるため、マルチ NIC 機能が有効になっているインスタンスではポッドが起動するまでに時間がかかる場合があります。詳細については、前の「[背景](#pod-multi-nic-background)」セクションを参照してください。
+ マルチ NIC 機能を有効にしても、デフォルトではポッドは複数のネットワークインターフェイスを持ちません。マルチ NIC を使用するように各ワークロードを設定する必要があります。複数のネットワークインターフェイスを持つ必要があるワークロードに `k8s.amazonaws.com/nicConfig: multi-nic-attachment` 注釈を追加します。
### `IPv6` に関する考慮事項
+ **カスタム IAM ポリシー** - `IPv6` クラスターの場合は、VPC CNI に次のカスタム IAM ポリシーを作成して使用します。このポリシーはマルチ NIC に固有です。`IPv6` クラスターでの VPC CNI の使用に関する一般的な情報については、「[クラスター、Pod、サービスに対する IPv6 アドレスの説明](cni-ipv6.md)」を参照してください。
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AmazonEKSCNIPolicyIPv6MultiNIC",
"Effect": "Allow",
"Action": [
"ec2:CreateNetworkInterface",
"ec2:DescribeInstances",
"ec2:AssignIpv6Addresses",
"ec2:DetachNetworkInterface",
"ec2:DescribeNetworkInterfaces",
"ec2:DescribeTags",
"ec2:ModifyNetworkInterfaceAttribute",
"ec2:DeleteNetworkInterface",
"ec2:DescribeInstanceTypes",
"ec2:UnassignIpv6Addresses",
"ec2:AttachNetworkInterface",
"ec2:DescribeSubnets"
],
"Resource": "*"
},
{
"Sid": "AmazonEKSCNIPolicyENITagIPv6MultiNIC",
"Effect": "Allow",
"Action": "ec2:CreateTags",
"Resource": "arn:aws:ec2:*:*:network-interface/*"
}
]
}
```
+ `IPv6` **移行メカニズムは使用できません** - マルチ NIC 機能を使用する場合、VPC CNI は`IPv6` クラスター上のポッドに `IPv4` アドレスを割り当てません。それ以外の場合、VPC CNI はホストローカル `IPv4` アドレスを各ポッドに割り当て、ポッドが別の Amazon VPC またはインターネットの外部 `IPv4` リソースと通信できるようにします。
## 使用方法
VPC CNI でマルチ NIC 機能を有効にし、`aws-node` ポッドを再起動すると、各ワークロードをマルチホームに設定できます。次の YAML 設定の例では、必要な注釈が付けられています。
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: orders-deployment
namespace: ecommerce
labels:
app: orders
spec:
replicas: 3
selector:
matchLabels:
app: orders
template:
metadata:
annotations:
k8s.amazonaws.com/nicConfig: multi-nic-attachment
labels:
app: orders
spec:
...
```
## よくある質問
### **1. ネットワークインターフェイスカード (NIC) とは**
ネットワークインターフェイスカード (NIC) は、単にネットワークカードとも呼ばれ、基盤となるクラウドコンピューティングハードウェアのネットワーク接続を可能にする物理デバイスです。最新の EC2 サーバーでは、これは Nitro ネットワークカードを指します。Elastic Network Interface (ENI) は、この基盤となるネットワークカードの仮想表現です。
一部の EC2 インスタンスタイプには、帯域幅とパケットレートのパフォーマンスを向上させるために複数の NIC があります。このようなインスタンスでは、追加のネットワークカードにセカンダリ ENI を割り当てることができます。例えば、ENI \$11 はネットワークカードインデックス 0 にアタッチされた NIC のインターフェイスとして機能しますが、ENI \$12 は別のネットワークカードインデックスにアタッチされた NIC のインターフェイスとして機能します。
### **2. マルチホームポッドとは**
マルチホームポッドは、複数のネットワークインターフェイス (および複数の IP アドレスを暗示) を持つ単一の Kubernetes ポッドです。各ポッドネットワークインターフェイスは [Elastic Network Interface (ENI)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html) に関連付けられており、これらの ENI は基盤となるワーカーノード上の個別の NIC の論理表現です。複数のネットワークインターフェイスを使用すると、マルチホームポッドのデータ転送容量が増え、データ転送速度も上がります。
**重要**
VPC CNI は、複数の NIC を持つインスタンスタイプでのみマルチホームポッドを設定できます。
### **3. この機能を使用する理由は何ですか?**
Kubernetes ベースのワークロードでネットワークパフォーマンスをスケールする必要がある場合は、マルチ NIC 機能を使用して、ENA デバイスがアタッチされているすべての基盤となる NIC とインターフェイスで通信するマルチホームポッドを実行できます。追加のネットワークカードを使用すると、複数の同時接続にアプリケーショントラフィックを分散することで、アプリケーションの帯域幅容量とパケットレートのパフォーマンスが向上します。これは、人工知能 (AI)、機械学習 (ML)、ハイパフォーマンスコンピューティング (HPC) のユースケースに特に役立ちます。
### **4. この機能の使用方法を教えてください。**
1. まず、Kubernetes クラスターが VPC CNI バージョン 1.20 以降を使用していることを確認する必要があります。VPC CNI を EKS アドオンとして更新する手順については、「[Amazon VPC CNI を更新する (Amazon EKS アドオン)](vpc-add-on-update.md)」を参照してください。
1. 次に、`ENABLE_MULTI_NIC` 環境変数を使用して、VPC CNI でマルチ NIC サポートを有効にする必要があります。
1. 次に、複数のネットワークカードを持つノードを作成して結合する必要があります。複数のネットワークカードを持つ EC2 インスタンスタイプのリストについては、「*Amazon EC2 ユーザーガイド*」の「[ネットワークカード](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html#network-cards)」を参照してください。
1. 最後に、複数のネットワークインターフェイス (マルチホームポッド) を使用するか、単一のネットワークインターフェイスを使用するかのいずれかに各ワークロードを設定します。
### **5. サポートされているワーカーノードで複数の NIC を使用するようにワークロードを設定するにはどうすればよいですか?**
マルチホームポッドを使用するには、注釈 `k8s.amazonaws.com/nicConfig: multi-nic-attachment` を追加する必要があります。これにより、基盤となるインスタンス内のすべての NIC からポッドに ENI がアタッチされます (ポッドと NIC 間の 1 対多マッピング)。
この注釈がない場合、VPC CNI はポッドに必要なネットワークインターフェイスが 1 つだけであると見なし、使用可能な任意の NIC の ENI から IP を 1 つ割り当てます。
### **6. この機能ではどのネットワークインターフェイスアダプターがサポートされていますか?**
IP トラフィックの基盤となるネットワークカードに少なくとも 1 つの ENA がアタッチされている場合は、任意のネットワークインターフェイスアダプターを使用できます。ENA に関する詳細については、「*Amazon EC2 ユーザーガイド*」の「[Elastic Network Adapter (ENA)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/enhanced-networking-ena.html)」を参照してください。
サポートされているネットワークデバイス設定:
+ **ENA** インターフェイスはVPC の IP ネットワークをサポートするために必要なすべての従来の IP ネットワークとルーティング機能を提供します。詳細については、「[EC2 インスタンスで ENA による拡張ネットワーキングを有効にする](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/enhanced-networking-ena.html)」を参照してください。
+ **EFA** **(EFA** と **ENA の組み合わせ)** インターフェイスは、IP ネットワーク用の ENA デバイスと、低レイテンシーで高スループット通信用の EFA デバイスの両方を提供します。
**重要**
ネットワークカードに **EFA 専用**アダプターのみがアタッチされている場合、VPC CNI はマルチホームポッドのネットワーク接続をプロビジョニングするときにそのネットワークカードをスキップします。ただし、**EFA 専用**アダプターをネットワークカード上の **ENA** アダプターと組み合わせると、VPC CNI はこのデバイス上の ENI も管理します。EKS クラスターで EFA 専用インターフェイスを使用するには、「[Elastic Fabric Adapter を使用して Amazon EKS で機械学習トレーニングを実行する](node-efa.md)」を参照してください。
### **7. クラスター内のノードが ENA をサポートしているかどうかを確認できますか?**
はい。AWS CLI または EC2 API を使用して、クラスター内の EC2 インスタンスに関するネットワーク情報を取得できます。これにより、インスタンスに ENA サポートがあるかどうかの詳細が表示されます。次の例で、`` をノードの EC2 インスタンス ID に置き換えます。
AWS CLI の例:
```
aws ec2 describe-instances --instance-ids --query "Reservations[].Instances[].EnaSupport"
```
出力例:
```
[ true ]
```
### **8. ポッドに関連付けられているさまざまな IP アドレスを確認できますか?**
いいえ、簡単にはできません。ただし、ノードから `nsenter` を使用して、`ip route show` のような一般的なネットワークツールを実行すれば、追加の IP アドレスとインターフェイスを確認できます。
### **9. ポッドのネットワークインターフェイスの数を制御できますか?**
いいえ。ワークロードがサポートされているインスタンスで複数の NIC を使用するように設定されている場合、単一のポッドにはインスタンス上のすべてのネットワークカードから IP アドレスが自動的に割り当てられます。または、シングルホームポッドには、インスタンス上の 1 つの NIC に 1 つのネットワークインターフェイスがアタッチされます。
**重要**
**EFA 専用**デバイス*のみ*がアタッチされているネットワークカードは、VPC CNI によってスキップされます。
### **10. 特定の NIC を使用するようにポッドを設定できますか?**
いいえ、それはサポートされません。ポッドに関連する注釈がある場合、VPC CNI はワーカーノード上の ENA アダプターですべての NIC を使用するように自動的に設定します。
### **11. この機能は、他の VPC CNI ネットワーク機能と連携しますか?**
はい。VPC CNI のマルチ NIC 機能は、*カスタムネットワーク*と*拡張サブネット検出*の両方と連携します。ただし、マルチホームポッドではカスタムサブネットやセキュリティグループを使用しません。代わりに、VPC CNI はノードと同じサブネットとセキュリティグループ設定を使用して、マルチホームポッドに IP アドレスとネットワークインターフェイスを割り当てます。カスタムネットワークの詳細については、「[カスタムネットワーキングを使用して代替サブネットに Pod をデプロイする](cni-custom-network.md)」を参照してください。
VPC CNI のマルチ NIC 機能は*ポッドのセキュリティグループ*と組み合わせて動作することはできません。
### **12. この機能でネットワークポリシーを使用できますか?**
はい。マルチ NIC で Kubernetes ネットワークポリシーを使用できます。Kubernetes ネットワークポリシーにより、Pod 間で送受信されるネットワークトラフィックが制限されます。VPC CNI でネットワークポリシーを適用する詳細については、「[Kubernetes ネットワークポリシーにより Pod トラフィックを制限する](cni-network-policy.md)」を参照してください。
### **13. マルチ NIC サポートは EKS オートモードで有効になっていますか?**
マルチ NIC は EKS オートモードクラスターではサポートされていません。
# Amazon EKS クラスターの代替 CNI プラグイン
[Amazon VPC CNI plugin for Kubernetes](https://github.com/aws/amazon-vpc-cni-plugins) は、Amazon EC2 ノードにおいて Amazon EKS によりサポートされている唯一の CNI プラグインです。Amazon EKS は、Amazon EKS Hybrid Nodes 用の Cilium および Calico のコア機能をサポートしています。Amazon EKS では、アップストリーム Kubernetes が実行されており、クラスター内の Amazon EC2 ノードに互換性のある CNI プラグインをインストールできます。クラスターに Fargate ノードがある場合、Amazon VPC CNI plugin for Kubernetes は既に Fargate ノードに存在します。これは Fargate ノードで使用できる唯一の CNI プラグインです。Fargate ノードに代替 CNI プラグインをインストールしようとすると失敗します。
Amazon EC2 ノードで代替 CNI プラグインを使用する予定であれば、当該プラグインの商用サポートを受けるか、社内のエキスパートによるトラブルシューティングを行い、解決策を CNI プラグインプロジェクトに提供することをお勧めします。
Amazon EKS は、互換性のある代替 CNI プラグインのサポートを提供するパートナーネットワークと連携しています。バージョンと認定、および実行されたテストの詳細については、次のパートナーのドキュメントを参照してください。
| パートナー | 製品 | ドキュメント |
| --- | --- | --- |
| Tigera | [Calico](https://www.tigera.io/partners/aws/) | [インストール手順](https://docs.projectcalico.org/getting-started/kubernetes/managed-public-cloud/eks) |
| Isovalent | [Cilium](https://cilium.io) | [インストール手順](https://docs.cilium.io/en/stable/gettingstarted/k8s-install-default/) |
| ジュニパー | [クラウドネイティブ Contrail Networking (CN2)](https://www.juniper.net/us/en/products/sdn-and-orchestration/contrail/cloud-native-contrail-networking.html) | [インストール手順](https://www.juniper.net/documentation/us/en/software/cn-cloud-native23.2/cn-cloud-native-eks-install-and-lcm/index.html) |
| VMware | [Antrea](https://antrea.io/) | [インストール手順](https://antrea.io/docs/main/docs/eks-installation) |
Amazon EKS ではすべてのユースケースをカバーする幅広いオプションの提供を目指しています。
## 互換性のある代替ネットワークポリシープラグイン
[Calico](https://www.tigera.io/project-calico) は、コンテナネットワークとセキュリティのために広く採用されているソリューションです。Calico on EKS を使用すると、EKS クラスターに完全準拠のネットワークポリシーが適用されます。さらに、基盤となる VPC の IP アドレスを節約する Calico のネットワークを使用することもできます。[Calico Cloud](https://www.tigera.io/tigera-products/calico-cloud/) は Calico Open Source の機能を強化すると共に、高度なセキュリティとオブザーバビリティ機能を提供します。
関連付けられたセキュリティグループを持つポッドとの間のトラフィックフローに、Calico ネットワークポリシーは適用されず、Amazon VPC セキュリティグループの適用のみに限定されます。
Calico ネットワークポリシーの適用を使用する場合は、Kubernetes の既知の問題を回避するために、環境変数 `ANNOTATE_POD_IP` を `true` に設定することをお勧めします。この機能を使用するには、ポッドの `patch` のアクセス許可を `aws-node` ClusterRole に追加する必要があります。`aws-node` DaemonSet にパッチのアクセス許可を追加すると、プラグインのセキュリティ範囲が広がることに注意してください。詳細については、GitHub の VPC CNI リポジトリの [ANNOTATE\$1POD\$1IP](https://github.com/aws/amazon-vpc-cni-k8s/?tab=readme-ov-file#annotate_pod_ip-v193) を参照してください。
## Amazon EKS Auto Mode の考慮事項
Amazon EKS Auto Mode は、代替 CNI プラグインおよびネットワークポリシープラグインをサポートしていません。詳細については、「[EKS Auto Mode を使用してクラスターインフラストラクチャを自動化する](automode.md)」を参照してください。
# Multus を使用して複数のネットワークインターフェイスを Pod にアタッチする
Multus CNI は、Amazon EKS 用のコンテナネットワークインターフェイス (CNI) プラグインです。これにより、Pod に複数のネットワークインターフェイスをアタッチできるようになります。詳細については、GitHub の [Multus-CNI](https://github.com/k8snetworkplumbingwg/multus-cni) を参照してください。
Amazon EKS では、Amazon VPC CNI プラグインによって割り当てられたネットワークインターフェイスが Pod ごとに 1 つあります。Multus を使用すると、複数のインターフェイスを備えたマルチホーム Pod を作成できます。これは、Multusが「meta-plugin」(他の複数の CNI プラグインを呼び出すことができる CNI プラグイン) として機能することによって達成されます。AWS では、Amazon VPC CNI プラグインをデフォルトのデリゲートプラグインとして設定することで、Multus をサポートしています。
+ Amazon EKS では、シングルルートの I/O 仮想化 (SR-IOV)、およびデータプレーン開発キット (DPDK) のCNI プラグインを構築および公開することはありません。ただし、Multus で管理されたホストデバイスおよび `ipvlan` プラグインを介して、Amazon EC2 Elastic Network Adapters (ENA) と直接接続することで、パケットアクセラレーションを実現することができます。
+ Amazon EKS では Multus をサポートすることで、追加の CNI プラグインの簡単な連鎖を可能にする汎用プロセスを提供します。AWS は、Multus とその連鎖プロセスをサポートしています。ただし、連鎖可能な互換性のある CNI プラグインすべてについてのサポートや、連鎖設定とは無関係な CNI プラグインで発生する可能性のある問題のサポートは行っていません。
+ Amazon EKS は Multus プラグインのサポートとライフサイクル管理を提供していますが、追加のネットワークインターフェイスに関連付けられた IP アドレスや他の管理については責任を負いません。Amazon VPC CNI プラグインを使用する、デフォルトのネットワークインターフェイスの IP アドレスと管理に変更はありません。
+ デフォルトのデリゲートプラグインとして正式にサポートされるのは、Amazon VPC CNI プラグインのみです。Amazon VPC CNI プラグインをプライマリネットワークに使用しないことを選択した場合は、公開されている Multus インストールマニフェストを変更して、デフォルトのデリゲートプラグインを代替の CNI に再設定する必要があります。
+ Multus は、Amazon VPC CNI をプライマリ CNI として使用する場合にのみサポートされます。セカンダリなど、高次のインターフェイスに使用する場合、Amazon VPC CNI はサポートされません。
+ Pod に追加で割り当てたネットワークインターフェイスが Amazon VPC CNI プラグインの管理対象にならないようにするには、そのネットワークインターフェイスに次のタグを追加します。
**key**
: `node.k8s.amazonaws.com/no_manage`
**value**
: `true`
+ Multus にはネットワークポリシーとの互換性がありますが、Pod に追加でアタッチされるネットワークインターフェイスの一部であるポートと IP アドレスを含めるように、ポリシーを強化する必要があります。
実装のチュートリアルについては、GitHub の[Multus セットアップガイド](https://github.com/aws-samples/eks-install-guide-for-multus/blob/main/README.md)を参照してください。
# AWS Load Balancer Controller を使用してインターネットトラフィックをルーティングする
**ヒント**
今後開催予定の Amazon EKS ワークショップに[登録](https://aws-experience.com/emea/smb/events/series/get-hands-on-with-amazon-eks?trk=4a9b4147-2490-4c63-bc9f-f8a84b122c8c&sc_channel=el)してください。
AWS Load Balancer Controller により、Kubernetes クラスター向けの AWS Elastic Load Balancer を管理できます。コントローラーを使用すると、クラスターアプリケーションをインターネットに公開できます。コントローラーは、クラスターサービスまたは Ingress リソースを指す AWS ロードバランサーをプロビジョニングします。つまり、コントローラーはクラスター内の複数のポッドを指す単一の IP アドレスまたは DNS 名を作成します。
![\[アーキテクチャ図。インターネットユーザーから Amazon Load Balancer へのトラフィックの図。Amazon Load Balancer は、クラスター内のポッドにトラフィックを分散します。\]](http://docs.aws.amazon.com/ja_jp/eks/latest/userguide/images/lbc-overview.png)
コントローラーは、Kubernetes Ingress または Service のリソースを監視します。これに応じて、適切な AWS Elastic Load Balancing リソースが作成されます。Kubernetes リソースに注釈を適用することで、ロードバランサーの特定の動作を設定できます。例えば、注釈を使用してロードバランサーに AWS セキュリティグループをアタッチできます。
コントローラは、以下のリソースをプロビジョニングします。
**Kubernetes `Ingress` **
Kubernetes `Ingress` を作成すると、LBC は [AWS Application Load Balancer (ALB)](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html) を作成します。[Ingress リソースに適用できる注釈を確認してください。](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/guide/ingress/annotations/)
**`LoadBalancer` タイプの Kubernetes サービス**
`LoadBalancer` タイプの Kubernetes サービスを作成すると、LBC は [AWS Network Load Balancer (NLB)](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html) を作成します。[サービスリソースに適用できる注釈を確認してください。](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/guide/service/annotations/)
以前は、*インスタンス*ターゲットには Kubernetes Network Load Balancer が使用されていましたが、*IP* ターゲットには LBC が使用されていました。AWS Load Balancer Controller バージョン `2.3.0` 以降では、いずれかのターゲットタイプを使用して NLBs を作成できます。NLB ターゲットタイプの詳細については、Network Load Balancer のユーザーガイドの 「[ターゲットタイプ](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-target-groups.html#target-type)」を参照してください。
コントローラーは GitHub で管理される[オープンソースプロジェクト](https://github.com/kubernetes-sigs/aws-load-balancer-controller)です。
コントローラーをデプロイする前に、「[Application Load Balancers を使用したアプリケーションおよび HTTP トラフィックのルーティング](alb-ingress.md)」および [Network Load Balancer を使用して TCP および UDP トラフィックをルーティングする](network-load-balancing.md) で前提条件と考慮事項を確認しておくことをお勧めします。これらのトピックでは、AWS ロードバランサーを含むサンプルアプリケーションをデプロイしています。
**Kubernetes `Gateway` API**
AWS Load Balancer Controller バージョン `2.14.0` 以降では、Kubernetes `Gateway` の作成時に [AWS Application Load Balancer (ALB)](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html) が作成されます。Kubernetes Gateway は、イングレスよりも多くの設定を標準化します (イングレスでは、よく使用される多くのオプションにカスタム注釈が必要でした)。[Gateway リソースに適用可能な設定を確認します。](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/guide/gateway/gateway/)`Gateway` API の詳細については、Kubernetes ドキュメントの「[Gateway API](https://kubernetes.io/docs/concepts/services-networking/gateway/)」を参照してください。
## コントローラーのインストール
次のどちらかの手順を使用して AWS Load Balancer Controller をインストールできます。
+ Amazon EKS を初めて使用する場合は、AWS Load Balancer Controller のインストールが簡素化されるため、Helm を使用してインストールすることをお勧めします。詳細については、「[Helm による AWS Load Balancer Controller のインストール](lbc-helm.md)」を参照してください。
+ パブリックコンテナレジストリへのネットワークアクセスが制限されているクラスターなどの高度な設定には、Kubernetes マニフェストを使用します。詳細については、「[マニフェストによる AWS Load Balancer Controller のインストール](lbc-manifest.md)」を参照してください。
## 非推奨のコントローラーバージョンから移行する
+ 非推奨バージョンの AWS Load Balancer Controller がインストールされている場合は、「[非推奨になった ALB Ingress Controller からのアプリの移行](lbc-remove.md)」を参照してください。
+ 非推奨バージョンはアップグレードできません。このバージョンを削除し、AWS Load Balancer Controller の最新バージョンをインストールする必要があります。
+ 非推奨バージョンには以下が含まれます。
+ AWS Load Balancer Controller の前身である AWS ALB Ingress Controller for Kubernetes (「Ingress Controller」)。
+ AWS Load Balancer Controller の任意の `0.1.x ` バージョン
## レガシークラウドプロバイダー
Kubernetes には、AWS のレガシークラウドプロバイダーが含まれています。レガシークラウドプロバイダーは AWS Load Balancer Controller と同様に、AWS ロードバランサーをプロビジョニングできます。レガシークラウドプロバイダーは Classic Load Balancer を作成します。AWS Load Balancer Controller をインストールしない場合、Kubernetes はデフォルトでレガシークラウドプロバイダーを使用します。AWS Load Balancer Controller をインストールして、レガシークラウドプロバイダーを使用しないようにしてください。
**重要**
バージョン 2.5 以降では、AWS Load Balancer Controller は、`type: LoadBalancer` を持つ Kubernetes *サービス*リソースのデフォルトコントローラーとなり、サービスごとに AWS Network Load Balancer (NLB) を作成します。これは、サービスの変更ウェブフックを変化することで実行され、これにより `type: LoadBalancer` の新しいサービスの `spec.loadBalancerClass` フィールドが `service.k8s.aws/nlb` に設定されます。Helm チャートの値 `enableServiceMutatorWebhook` を `false` に設定すると、この機能をオフにして、[レガシークラウドプロバイダー](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/guide/service/annotations/#legacy-cloud-provider)をデフォルトのコントローラーとして使用するように戻すことができます。この機能をオフにしない限り、クラスターはサービスに新しい Classic Load Balancer をプロビジョニングしません。既存の Classic Load Balancer は従来どおり機能します。
# Helm による AWS Load Balancer Controller のインストール
**ヒント**
今後開催予定の Amazon EKS ワークショップに[登録](https://aws-experience.com/emea/smb/events/series/get-hands-on-with-amazon-eks?trk=4a9b4147-2490-4c63-bc9f-f8a84b122c8c&sc_channel=el)してください。
**ヒント**
Amazon EKS 自動モード ではネットワーク形成のアドオンをインストールまたはアップグレードする必要はありません。自動モード にはポッドのネットワーク形成とロードバランシング機能が含まれています。
詳細については、「[EKS Auto Mode を使用してクラスターインフラストラクチャを自動化する](automode.md)」を参照してください。
このトピックでは、Kubernetes のパッケージマネージャーである Helm と `eksctl` を使用して AWS Load Balancer Controller をインストールする方法について説明します。コントローラーはデフォルトのオプションでインストールされます。注釈を使用した設定などコントローラーの詳細については、GitHub で「[AWS Load Balancer Controller ドキュメント](https://kubernetes-sigs.github.io/aws-load-balancer-controller/)」を参照してください。
以下のステップでは、サンプル値を独自の値に置き換えます。
## 前提条件
このチュートリアルを開始する前に、以下のステップを完了する必要があります。
+ Amazon EKS クラスターを作成します。作成する場合は「[Amazon EKS の使用を開始する](getting-started.md)」を参照してください。
+ ローカルマシンに [Helm](https://helm.sh/docs/helm/helm_install/) をインストールします。
+ Amazon VPC CNI plugin for Kubernetes、`kube-proxy`、および CoreDNS アドオンが、[サービスアカウントトークン](service-accounts.md#boundserviceaccounttoken-validated-add-on-versions)に記載されている最小のバージョンであることを確認してください。
+ AWS Elastic Load Balancing の概念を確認します。詳細については、「[Elastic Load Balancing ユーザーガイド](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/)」を参照してください。
+ Kubernetes [サービス](https://kubernetes.io/docs/concepts/services-networking/service/)と [Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/) リソースについて確認します。
### 考慮事項
このページの設定手順に進む前に、以下の点について考慮してください。
+ IAM ポリシーとロール (`AmazonEKSLoadBalancerControllerRole`) は、同じ AWS アカウントの複数の EKS クラスターで再利用できます。
+ ロール (`AmazonEKSLoadBalancerControllerRole`) が最初に作成されたのと同じクラスターにコントローラーをインストールする場合は、ロールが存在することを確認した後、「[ステップ 2: Load Balancer Controller のインストール](#lbc-helm-install)」に進みます。
+ サービスアカウントの IAM ロール (IRSA) を使用している場合、IRSA はクラスターごとに設定する必要があり、ロールの信頼ポリシー内の OpenID Connect (OIDC) プロバイダー ARN は各 EKS クラスターに固有です。さらに、既存の `AmazonEKSLoadBalancerControllerRole` を使用して新しいクラスターにコントローラーをインストールする場合は、そのロールの信頼ポリシーを更新して新しいクラスターの OIDC プロバイダーを追加し、適切なロール注釈を持つ新しいサービスアカウントを作成します。OIDC プロバイダーが既に存在しているかどうかを確認する、または OIDC プロバイダーを作成するには、「[クラスターの IAM OIDC プロバイダーを作成するには](enable-iam-roles-for-service-accounts.md)」を参照してください。
## ステップ 1: `eksctl` を使用して IAM ロールを作成する
次の手順は、AWS Load Balancer Controller **v2.14.1** リリースバージョンに関するものです。すべてのリリースの詳細については、GitHub で「[AWS Load Balancer Controller Release Page](https://github.com/kubernetes-sigs/aws-load-balancer-controller/releases/)」を参照してください。
1. ユーザーに代わって AWS API を呼び出すことを許可する、AWS Load Balancer Controller 用の IAM ポリシーをダウンロードします。
```
curl -O https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/v2.14.1/docs/install/iam_policy.json
```
+ AWS パーティションが政府リージョンや中国リージョンなど標準以外のものである場合は、[GitHub でポリシーを確認](https://github.com/kubernetes-sigs/aws-load-balancer-controller/tree/main/docs/install)し、ご使用のリージョンに適切なポリシーをダウンロードします。
1. 前のステップでダウンロードしたポリシー を使用して、IAM ポリシーを作成します。
```
aws iam create-policy \
--policy-name AWSLoadBalancerControllerIAMPolicy \
--policy-document file://iam_policy.json
```
**注記**
AWS マネジメントコンソール でポリシーを確認すると、コンソールには **[ELB]** サービスに関する警告が表示されますが、**[ELB v2]** サービスに関する警告は表示されません。これは、ポリシー内のアクションの一部が **[ELB v2]** には存在するが、**[ELB]** には存在しないために起こります。**[ELB]** に関する警告は無視できます。
1. クラスター名、リージョンコード、およびアカウント ID の値を置き換えます。
```
eksctl create iamserviceaccount \
--cluster= \
--namespace=kube-system \
--name=aws-load-balancer-controller \
--attach-policy-arn=arn:aws:iam:::policy/AWSLoadBalancerControllerIAMPolicy \
--override-existing-serviceaccounts \
--region \
--approve
```
## ステップ 2: AWS Load Balancer Controller をインストールする
1. `eks-charts` Helm チャートリポジトリを追加します。AWS は[このリポジトリ](https://github.com/aws/eks-charts)を GitHub で管理しています。
```
helm repo add eks https://aws.github.io/eks-charts
```
1. ローカルリポジトリを更新して、最新のグラフがあることを確認します。
```
helm repo update eks
```
1. AWS Load Balancer コントローラをインストールします。
[Amazon EC2 インスタンスメタデータサービス (IMDS) に対するアクセスが制限されている](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node) Amazon EC2 ノードにコントローラーをデプロイする場合、または Fargate もしくは Amazon EKS Hybrid Nodes にデプロイする場合には、次の `helm` コマンドに次のフラグを追加します。
+ `--set region=region-code `
+ `--set vpcId=vpc-xxxxxxxx `
*マイクラスター* の部分は自分のクラスター名に置き換えます。次のコマンドの中の `aws-load-balancer-controller`は、前のステップで作成した Kubernetes サービスアカウントです。
Helm チャートの設定の詳細については、GitHub の「[values.yaml](https://github.com/aws/eks-charts/blob/master/stable/aws-load-balancer-controller/values.yaml)」を参照してください。
```
helm install aws-load-balancer-controller eks/aws-load-balancer-controller \
-n kube-system \
--set clusterName=my-cluster \
--set serviceAccount.create=false \
--set serviceAccount.name=aws-load-balancer-controller \
--version 1.14.0
```
**重要**
デプロイされたグラフは、セキュリティに関する更新を自動的に受信しません。この更新が利用可能になったら、手動で新しいグラフにアップグレードする必要があります。アップグレードする場合は、前のコマンドで *install* を `upgrade` に変更します。
`helm install` コマンドは、コントローラーのカスタムリソース定義 (CRD) を自動的にインストールします。一方、`helm upgrade` コマンドでは自動的にインストールされません。`helm upgrade,` コマンドを使用する場合は、CRD を手動でインストールする必要があります。次のコマンドを実行して、CRD をインストールします。
```
wget https://raw.githubusercontent.com/aws/eks-charts/master/stable/aws-load-balancer-controller/crds/crds.yaml
kubectl apply -f crds.yaml
```
## ステップ 3: コントローラーがインストールされていることを確認する
1. コントローラがインストールされていることを確認します。
```
kubectl get deployment -n kube-system aws-load-balancer-controller
```
出力例は次のとおりです。
```
NAME READY UP-TO-DATE AVAILABLE AGE
aws-load-balancer-controller 2/2 2 2 84s
```
Helm を使用してデプロイした場合は、前の出力を受け取ります。Kubernetes マニフェストを使用してデプロイした場合、レプリカは 1 つしかありません。
1. コントローラーを使用して AWS リソースをプロビジョニングする場合には、クラスターは特定の要件を満たしている必要があります。詳細については、「[Application Load Balancer を使用してアプリケーションと HTTP トラフィックをルーティングする](alb-ingress.md)」および「[Network Load Balancer を使用して TCP および UDP トラフィックをルーティングする](network-load-balancing.md)」を参照してください。
# マニフェストによる AWS Load Balancer Controller のインストール
**ヒント**
Amazon EKS Auto Mode では、ネットワーク形成のアドオンをインストールまたはアップグレードする必要はありません。自動モード にはポッドのネットワーク形成とロードバランシング機能が含まれています。
詳細については、「[EKS Auto Mode を使用してクラスターインフラストラクチャを自動化する](automode.md)」を参照してください。
このトピックでは、Kubernetes マニフェストをダウンロードし適用することでコントローラーをインストールする方法について説明します。コントローラについての完全な [ドキュメント](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/)は、GitHub でご覧になれます。
以下のステップでは、サンプル値を独自の値に置き換えます。
## 前提条件
このチュートリアルを開始する前に、以下のステップを完了する必要があります。
+ Amazon EKS クラスターを作成します。作成する場合は「[Amazon EKS の使用を開始する](getting-started.md)」を参照してください。
+ ローカルマシンに [Helm](https://helm.sh/docs/helm/helm_install/) をインストールします。
+ Amazon VPC CNI plugin for Kubernetes、`kube-proxy`、および CoreDNS アドオンが、[サービスアカウントトークン](service-accounts.md#boundserviceaccounttoken-validated-add-on-versions)に記載されている最小のバージョンであることを確認してください。
+ AWS Elastic Load Balancing の概念を確認します。詳細については、「[Elastic Load Balancing ユーザーガイド](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/)」を参照してください。
+ Kubernetes [サービス](https://kubernetes.io/docs/concepts/services-networking/service/)と [Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/) リソースについて確認します。
### 考慮事項
このページの設定手順に進む前に、以下の点について考慮してください。
+ IAM ポリシーとロール (`AmazonEKSLoadBalancerControllerRole`) は、同じ AWS アカウントの複数の EKS クラスターで再利用できます。
+ ロール (`AmazonEKSLoadBalancerControllerRole`) が最初に作成されたのと同じクラスターにコントローラーをインストールする場合は、ロールが存在することを確認した後、「[ステップ 2: cert-manager のインストール](#lbc-cert)」に進みます。
+ サービスアカウントの IAM ロール (IRSA) を使用している場合、IRSA はクラスターごとに設定する必要があり、ロールの信頼ポリシー内の OpenID Connect (OIDC) プロバイダー ARN は各 EKS クラスターに固有です。さらに、既存の `AmazonEKSLoadBalancerControllerRole` を使用して新しいクラスターにコントローラーをインストールする場合は、そのロールの信頼ポリシーを更新して新しいクラスターの OIDC プロバイダーを追加し、適切なロール注釈を持つ新しいサービスアカウントを作成します。OIDC プロバイダーが既に存在しているかどうかを確認する、または OIDC プロバイダーを作成するには、「[クラスターの IAM OIDC プロバイダーを作成するには](enable-iam-roles-for-service-accounts.md)」を参照してください。
## ステップ 1: IAM を設定する
次の手順は、AWS Load Balancer Controller **v2.14.1** リリースバージョンに関するものです。すべてのリリースの詳細については、GitHub で「[AWS Load Balancer Controller Release Page](https://github.com/kubernetes-sigs/aws-load-balancer-controller/releases/)」を参照してください。
1. ユーザーに代わって AWS API を呼び出すことを許可する、AWS Load Balancer Controller 用の IAM ポリシーをダウンロードします。
**Example**
------
#### [ AWS ]
```
curl -O https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/v2.14.1/docs/install/iam_policy.json
```
------
#### [ AWS GovCloud (US) ]
```
curl -O https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/v2.14.1/docs/install/iam_policy_us-gov.json
```
```
mv iam_policy_us-gov.json iam_policy.json
```
------
1. 前のステップでダウンロードしたポリシー を使用して、IAM ポリシーを作成します。
```
aws iam create-policy \
--policy-name AWSLoadBalancerControllerIAMPolicy \
--policy-document file://iam_policy.json
```
**注記**
AWS マネジメントコンソール でポリシーを確認すると、コンソールには **[ELB]** サービスに関する警告が表示されますが、**[ELB v2]** サービスに関する警告は表示されません。これは、ポリシー内のアクションの一部が **[ELB v2]** には存在するが、**[ELB]** には存在しないために起こります。**[ELB]** に関する警告は無視できます。
**Example**
1. *my-cluster* はご自分のクラスター名に、*111122223333* はご自分のアカウント ID に置き換えた上で、コマンドを実行します。
```
eksctl create iamserviceaccount \
--cluster=my-cluster \
--namespace=kube-system \
--name=aws-load-balancer-controller \
--role-name AmazonEKSLoadBalancerControllerRole \
--attach-policy-arn=arn:aws:iam::111122223333:policy/AWSLoadBalancerControllerIAMPolicy \
--approve
```
1. クラスターの OIDC プロバイダー ID を取得して、変数に格納します。
```
oidc_id=$(aws eks describe-cluster --name my-cluster --query "cluster.identity.oidc.issuer" --output text | cut -d '/' -f 5)
```
1. クラスターの ID を持つ IAM OIDC プロバイダーが既にアカウントにあるかどうかを確認します。クラスターと IAM の両方に OIDC を設定する必要があります。
```
aws iam list-open-id-connect-providers | grep $oidc_id | cut -d "/" -f4
```
出力が返された場合は、クラスター用の IAM OIDC プロバイダーが既に存在します。出力が返されない場合はクラスター用の IAM OIDC プロバイダーを作成する必要があります。詳細については、「[クラスターの IAM OIDC プロバイダーを作成するには](enable-iam-roles-for-service-accounts.md)」を参照してください。
1. 次のコンテンツをデバイスにコピーします。*111122223333* は、ご自分のアカウント ID に置き換えます。*region-code* を、クラスターのある AWS リージョンに置き換えます。*EXAMPLED539D4633E53DE1B71EXAMPLE* を、前のステップで返された出力に置き換えます。
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::111122223333:oidc-provider/oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {
"oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE:aud": "sts.amazonaws.com",
"oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE:sub": "system:serviceaccount:kube-system:aws-load-balancer-controller"
}
}
}
]
}
```
1. IAM ロールの作成
```
aws iam create-role \
--role-name AmazonEKSLoadBalancerControllerRole \
--assume-role-policy-document file://"load-balancer-role-trust-policy.json"
```
1. IAM ロールに、必要な Amazon EKS 管理の IAM ポリシーをアタッチします。*111122223333* は、ご自分のアカウント ID に置き換えます。
```
aws iam attach-role-policy \
--policy-arn arn:aws:iam::111122223333:policy/AWSLoadBalancerControllerIAMPolicy \
--role-name AmazonEKSLoadBalancerControllerRole
```
1. 次のコンテンツをデバイスにコピーします。*111122223333* は、ご自分のアカウント ID に置き換えます。テキストを置き換えたら、変更したコマンドを実行して `aws-load-balancer-controller-service-account.yaml` ファイルを作成します。
```
cat >aws-load-balancer-controller-service-account.yaml <
以下のいずれかの方法で `cert-manager` をインストールして、Webhook に証明書設定を導入します。詳細については、「*cert-manager ドキュメント*」の「[開始方法](https://cert-manager.io/docs/installation/#getting-started)」を参照してください。
`cert-manager` をインストールするには、`quay.io` コンテナレジストリを使用することをお勧めします。ノードが `quay.io` コンテナレジストリにアクセスできない場合は、Amazon ECR を使用して `cert-manager` をインストールします (以下を参照)。
**Example**
1. ノードが `quay.io` コンテナレジストリにアクセスできる場合は、`cert-manager` をインストールして、Webhook に証明書設定を挿入します。
```
kubectl apply \
--validate=false \
-f https://github.com/jetstack/cert-manager/releases/download/v1.13.5/cert-manager.yaml
```
1. 以下のいずれかの方法で `cert-manager` をインストールして、Webhook に証明書設定を導入します。詳細については、「*cert-manager ドキュメント*」の「[開始方法](https://cert-manager.io/docs/installation/#getting-started)」を参照してください。
1. マニフェストをダウンロードします。
```
curl -Lo cert-manager.yaml https://github.com/jetstack/cert-manager/releases/download/v1.13.5/cert-manager.yaml
```
1. 次のイメージをプルして、ノードがアクセスできるリポジトリにプッシュします。イメージをプルし、タグ付けして独自のリポジトリにプッシュする方法の詳細については、[あるリポジトリから別のリポジトリにコンテナイメージをコピーする](copy-image-to-repository.md) を参照してください。
```
quay.io/jetstack/cert-manager-cainjector:v1.13.5
quay.io/jetstack/cert-manager-controller:v1.13.5
quay.io/jetstack/cert-manager-webhook:v1.13.5
```
1. 三つのイメージのマニフェストの `quay.io` を、独自のレジストリ名に置き換えます。次のコマンドは、プライベートリポジトリの名前がソースリポジトリと同じであることを前提としています。*111122223333.dkr.ecr.region-code.amazonaws.com* をプライベートレジストリに置き換えます。
```
sed -i.bak -e 's|quay.io|111122223333.dkr.ecr.region-code.amazonaws.com|' ./cert-manager.yaml
```
1. マニフェストを適用します。
```
kubectl apply \
--validate=false \
-f ./cert-manager.yaml
```
## ステップ 3: AWS Load Balancer Controller をインストールする
1. Controller の詳細をダウンロードします。Controller の詳細については、GitHub の[ドキュメント](https://kubernetes-sigs.github.io/aws-load-balancer-controller/)を参照してください。
```
curl -Lo v2_14_1_full.yaml https://github.com/kubernetes-sigs/aws-load-balancer-controller/releases/download/v2.14.1/v2_14_1_full.yaml
```
1. ファイルに以下の編集を行います。
1. `v2_14_1_full.yaml` ファイルをダウンロードした場合は、次のコマンドを実行してマニフェストの `ServiceAccount` セクションを削除します。このセクションを削除しないと、前のステップでサービスアカウントに作成した必須の注釈が上書きされます。コントローラーを削除した場合、このセクションの削除により、前のステップで作成したサービスアカウントも保持されます。
```
sed -i.bak -e '764,772d' ./v2_14_1_full.yaml
```
別のバージョンのファイルをダウンロードした場合は、エディタでファイルを開き、次の行を削除します。
```
apiVersion: v1
kind: ServiceAccount
metadata:
labels:
app.kubernetes.io/component: controller
app.kubernetes.io/name: aws-load-balancer-controller
name: aws-load-balancer-controller
namespace: kube-system
---
```
1. *My-cluster* をユーザーのクラスター名に置き換えることにより、ファイルの`Deployment` `spec` セクションの `your-cluster-name` をクラスターの名前に置き換えます。
```
sed -i.bak -e 's|your-cluster-name|my-cluster|' ./v2_14_1_full.yaml
```
1. ノードが Amazon EKS Amazon ECR イメージリポジトリにアクセスできない場合は、次のイメージをプルして、ノードがアクセスできるリポジトリにプッシュする必要があります。イメージをプルし、タグ付けして独自のリポジトリにプッシュする方法の詳細については、[あるリポジトリから別のリポジトリにコンテナイメージをコピーする](copy-image-to-repository.md) を参照してください。
```
public.ecr.aws/eks/aws-load-balancer-controller:v2.14.1
```
マニフェストにレジストリの名前を追加します。次のコマンドは、プライベートリポジトリの名前がソースリポジトリと同じであると仮定し、プライベートレジストリの名前をファイルに追加します。*111122223333.dkr.ecr.region-code.amazonaws.com* をレジストリに置き換えます。この行は、プライベートリポジトリにソースリポジトリと同じ名前を付けたことを前提としています。そうでない場合は、プライベートレジストリ名の後の `eks/aws-load-balancer-controller` テキストを、リポジトリ名に変更します。
```
sed -i.bak -e 's|public.ecr.aws/eks/aws-load-balancer-controller|111122223333.dkr.ecr.region-code.amazonaws.com/eks/aws-load-balancer-controller|' ./v2_14_1_full.yaml
```
1. (Fargate または制限付き IMDS の場合にのみ必須)
[Amazon EC2 インスタンスメタデータサービス (IMDS) に対するアクセスが制限されている](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node) Amazon EC2 ノードにコントローラをデプロイする場合、または Fargate もしくは Amazon EKS Hybrid Nodes にデプロイする場合には、`- args:` の下に `following parameters` を追加します。
```
[...]
spec:
containers:
- args:
- --cluster-name=your-cluster-name
- --ingress-class=alb
- --aws-vpc-id=vpc-xxxxxxxx
- --aws-region=region-code
[...]
```
1. ファイルを適用します。
```
kubectl apply -f v2_14_1_full.yaml
```
1. `IngressClass` および `IngressClassParams` マニフェストをクラスターにダウンロードします。
```
curl -Lo v2.14.1_ingclass.yaml https://github.com/kubernetes-sigs/aws-load-balancer-controller/releases/download/v2.14.1/v2_14_1_ingclass.yaml
```
1. マニフェストをクラスターに適用します。
```
kubectl apply -f v2_14_1_ingclass.yaml
```
## ステップ 4: コントローラーがインストールされていることを確認する
1. コントローラがインストールされていることを確認します。
```
kubectl get deployment -n kube-system aws-load-balancer-controller
```
出力例は次のとおりです。
```
NAME READY UP-TO-DATE AVAILABLE AGE
aws-load-balancer-controller 2/2 2 2 84s
```
Helm を使用してデプロイした場合は、前の出力を受け取ります。Kubernetes マニフェストを使用してデプロイした場合、レプリカは 1 つしかありません。
1. コントローラーを使用して AWS リソースをプロビジョニングする場合には、クラスターは特定の要件を満たしている必要があります。詳細については、「[Application Load Balancer を使用してアプリケーションと HTTP トラフィックをルーティングする](alb-ingress.md)」および「[Network Load Balancer を使用して TCP および UDP トラフィックをルーティングする](network-load-balancing.md)」を参照してください。
# 非推奨になった ALB Ingress Controller からのアプリの移行
このトピックでは非推奨のコントローラーバージョンから移行する方法を説明します。具体的には、AWS Load Balancer Controller の非推奨バージョンを削除する方法について説明します。
+ 非推奨バージョンはアップグレードできません。まずそれらを削除してから、最新バージョンをインストールする必要があります。
+ 非推奨バージョンには以下が含まれます。
+ AWS Load Balancer Controller の前身である AWS ALB Ingress Controller for Kubernetes (「Ingress Controller」)。
+ AWS Load Balancer Controller の任意の `0.1.x ` バージョン
## 非推奨のコントローラーバージョンを削除する
**注記**
非推奨バージョンは、Helm を使用したか、Kubernetes マニフェストに従って手動でインストールされた可能性があります。この手順は元々インストールしてあるツールを使用して実行してください。
1. `incubator/aws-alb-ingress-controller` Helm チャートをインストールしてある場合はこれをアンインストールします。
```
helm delete aws-alb-ingress-controller -n kube-system
```
1. `eks-charts/aws-load-balancer-controller` のバージョン `0.1.x ` をインストールしている場合はこれをアンインストールします。`0.1.x ` からバージョン `1.0.0` へのアップグレードはWebhook API のバージョンとの互換性がないため動作しません。
```
helm delete aws-load-balancer-controller -n kube-system
```
1. イングレス・コントローラー がインストール済みであるかどうかを確認します。
```
kubectl get deployment -n kube-system alb-ingress-controller
```
これはコントローラが取り付けられていない場合の出力です。
```
Error from server (NotFound): deployments.apps "alb-ingress-controller" not found
```
これは、コントローラが取り付けられている場合の出力です。
```
NAME READY UP-TO-DATE AVAILABLE AGE
alb-ingress-controller 1/1 1 1 122d
```
1. 次のコマンドを入力してコントローラを削除します。
```
kubectl delete -f https://raw.githubusercontent.com/kubernetes-sigs/aws-alb-ingress-controller/v1.1.8/docs/examples/alb-ingress-controller.yaml
kubectl delete -f https://raw.githubusercontent.com/kubernetes-sigs/aws-alb-ingress-controller/v1.1.8/docs/examples/rbac-role.yaml
```
## AWS Load Balancer Controller への移行
ALB Ingress Controller for Kubernetes から AWS Load Balancer Controller に移行するには、以下を実行する必要があります。
1. ALB イングレス・コントローラー を削除します (上記を参照)。
1. [AWS ロードバランサー コントローラーをインストールします。](aws-load-balancer-controller.md#lbc-overview)
1. AWS Load Balancer Controller で使用される IAM ロールにポリシーを追加します。このポリシーにより、ALB Ingress Controller for Kubernetes によって作成されたリソースを LBC が管理できるようになります。
1. IAM ポリシーをダウンロードします。このポリシーにより、ALB Ingress Controller for Kubernetes によって作成されたリソースを AWS Load Balancer Controller が管理できるようになります。[ポリシーを表示](https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/main/docs/install/iam_policy_v1_to_v2_additional.json)することもできます。
```
curl -O https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/v2.14.1/docs/install/iam_policy_v1_to_v2_additional.json
```
1. クラスターが AWS GovCloud (米国東部) または AWS GovCloud (米国西部) の AWS リージョンにある場合は` arn:aws: ` を `arn:aws-us-gov:` に置き換えます。
```
sed -i.bak -e 's|arn:aws:|arn:aws-us-gov:|' iam_policy_v1_to_v2_additional.json
```
1. IAM ポリシーを作成し、返された ARN を書き留めます。
```
aws iam create-policy \
--policy-name AWSLoadBalancerControllerAdditionalIAMPolicy \
--policy-document file://iam_policy_v1_to_v2_additional.json
```
1. AWS Load Balancer Controller によって使用される IAM ロールに IAM ポリシーをアタッチします。*ロール名* を役割の名前 (例: `AmazonEKSLoadBalancerControllerRole`) に置き換えます。
`eksctl` を使用して役割を作成している場合、作成された役割名を見つけるには[AWS クラウドフォーメーション コンソール](https://console.aws.amazon.com/cloudformation)を開き、**eksctl-*マイクラスター*-addon-iamserviceaccount-kube-system-aws-load-balancer-controller** スタックを選択してください。[**Resources (リソース)**] タブを選択してください。役割名は[**Physical ID (物理 ID)**] 列で見つかります。
```
aws iam attach-role-policy \
--role-name your-role-name \
--policy-arn arn:aws:iam::111122223333:policy/AWSLoadBalancerControllerAdditionalIAMPolicy
```
# Amazon EKS クラスターで DNS の CoreDNS を管理する
**ヒント**
Amazon EKS 自動モード ではネットワーク形成のアドオンをインストールまたはアップグレードする必要はありません。自動モード にはポッドのネットワーク形成とロードバランシング機能が含まれています。
詳細については、「[EKS Auto Mode を使用してクラスターインフラストラクチャを自動化する](automode.md)」を参照してください。
CoreDNS は、Kubernetes クラスター DNS として機能する、フレキシブルで拡張可能な DNS サーバーです。少なくとも 1 つのノードで Amazon EKS クラスターを起動すると、クラスターにデプロイされたノード数に関係なく、デフォルトで CoreDNS イメージの 2 つのレプリカがデプロイされます。これらの CoreDNS ポッドは、クラスター内のすべてのポッドの名前解決を行います。クラスターに名前空間が CoreDNS `deployment` の名前空間と一致する名前空間を持つ [Fargate プロファイル](fargate-profile.md)が含まれいる場合、CoreDNS ポッドを Fargate ノードにデプロイできます。CoreDNS の詳細については、Kubernetes ドキュメント の「[Using CoreDNS for Service Discovery](https://kubernetes.io/docs/tasks/administer-cluster/coredns/)」を参照してください。
## CoreDNS のバージョン
次の表は、Kubernetes バージョンごとに Amazon EKS アドオンタイプの最新バージョンを示しています。
| Kubernetes バージョン | CoreDNS のバージョン |
| --- | --- |
| 1.35 | v1.13.2-eksbuild.1 |
| 1.34 | v1.13.2-eksbuild.1 |
| 1.33 | v1.13.2-eksbuild.1 |
| 1.32 | v1.11.4-eksbuild.28 |
| 1.31 | v1.11.4-eksbuild.28 |
| 1.30 | v1.11.4-eksbuild.28 |
| 1.29 | v1.11.4-eksbuild.28 |
**重要**
このアドオンを自己管理している場合、表のバージョンは利用可能なセルフマネージドバージョンと同じではない可能性があります。このアドオンのセルフマネージドタイプの更新の詳細については「[CoreDNS Amazon EKS セルフマネージドアドオンを更新する](coredns-add-on-self-managed-update.md)」を参照してください。
## CoreDNS アップグレードに関する重要な考慮事項
+ CoreDNS 更新では PodDisruptionBudget が使用され、更新プロセス中に DNS サービスの可用性を維持します。
+ CoreDNS デプロイの安定性と可用性を高めるには、`PodDisruptionBudget` を使用してバージョン `v1.9.3-eksbuild.6` 以降および `v1.10.1-eksbuild.3` をデプロイします。既存の `PodDisruptionBudget` をデプロイした場合、これらのバージョンへのアップグレードは失敗する可能性があります。アップグレードが失敗した場合は次のいずれかのタスクを実行することで問題が解決します。
+ Amazon EKS アドオンをアップグレードする際は競合解決のオプションとして既存の設定を上書きすることを選択してください。デプロイに他のカスタム設定を行った場合は、アップグレード後に他のカスタム設定を再適用できるように、アップグレード前に必ず設定をバックアップしてください。
+ 既存の `PodDisruptionBudget` を削除して、アップグレードを再試行してください。
+ EKS アドオンバージョン `v1.9.3-eksbuild.3` 以降および `v1.10.1-eksbuild.6` 以降では、CoreDNS デプロイは `/ready` エンドポイントを使用するように `readinessProbe` を設定します。このエンドポイントは、CoreDNS の `Corefile` 設定ファイルで有効になっています。
カスタム `Corefile` を使用する場合は、`ready` プラグインを設定に追加して、プローブが使用できるように `/ready` エンドポイントを CoreDNS でアクティブにする必要があります。
+ EKS アドオンバージョン `v1.9.3-eksbuild.7` 以降および `v1.10.1-eksbuild.4` 以降では`PodDisruptionBudget` を変更できます。次の例ではフィールドを使用して、アドオンを編集したり、**[任意の設定項目]**でこれらの設定を変更したりできます。この例はデフォルトの `PodDisruptionBudget` を示しています。
```
{
"podDisruptionBudget": {
"enabled": true,
"maxUnavailable": 1
}
}
```
`maxUnavailable` または `minAvailable` を設定できますが、両方を単一の `PodDisruptionBudget` で設定することはできません。`PodDisruptionBudgets` の詳細については*Kubernetes ドキュメント*の「[PodDisruptionBudgetの指定](https://kubernetes.io/docs/tasks/run-application/configure-pdb/#specifying-a-poddisruptionbudget)」を参照してください。
`enabled` を `false` に設定しても、`PodDisruptionBudget` は削除されないことに注意してください。このフィールドを `false` に設定後、`PodDisruptionBudget` オブジェクトを削除する必要があります。同様に、`PodDisruptionBudget` のあるバージョンにアップグレードした後、古いバージョンのアドオンを使用するようにアドオンを編集した場合 (アドオンをダウングレード)、`PodDisruptionBudget` は削除されません。次のコマンドを実行して、`PodDisruptionBudget` を削除します。
```
kubectl delete poddisruptionbudget coredns -n kube-system
```
+ EKS アドオンバージョン `v1.10.1-eksbuild.5` 以降ではデフォルトの許容値を KEP 2067 に準拠するように `node-role.kubernetes.io/master:NoSchedule` から `node-role.kubernetes.io/control-plane:NoSchedule` に変更してください。KEP 2067 の詳細については、GitHub で「*Kubernetes Enhancement Proposals (KEPs)*」の「[KEP-2067: Rename the kubeadm "master" label and taint](https://github.com/kubernetes/enhancements/tree/master/keps/sig-cluster-lifecycle/kubeadm/2067-rename-master-label-taint#renaming-the-node-rolekubernetesiomaster-node-taint)」を参照してください。
EKS アドオンバージョン `v1.8.7-eksbuild.8` 以降、および `v1.9.3-eksbuild.9` 以降では、どちらの許容範囲もすべての Kubernetes バージョンと互換性を維持できるように設定されています。
+ EKS アドオンバージョン `v1.9.3-eksbuild.11` および `v1.10.1-eksbuild.7` 以降では、CoreDNS デプロイは `topologySpreadConstraints` のデフォルト値を設定します。このデフォルト値により、複数のアベイラビリティーゾーンに使用可能なノードがある場合には、CoreDNS Pod がアベイラビリティーゾーン全体に分散します。デフォルト値の代わりに使用するカスタム値を設定できます。デフォルト値は次のとおりです。
```
topologySpreadConstraints:
- maxSkew: 1
topologyKey: topology.kubernetes.io/zone
whenUnsatisfiable: ScheduleAnyway
labelSelector:
matchLabels:
k8s-app: kube-dns
```
### CoreDNS `v1.11` アップグレードに関する考慮事項
+ EKS アドオン バージョン `v1.11.1-eksbuild.4` 以降ではコンテナイメージは Amazon EKS Distro によって維持される[最小ベースイメージ](https://gallery.ecr.aws/eks-distro-build-tooling/eks-distro-minimal-base)に基づいています。これには最小限のパッケージが含まれ、シェルはありません。詳細については「[Amazon EKS Distro](https://distro.eks.amazonaws.com/)」を参照してください。CoreDNS イメージの使用方法とトラブルシューティングは変わりません。
# CoreDNS Amazon EKS アドオンを作成する
CoreDNS Amazon EKS アドオンを作成します。アドオンを作成する前に、クラスターを用意する必要があります。詳細については、「[Amazon EKS クラスターを作成します。](create-cluster.md)」を参照してください。
1. クラスターにインストールされているアドオンのバージョンを確認します。
```
kubectl describe deployment coredns --namespace kube-system | grep coredns: | cut -d : -f 3
```
出力例は次のとおりです。
```
v1.10.1-eksbuild.13
```
1. クラスターにインストールされているアドオンのタイプを確認します。クラスターを作成するために使用したツールによっては、現在クラスターに アマゾン EKS アドオンタイプがインストールされていない場合があります。*マイクラスター* の部分は、自分のクラスター名に置き換えます。
```
aws eks describe-addon --cluster-name my-cluster --addon-name coredns --query addon.addonVersion --output text
```
バージョン番号が返された場合、アマゾン EKS タイプのアドオンがクラスターにインストールされているため、このステップの残りのステップを完了する必要はありません。エラーが返された場合、クラスターに アマゾン EKS タイプのアドオンがインストールされていません。インストールするには、このステップの残りのステップを完了します。
1. 現在インストールされているアドオンの設定を保存します。
```
kubectl get deployment coredns -n kube-system -o yaml > aws-k8s-coredns-old.yaml
```
1. AWS CLI を使用してアドオンを作成します。AWS マネジメントコンソール または `eksctl` を使用してアドオンを作成する場合は、「[Amazon EKS アドオンを作成する](creating-an-add-on.md)」を参照して、アドオン名の `coredns` を指定します。デバイスに沿ったコマンドをコピーします。必要に応じてコマンドに次の変更を加え、変更したコマンドを実行してください。
+ *マイクラスター* の部分は自分のクラスター名に置き換えます。
+ *v1.11.3-eksbuild.1* を、使用しているクラスターバージョンに対して[最新バージョンの表](managing-coredns.md#coredns-versions)に記載されている最新バージョンに置き換えます。
```
aws eks create-addon --cluster-name my-cluster --addon-name coredns --addon-version v1.11.3-eksbuild.1
```
Amazon EKS アドオンのデフォルト設定と競合するカスタム設定を現在のアドオンに適用した場合、作成が失敗する可能性があります。作成に失敗した場合、問題解決に役立つエラーが表示されます。または、前のコマンドに `--resolve-conflicts OVERWRITE` を追加することもできます。これにより、アドオンは既存のカスタム設定を上書きできます。アドオンを作成したら、カスタム設定で更新できます。
1. クラスターの Kubernetes バージョン用のアドオンの最新バージョンがクラスターに追加されたことを確認します。*マイクラスター* の部分は、自分のクラスター名に置き換えます。
```
aws eks describe-addon --cluster-name my-cluster --addon-name coredns --query addon.addonVersion --output text
```
アドオンの作成が完了するまでに数秒かかる場合があります。
出力例は次のとおりです。
```
v1.11.3-eksbuild.1
```
1. 元のアドオンに対してカスタム設定を行った場合は、Amazon EKS アドオンを作成する前に、前のステップで保存した設定を使用して、カスタム設定で Amazon EKS アドオンを更新します。アドオンの更新方法については「[CoreDNS Amazon EKS アドオンを更新する](coredns-add-on-update.md)」を参照してください。
# CoreDNS Amazon EKS アドオンを更新する
Amazon EKS タイプの アドオンを更新します。Amazon EKS アドオンをクラスターに追加していない場合は[アドオンを追加する](coredns-add-on-create.md)か、「[CoreDNS Amazon EKS セルフマネージドアドオンを更新する](coredns-add-on-self-managed-update.md)」を参照してください。
開始する前に、アップグレードに関する考慮事項を確認してください。詳細については「[CoreDNS アップグレードに関する重要な考慮事項](managing-coredns.md#coredns-upgrade)」を参照してください。
1. クラスターにインストールされているアドオンのバージョンを確認します。*マイクラスター* の部分は自分のクラスター名に置き換えます。
```
aws eks describe-addon --cluster-name my-cluster --addon-name coredns --query "addon.addonVersion" --output text
```
出力例は次のとおりです。
```
v1.10.1-eksbuild.13
```
返されたバージョンが、[最新バージョンの表](managing-coredns.md#coredns-versions)にあるクラスターの Kubernetes バージョンのバージョンと同じである場合は既に最新バージョンがクラスターにインストールされているため、この手順の残りを完了する必要はありません。出力にバージョン番号ではなくエラーが表示される場合はアマゾン EKS タイプのアドオンがクラスターにインストールされていません。この手順でアドオンを更新する前に、[アドオンを作成](coredns-add-on-create.md)する必要があります。
1. 現在インストールされているアドオンの設定を保存します。
```
kubectl get deployment coredns -n kube-system -o yaml > aws-k8s-coredns-old.yaml
```
1. AWS CLI を使用してアドオンを更新します。AWS マネジメントコンソール または `eksctl` を使用してアドオンを更新する場合は「[Amazon EKS アドオンを更新する](updating-an-add-on.md)」を参照してください。デバイスに沿ったコマンドをコピーします。必要に応じてコマンドに次の変更を加え、変更したコマンドを実行してください。
+ *マイクラスター* の部分は自分のクラスター名に置き換えます。
+ *v1.11.3-eksbuild.1* を、使用しているクラスターバージョンに対して[最新バージョンの表](managing-coredns.md#coredns-versions)に記載されている最新バージョンに置き換えます。
+ `--resolve-conflictsPRESERVE ` オプションはアドオンの既存の設定値を保存します。アドオン設定にカスタム値を設定していて、このオプションを使用しない場合、アマゾン EKS は値をデフォルト値で上書きします。このオプションを使用する場合、実稼働クラスターのアドオンを更新する前に、非稼動クラスターのフィールドおよび値変更をテストすることをお勧めします。この値を `OVERWRITE` に変更する場合、すべての設定が アマゾン EKS のデフォルト値に変更されます。いずれかの設定にカスタム値を設定した場合、アマゾン EKS のデフォルト値で上書きされる可能性があります。この値を `none` に変更した場合、アマゾン EKS は設定の値を一切変更しませんが、更新が失敗する可能性があります。更新に失敗した場合、競合の解決に役立つエラーメッセージが返されます。
+ 構成設定を更新しない場合はコマンドから `--configuration-values '{"replicaCount":3}'` を削除します。構成設定を更新する場合は*"replicaCount":3* を設定したい設定に置き換えてください。この例では、CoreDNS のレプリカの数は `3` に設定されています。指定する値は設定スキーマに対して有効である必要があります。設定スキーマが不明である場合は`aws eks describe-addon-configuration --addon-name coredns --addon-version v1.11.3-eksbuild.1 ` を実行して、*v1.11.3-eksbuild.1* を、設定を表示するアドオンのバージョン番号に置き換えます。出力でスキーマが返されます。既存のカスタム設定があり、それをすべて削除してすべての設定の値を Amazon EKS のデフォルトに戻したい場合はコマンドから *"replicaCount":3* を削除して、`{}` が空になるようにします。設定の詳細については、Kubernetes ドキュメントの「[Customizing DNS Service](https://kubernetes.io/docs/tasks/administer-cluster/dns-custom-nameservers/)」を参照してください。
```
aws eks update-addon --cluster-name my-cluster --addon-name coredns --addon-version v1.11.3-eksbuild.1 \
--resolve-conflicts PRESERVE --configuration-values '{"replicaCount":3}'
```
更新が完了するまでに数秒かかる場合があります。
1. アドオンのバージョンが更新されたことを確認します。*マイクラスター* の部分は自分のクラスター名に置き換えます。
```
aws eks describe-addon --cluster-name my-cluster --addon-name coredns
```
更新が完了するまでに数秒かかる場合があります。
出力例は次のとおりです。
```
{
"addon": {
"addonName": "coredns",
"clusterName": "my-cluster",
"status": "ACTIVE",
"addonVersion": "v1.11.3-eksbuild.1",
"health": {
"issues": []
},
"addonArn": "arn:aws:eks:region:111122223333:addon/my-cluster/coredns/d2c34f06-1111-2222-1eb0-24f64ce37fa4",
"createdAt": "2023-03-01T16:41:32.442000+00:00",
"modifiedAt": "2023-03-01T18:16:54.332000+00:00",
"tags": {},
"configurationValues": "{\"replicaCount\":3}"
}
}
```
# CoreDNS Amazon EKS セルフマネージドアドオンを更新する
**重要**
セルフマネージド型のアドオンを使用する代わりに、アマゾン EKS タイプのアドオンをクラスターに追加することをお勧めします。タイプの違いがよくわからない場合は「[Amazon EKS アドオン](eks-add-ons.md)」を参照してください。アマゾン EKS アドオンをクラスターに追加する方法については「[Amazon EKS アドオンを作成する](creating-an-add-on.md)」を参照してください。アマゾン EKS アドオンを使用できない場合はその理由に関する問題を[コンテナロードマップ GitHub リポジトリ](https://github.com/aws/containers-roadmap/issues)に送信することをお勧めします。
開始する前に、アップグレードに関する考慮事項を確認してください。詳細については「[CoreDNS アップグレードに関する重要な考慮事項](managing-coredns.md#coredns-upgrade)」を参照してください。
1. クラスターにインストールされているアドオンがセルフマネージド型であることを確認します。*マイクラスター* の部分は自分のクラスター名に置き換えます。
```
aws eks describe-addon --cluster-name my-cluster --addon-name coredns --query addon.addonVersion --output text
```
エラーメッセージが返された場合、クラスターにセルフマネージド型のアドオンがインストールされています。インストールするにはこのステップの残りのステップを完了します。バージョン番号が返された場合、クラスターに アマゾン EKS タイプのアドオンがインストールされています。Amazon EKS タイプのアドオンを更新するにはこの手順を使用するのではなく、「[CoreDNS Amazon EKS アドオンを更新する](coredns-add-on-update.md)」の手順を使用してください。アドオンタイプの違いがよくわからない場合は「[Amazon EKS アドオン](eks-add-ons.md)」を参照してください。
1. クラスターに現在インストールされているコンテナイメージのバージョンを確認します。
```
kubectl describe deployment coredns -n kube-system | grep Image | cut -d ":" -f 3
```
出力例は次のとおりです。
```
v1.8.7-eksbuild.2
```
1. 現在の CoreDNS のバージョンが `v1.5.0` 以降で、かつ [CoreDNS バージョン](managing-coredns.md#coredns-versions)表に記載されるバージョンよりも前の場合は、このステップをスキップしてください。現在のバージョンが `1.5.0` より前の場合、プロキシアドオンではなく進んだアドオンを使用するためには、CoreDNS の `ConfigMap` を修正する必要があります。
1. 次のコマンドを使用して `ConfigMap` を開きます。
```
kubectl edit configmap coredns -n kube-system
```
1. 次の行の `proxy` を `forward` に置き換えます。ファイルを保存し、エディタを終了します。
```
proxy . /etc/resolv.conf
```
1. Kubernetes `1.17` 以前にクラスターを最初にデプロイした場合は、CoreDNS マニフェストから廃止された行を削除する必要があります。
**重要**
CoreDNS バージョン `1.7.0` に更新する前に、この手順を完了する必要があります。以前のバージョンに更新する場合でも、この手順を完了することをお勧めします。
1. CoreDNS マニフェストにその行があるかどうか確認します。
```
kubectl get configmap coredns -n kube-system -o jsonpath='{$.data.Corefile}' | grep upstream
```
出力が返されない場合、マニフェストにその行がないため、次のステップに進み、CoreDNS を更新することができます。出力が返された場合はその行を削除します。
1. 以下のコマンドを使用して `ConfigMap`を編集し、ファイル内の `upstream` という単語がある行を削除します。このファイル内の他の部分は変更しないでください。行を削除したら、変更を保存します。
```
kubectl edit configmap coredns -n kube-system -o yaml
```
1. 現在の CoreDNS イメージバージョンを取得します。
```
kubectl describe deployment coredns -n kube-system | grep Image
```
出力例は次のとおりです。
```
602401143452.dkr.ecr.region-code.amazonaws.com/eks/coredns:v1.8.7-eksbuild.2
```
1. CoreDNS `1.8.3` 以降に更新する場合は、`endpointslices` のアクセス許可を `system:coredns` Kubernetes `clusterrole` に追加する必要があります。
```
kubectl edit clusterrole system:coredns -n kube-system
```
ファイルの `rules` セクション内の既存の権限行の下に次の行を追加します。
```
[...]
- apiGroups:
- discovery.k8s.io
resources:
- endpointslices
verbs:
- list
- watch
[...]
```
1. *602401143452* および *region-code* を、前のステップで返された出力の値に置き換えて、CoreDNS アドオンを更新します。*v1.11.3-eksbuild.1* を、使用している Kubernetes バージョンについて[最新バージョンの表](managing-coredns.md#coredns-versions)に記載されている CoreDNS バージョンに置き換えます。
```
kubectl set image deployment.apps/coredns -n kube-system coredns=602401143452.dkr.ecr.region-code.amazonaws.com/eks/coredns:v1.11.3-eksbuild.1
```
出力例は次のとおりです。
```
deployment.apps/coredns image updated
```
1. コンテナイメージのバージョンをもう一度チェックして、前のステップで指定したバージョンに更新されたことを確認します。
```
kubectl describe deployment coredns -n kube-system | grep Image | cut -d ":" -f 3
```
出力例は次のとおりです。
```
v1.11.3-eksbuild.1
```
# CoreDNS ポッドを高い DNS トラフィックにスケールする
1 つ以上のノードで Amazon EKS クラスターを起動すると、クラスターにデプロイされたノード数に関係なく、デフォルトで CoreDNS イメージの 2 つのレプリカのデプロイがデプロイされます。これらの CoreDNS ポッドは、クラスター内のすべてのポッドの名前解決を行います。アプリケーションは名前解決を使用して、クラスター内のポッドとサービスに接続し、同様にクラスター外のサービスに接続します。ポッドからの名前解決 (クエリ) のリクエスト数が増えると、CoreDNS ポッドが処理しきれなくなって速度が低下し、ポッドが処理できないリクエストが拒否される可能性があります。
CoreDNS ポッドの負荷の増加を処理するには、CoreDNS の自動スケーリングシステムを検討してください。Amazon EKS は、CoreDNS の EKS アドオンバージョンで CoreDNS デプロイの自動スケーリングを管理できます。この CoreDNS オートスケーラーは、ノード数や CPU コア数など、クラスターの状態を継続的にモニタリングします。この情報に基づいて、コントローラーは EKS クラスター内の CoreDNS デプロイのレプリカ数を動的に調整します。この機能は CoreDNS `v1.9` 以降で動作します。CoreDNS 自動スケーリングと互換性のあるバージョンの詳細については、次のセクションを参照してください。
システムは、クラスター内のノード数と CPU コアの両方に基づく動的な式を使用して CoreDNS レプリカを自動的に管理し、(numberOfNodes を 16 で割った値) と (numberOfCPUCores を 256 で割った値) のうち、大きい方の値として計算されます。10 分間のピーク期間にわたって需要を評価し、DNS クエリ負荷の増加に対応するために必要に応じて即座にスケールアップする一方で、システムの安定性を維持して中断を回避するために、3 分ごとにレプリカを 33% 削減するという段階的なスケールダウンを行います。
この機能はアプリケーションの全体的な可用性とクラスターのスケーラビリティを向上させるために、他の [EKS クラスターの自動スケーリングのベストプラクティス](https://aws.github.io/aws-eks-best-practices/cluster-autoscaling/)と組み合わせて使用することをお勧めします。
## 前提条件
Amazon EKS が CoreDNS デプロイをスケーリングするには、次の 3 つの前提条件があります。
+ CoreDNS の *EKS アドオン*バージョンを使用する必要があります。
+ クラスターは少なくとも最小のクラスターバージョンとプラットフォームバージョンを実行している必要があります。
+ クラスターは少なくとも CoreDNS の EKS アドオンの最小バージョンを実行している必要があります。
### 最小クラスターバージョン
CoreDNS の自動スケーリングは Amazon EKS によって管理されるクラスターコントロールプレーンの新しいコンポーネントによって行われます。このため、新しいコンポーネントを持つ最小プラットフォームバージョンをサポートする EKS リリースにクラスターをアップグレードする必要があります。
新しい Amazon EKS クラスター。デプロイするには「[Amazon EKS の使用を開始する](getting-started.md)」を参照してください。クラスターは次の表に示す Kubernetes バージョンとプラットフォームバージョン、またはそれ以降のいずれかを実行している必要があります。一覧にあるバージョンより後の Kubernetes とプラットフォームのバージョンもサポートされることにご注意ください。現在の Kubernetes バージョンを確認するには、次のコマンドの *my-cluster* をクラスターの名前に置き換えて、変更したコマンドを実行します。
```
aws eks describe-cluster --name my-cluster --query cluster.version --output text
```
| Kubernetes バージョン | プラットフォームバージョン |
| --- | --- |
| リストに記載なし | すべてのプラットフォームバージョン |
| `1.29.3` | `eks.7` |
| `1.28.8` | `eks.13` |
| `1.27.12` | `eks.17` |
| `1.26.15` | `eks.18` |
**注記**
以降の Kubernetes バージョンのすべてのプラットフォームバージョンもサポートされています。例えば、Kubernetes バージョン `1.30` の `eks.1` 以降のバージョンなどです。
### EKS アドオンの最小バージョン
| Kubernetes バージョン | 1.29 | 1.28 |
| --- | --- | --- |
| | `v1.11.1-eksbuild.9` | `v1.10.1-eksbuild.11` |
#### AWS マネジメントコンソールで CoreDNS 自動スケーリングを設定する
1. クラスターが最小クラスターバージョン以上であることを確認します。
Amazon EKS は同じ Kubernetes バージョンのプラットフォームバージョン間でクラスターを自動的にアップグレードするため、このプロセスを自分で開始することはできません。代わりに、クラスターを次の Kubernetes バージョンにアップグレードすると、クラスターはその K8s バージョンと最新のプラットフォームバージョンにアップグレードされます。
新しい Kubernetes バージョンでは、大幅な変更が加えられている場合があります。このため、本稼働用クラスターで更新を行う前に、新しい Kubernetes バージョンのクラスターを別に用意し、アプリケーションの動作をテストしておくことをお勧めします。
クラスターを新しい Kubernetes バージョンにアップグレードするには、「[Update existing cluster to new Kubernetes version](update-cluster.md)」の手順に従います。
1. セルフマネージド型の CoreDNS デプロイではなく、CoreDNS 用の EKS アドオンがあることを確認します。
クラスターを作成するために使用したツールによっては現在クラスターに Amazon EKS アドオンタイプがインストールされていない場合があります。クラスターにインストールされているアドオンのタイプを確認するには次のコマンドを実行してください。`my-cluster` を自分のクラスター名に置き換えます。
```
aws eks describe-addon --cluster-name my-cluster --addon-name coredns --query addon.addonVersion --output text
```
バージョン番号が返された場合、クラスターに Amazon EKS タイプのアドオンがインストールされ、次のステップに進むことができます。エラーが返された場合、クラスターに Amazon EKS タイプのアドオンがインストールされていません。ステップ「[CoreDNS Amazon EKS を作成する](coredns-add-on-create.md)」の残りのステップを完了して、セルフマネージドバージョンを Amazon EKS アドオンに置き換えます。
1. CoreDNS の EKS アドオンが、最小 EKS アドオンバージョンと同じかそれ以上のバージョンであることを確認します。
クラスターにインストールされているアドオンのバージョンを確認します。AWS マネジメントコンソールで確認するか、以下のコマンドを実行できます：
```
kubectl describe deployment coredns --namespace kube-system | grep coredns: | cut -d : -f 3
```
出力例は次のとおりです。
```
v1.10.1-eksbuild.13
```
このバージョンを前のセクションの最小 EKS アドオンバージョンと比較します。必要に応じて、「[CoreDNS Amazon EKS アドオンを更新する](coredns-add-on-update.md)」の手順に従って EKS アドオンを上位のバージョンにアップグレードします。
1. 自動スケーリング設定を EKS アドオンの **[オプションの設定]** に追加します。
1. [Amazon EKS コンソール](https://console.aws.amazon.com/eks/home#/clusters)を開きます。
1. 左のナビゲーションペインで、**[クラスター]** を選択し、次にアドオンを設定するクラスター名を選択してください。
1. **[アドオン]** タブを選択してください。
1. CoreDNS アドオンボックスの右上にあるボックスを選択し、次に **[編集]** を選択してください。
1. **[CoreDNS の設定]** ページで、次の操作を行います。
1. 使用する **[バージョン]** を選択してください。前のステップと同じバージョンを保持し、別のアクションでバージョンと設定を更新することをお勧めします。
1. **[オプションの構成設定]** を展開します。
1. **[設定値]** で JSON キー `"autoscaling":` とネストした JSON オブジェクトの値に、キー `"enabled":` と値 `true` を指定します。結果のテキストは有効な JSON オブジェクトでなければなりません。このキーと値だけがテキストボックス内のデータである場合はキーと値を中括弧 `{ }` で囲みます。次の例は自動スケーリングが有効になっていることを示しています：
```
{
"autoScaling": {
"enabled": true
}
}
```
1. (オプション) 自動スケーリングが CoreDNS ポッド数をスケールできる最小値と最大値を指定できます。
次の例は自動スケーリングが有効で、すべてのオプションキーに値があることを示しています。クラスター内の DNS サービスに回復力を提供できるように、CoreDNS ポッドの最小数は常に 2 より大きくすることをお勧めします。
```
{
"autoScaling": {
"enabled": true,
"minReplicas": 2,
"maxReplicas": 10
}
}
```
1. CoreDNS ポッドを置き換えて新しい設定を適用するには、**[変更を保存]** を選択します。
Amazon EKS は CoreDNS の Kubernetes デプロイの*ロールアウト*を使用して EKS アドオンに変更を適用します。ロールアウトのステータスはAWS マネジメントコンソール のアドオン **[更新履歴]** と `kubectl rollout status deployment/coredns --namespace kube-system` で追跡できます。
`kubectl rollout` は以下のコマンドを実行してください：
```
kubectl rollout
history -- View rollout history
pause -- Mark the provided resource as paused
restart -- Restart a resource
resume -- Resume a paused resource
status -- Show the status of the rollout
undo -- Undo a previous rollout
```
ロールアウトに時間がかかりすぎる場合、Amazon EKS はロールアウトを取り消し、**[アドオン更新]** のタイプと **[失敗]** のステータスのメッセージがアドオンの **[更新履歴]** に追加されます。問題を調査するにはロールアウトの履歴から開始し、CoreDNS のポッドで `kubectl logs` を実行して CoreDNS のログを確認します。
1. **[更新履歴]** の新しいエントリのステータスが **[成功]** の場合、ロールアウトが完了し、アドオンはすべての CoreDNS のポッドで新しい設定を使用していることを意味します。クラスター内のノード数とノードの CPU コア数を変更すると、Amazon EKS は CoreDNS デプロイのレプリカ数をスケールします。
#### AWS コマンドラインインターフェイスで CoreDNS 自動スケーリングを設定する
1. クラスターが最小クラスターバージョン以上であることを確認します。
Amazon EKS は同じ Kubernetes バージョンのプラットフォームバージョン間でクラスターを自動的にアップグレードするため、このプロセスを自分で開始することはできません。代わりに、クラスターを次の Kubernetes バージョンにアップグレードすると、クラスターはその K8s バージョンと最新のプラットフォームバージョンにアップグレードされます。
新しい Kubernetes バージョンでは、大幅な変更が加えられている場合があります。このため、本稼働用クラスターで更新を行う前に、新しい Kubernetes バージョンのクラスターを別に用意し、アプリケーションの動作をテストしておくことをお勧めします。
クラスターを新しい Kubernetes バージョンにアップグレードするには、「[Update existing cluster to new Kubernetes version](update-cluster.md)」の手順に従います。
1. セルフマネージド型の CoreDNS デプロイではなく、CoreDNS 用の EKS アドオンがあることを確認します。
クラスターを作成するために使用したツールによっては現在クラスターに Amazon EKS アドオンタイプがインストールされていない場合があります。クラスターにインストールされているアドオンのタイプを確認するには次のコマンドを実行してください。`my-cluster` を自分のクラスター名に置き換えます。
```
aws eks describe-addon --cluster-name my-cluster --addon-name coredns --query addon.addonVersion --output text
```
バージョン番号が返された場合、クラスターに Amazon EKS タイプのアドオンがインストールされています。エラーが返された場合、クラスターに Amazon EKS タイプのアドオンがインストールされていません。ステップ「[CoreDNS Amazon EKS を作成する](coredns-add-on-create.md)」の残りのステップを完了して、セルフマネージドバージョンを Amazon EKS アドオンに置き換えます。
1. CoreDNS の EKS アドオンが、最小 EKS アドオンバージョンと同じかそれ以上のバージョンであることを確認します。
クラスターにインストールされているアドオンのバージョンを確認します。AWS マネジメントコンソールで確認するか、以下のコマンドを実行できます：
```
kubectl describe deployment coredns --namespace kube-system | grep coredns: | cut -d : -f 3
```
出力例は次のとおりです。
```
v1.10.1-eksbuild.13
```
このバージョンを前のセクションの最小 EKS アドオンバージョンと比較します。必要に応じて、「[CoreDNS Amazon EKS アドオンを更新する](coredns-add-on-update.md)」の手順に従って EKS アドオンを上位のバージョンにアップグレードします。
1. 自動スケーリング設定を EKS アドオンの **[オプションの設定]** に追加します。
次の AWS CLI コマンドを実行してください。`my-cluster` をクラスターの名前に置き換え、IAM ロール ARN を使用するロールに置き換えます。
```
aws eks update-addon --cluster-name my-cluster --addon-name coredns \
--resolve-conflicts PRESERVE --configuration-values '{"autoScaling":{"enabled":true}}'
```
Amazon EKS は CoreDNS の Kubernetes デプロイの*ロールアウト*を使用して EKS アドオンに変更を適用します。ロールアウトのステータスはAWS マネジメントコンソール のアドオン **[更新履歴]** と `kubectl rollout status deployment/coredns --namespace kube-system` で追跡できます。
`kubectl rollout` は以下のコマンドを実行してください：
```
kubectl rollout
history -- View rollout history
pause -- Mark the provided resource as paused
restart -- Restart a resource
resume -- Resume a paused resource
status -- Show the status of the rollout
undo -- Undo a previous rollout
```
ロールアウトに時間がかかりすぎる場合、Amazon EKS はロールアウトを取り消し、**[アドオン更新]** のタイプと **[失敗]** のステータスのメッセージがアドオンの **[更新履歴]** に追加されます。問題を調査するにはロールアウトの履歴から開始し、CoreDNS のポッドで `kubectl logs` を実行して CoreDNS のログを確認します。
1. (オプション) 自動スケーリングが CoreDNS ポッド数をスケールできる最小値と最大値を指定できます。
次の例は自動スケーリングが有効で、すべてのオプションキーに値があることを示しています。クラスター内の DNS サービスに回復力を提供できるように、CoreDNS ポッドの最小数は常に 2 より大きくすることをお勧めします。
```
aws eks update-addon --cluster-name my-cluster --addon-name coredns \
--resolve-conflicts PRESERVE --configuration-values '{"autoScaling":{"enabled":true,"minReplicas":2,"maxReplicas":10}}'
```
1. 次のコマンドを実行して、アドオンの更新のステータスを確認します：
```
aws eks describe-addon --cluster-name my-cluster --addon-name coredns
```
`"status": "ACTIVE"` という行が表示された場合、ロールアウトが完了し、アドオンはすべての CoreDNS ポッドで新しい設定を使用していることを意味します。クラスター内のノード数とノードの CPU コア数を変更すると、Amazon EKS は CoreDNS デプロイのレプリカ数をスケールします。
# CoreDNS メトリクスを使用して Kubernetes DNS 解決をモニタリングする
CoreDNS は、EKS アドオンとして、`9153` ポートの CoreDNS からのメトリクスを `kube-dns` サービス内の Prometheus 形式で公開します。Prometheus、Amazon CloudWatch エージェント、またはその他の互換性のあるシステムを使用して、これらのメトリックスをスクレイピング (収集 できます。
Prometheus と CloudWatch エージェントの両方と互換性のあるスクレイプ設定の例についてはAmazon CloudWatch ユーザーガイドの「[Prometheus 用の CloudWatch エージェント設定](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContainerInsights-Prometheus-Setup-configure.html)」を参照してください。
# Amazon EKS クラスターで `kube-proxy` を管理する
**ヒント**
Amazon EKS 自動モード ではネットワーク形成のアドオンをインストールまたはアップグレードする必要はありません。自動モード にはポッドのネットワーク形成とロードバランシング機能が含まれています。
詳細については「[EKS Auto Mode を使用してクラスターインフラストラクチャを自動化する](automode.md)」を参照してください。
セルフマネージド型のアドオンを使用する代わりに、Amazon EKS タイプのアドオンをクラスターに追加することをお勧めします。タイプの違いがよくわからない場合は「[Amazon EKS アドオン](eks-add-ons.md)」を参照してください。Amazon EKS アドオンをクラスターに追加する方法については「[Amazon EKS アドオンを作成する](creating-an-add-on.md)」を参照してください。Amazon EKS アドオンを使用できない場合はその理由に関する問題を[コンテナロードマップ GitHub リポジトリ](https://github.com/aws/containers-roadmap/issues)に送信することをお勧めします。
`kube-proxy` アドオンは Amazon EKS クラスター内の各 Amazon EC2 ノードにデプロイされます。これは、ノード上のネットワークルールを維持し、Pod へのネットワーク通信を有効にします。アドオンはクラスター内の Fargate ノードにはデプロイされません。詳細については、Kubernetes ドキュメントの「[kube-proxy](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-proxy/)」を参照してください。
## Amazon EKS アドオンとしてインストールする
## `kube-proxy` バージョン
次の表は、Kubernetes バージョンごとに Amazon EKS アドオンタイプの最新バージョンを示しています。
| Kubernetes バージョン | `kube-proxy` バージョン |
| --- | --- |
| 1.35 | v1.35.0-eksbuild.2 |
| 1.34 | v1.34.5-eksbuild.2 |
| 1.33 | v1.33.9-eksbuild.2 |
| 1.32 | v1.32.13-eksbuild.2 |
| 1.31 | v1.31.14-eksbuild.6 |
| 1.30 | v1.30.14-eksbuild.24 |
| 1.29 | v1.29.15-eksbuild.32 |
**注記**
以前のバージョンのドキュメントには誤りが含まれていました。`kube-proxy` バージョン `v1.28.5`、`v1.27.9`、および `v1.26.12` は利用できません。
このアドオンを自己管理している場合、表のバージョンは利用可能なセルフマネージドバージョンと同じではない可能性があります。
## `kube-proxy` コンテナイメージ
`kube-proxy` コンテナイメージは Amazon EKS Distro によって維持される[最小ベースイメージ](https://gallery.ecr.aws/eks-distro-build-tooling/eks-distro-minimal-base-iptables)に基づいています。これには最小限のパッケージが含まれ、シェルはありません。詳細については「[Amazon EKS Distro](https://distro.eks.amazonaws.com/)」を参照してください。
次の表に、各 Amazon EKS クラスターバージョンで利用可能な最新のセルフマネージド `kube-proxy` コンテナイメージのバージョンを示します。
| バージョン | kube-proxy |
| --- | --- |
| 1.35 | v1.35.0-eksbuild.2 |
| 1.34 | v1.34.1-eksbuild.2 |
| 1.33 | v1.33.5-minimal-eksbuild.2 |
| 1.32 | v1.32.9-minimal-eksbuild.2 |
| 1.31 | v1.31.13-minimal-eksbuild.2 |
| 1.30 | v1.30.14-minimal-eksbuild.8 |
| 1.29 | v1.29.15-minimal-eksbuild.16 |
[Amazon EKS アドオンタイプ](updating-an-add-on.md)を更新するときは有効な Amazon EKS アドオンバージョンを指定しますが、この表に記載されているバージョンではない可能性があります。これは[Amazon EKS アドオン](workloads-add-ons-available-eks.md#add-ons-kube-proxy)のバージョンが、このアドオンのセルフマネージドタイプを更新するときに指定されるコンテナイメージのバージョンと常に一致するとは限らないためです。このアドオンのセルフマネージドタイプを更新するときはこの表に記載されている有効なコンテナイメージのバージョンを指定します。
# Kubernetes `kube-proxy` セルフマネージドアドオンの更新
**重要**
セルフマネージド型のアドオンを使用する代わりに、アマゾン EKS タイプのアドオンをクラスターに追加することをお勧めします。タイプの違いがよくわからない場合は「[Amazon EKS アドオン](eks-add-ons.md)」を参照してください。アマゾン EKS アドオンをクラスターに追加する方法については「[Amazon EKS アドオンを作成する](creating-an-add-on.md)」を参照してください。Amazon EKS アドオンを使用できない場合は、その理由に関する問題を[コンテナロードマップ GitHub リポジトリ](https://github.com/aws/containers-roadmap/issues)に送信することをお勧めします。
## 前提条件
+ 既存の Amazon EKS クラスター。デプロイするには「[Amazon EKS の使用を開始する](getting-started.md)」を参照してください。
## 考慮事項
+ Amazon EKS クラスターの `Kube-proxy` は、[Kubernetes と同じ互換性およびスキューポリシー](https://kubernetes.io/releases/version-skew-policy/#kube-proxy)が適用されます。[Amazon EKS アドオンバージョンのクラスターとの互換性の検証](addon-compat.md)について説明します。
1. クラスターにインストールされているアドオンがセルフマネージド型であることを確認します。*マイクラスター* の部分は自分のクラスター名に置き換えます。
```
aws eks describe-addon --cluster-name my-cluster --addon-name kube-proxy --query addon.addonVersion --output text
```
エラーメッセージが返された場合、クラスターにセルフマネージド型のアドオンがインストールされています。このトピックの残りの手順は、セルフマネージド型のアドオンを更新することです。バージョン番号が返された場合、クラスターに Amazon EKS タイプのアドオンがインストールされています。Amazon EKS タイプのアドオンを更新するには、このトピックの手順を使用するのではなく、「[Amazon EKS アドオンの更新](updating-an-add-on.md)」の手順を使用してください。アドオンタイプの違いがよくわからない場合は、「[Amazon EKS アドオン](eks-add-ons.md)」を参照してください。
1. クラスターに現在インストールされているコンテナイメージのバージョンを確認します。
```
kubectl describe daemonset kube-proxy -n kube-system | grep Image
```
出力例は次のとおりです。
```
Image: 602401143452.dkr.ecr.region-code.amazonaws.com/eks/kube-proxy:v1.29.1-eksbuild.2
```
出力例では、*v1.29.1-eksbuild.2* がクラスターにインストールされているバージョンです。
1. *602401143452* および *region-code* を、前のステップの出力の値に置き換えて、`kube-proxy` アドオンを更新します。*v1.30.6-eksbuild.3* を、「[Amazon EKS クラスターの各バージョンで使用可能な最新のセルフマネージド kube-proxy コンテナイメージバージョン](managing-kube-proxy.md#managing-kube-proxy-images)」の表に記載されている `kube-proxy` バージョンに置き換えます。
**重要**
各イメージタイプのマニフェストは異なり、*デフォルト*または*最小*のイメージタイプ間で互換性がありません。エントリポイントと引数が一致するように、前のイメージと同じイメージタイプを使用する必要があります。
```
kubectl set image daemonset.apps/kube-proxy -n kube-system kube-proxy=602401143452.dkr.ecr.region-code.amazonaws.com/eks/kube-proxy:v1.30.6-eksbuild.3
```
出力例は次のとおりです。
```
daemonset.apps/kube-proxy image updated
```
1. 新しいバージョンがクラスターにインストールされたことを確認します。
```
kubectl describe daemonset kube-proxy -n kube-system | grep Image | cut -d ":" -f 3
```
出力例は次のとおりです。
```
v1.30.0-eksbuild.3
```
1. 同じクラスターで `x86` ノードと `Arm` ノードを使用しており、クラスターが 2020 年 8 月 17 日より前にデプロイされている場合。以下のコマンドにより `kube-proxy` マニフェストを編集して、複数のハードウェアアーキテクチャにノードセレクターを含めます。このオペレーションを行うのは 1 回限りです。マニフェストにセレクタを追加した後、アドオンを更新するたびに追加する必要はありません。クラスターが 2020 年 8 月 17 日以降にデプロイされている場合、`kube-proxy` は既にマルチアーキテクチャに対応しています。
```
kubectl edit -n kube-system daemonset/kube-proxy
```
エディタを使用して、次のノードセレクターをファイルに追加し、その内容を保存します。エディタ上で、このテキストを挿入する場所の例については、GitHub の[CNI マニフェスト](https://github.com/aws/amazon-vpc-cni-k8s/blob/release-1.11/config/master/aws-k8s-cni.yaml#L265-#L269)ファイルをご覧ください。これにより、Kubernetes はノードのハードウェアアーキテクチャに基づいて、正しいハードウェアイメージを取得できるようになります。
```
- key: "kubernetes.io/arch"
operator: In
values:
- amd64
- arm64
```
1. クラスターを最初に作成したのが Kubernetes バージョン `1.14` 以降である場合は、既にこの `Affinity Rule` が `kube-proxy` に含まれているため、この手順をスキップできます。Amazon EKS クラスターを最初に作成したのが Kubernetes `1.13` 以前のバージョンであり、今後そのクラスターで Fargate ノードを使用する場合は、`kube-proxy` マニフェストを編集して `NodeAffinity` ルールを含め、`kube-proxy` Pod が Fargate ノードでスケジュールしないようにしてください。この編集を行うのは 1 回限りです。`Affinity Rule` をマニフェストに一度追加したら、アドオンを更新するたびに追加する必要はありません。`kube-proxy` DaemonSet を編集します。
```
kubectl edit -n kube-system daemonset/kube-proxy
```
エディタで、次の `Affinity Rule` をファイルの DaemonSet `spec` セクションに追加して、ファイルを保存します。エディタ上で、このテキストを挿入する場所の例については、GitHub の[CNI マニフェスト](https://github.com/aws/amazon-vpc-cni-k8s/blob/release-1.11/config/master/aws-k8s-cni.yaml#L270-#L273)ファイルをご覧ください。
```
- key: eks.amazonaws.com/compute-type
operator: NotIn
values:
- fargate
```