**このページの改善にご協力ください**
このユーザーガイドに貢献するには、すべてのページの右側のペインにある「**GitHub でこのページを編集する**」リンクを選択してください。
# EKS クラスターに WiWindows ノードをデプロイする
Amazon EKS クラスターの Windows サポートを有効にして管理し、Linux コンテナと一緒に Windows コンテナを実行する方法について説明します。
## 考慮事項
Windows ノードをデプロイする前に、以下の考慮事項を確認してください。
+ EKS Auto Mode は Windows ノードをサポートしていません
+ `HostProcess` ポッドを使用して Windows ノードでホスト ネットワークを使用できます。詳細については、Kubernetes ドキュメントの「[Create a Windows HostProcessPod](https://kubernetes.io/docs/tasks/configure-pod-container/create-hostprocess-pod/)」を参照してください。
+ CoreDNS など、Linux でのみ動作するコアシステム Pod を実行するには、Amazon EKS クラスターに 1 つ以上の Linux ノードまたは Fargate ノードが含まれている必要があります。
+ `kubelet` および `kube-proxy` イベントログは `EKS Windows` Event Log にリダイレクトされ、200 MB の制限に設定されます。
+ Windows ノードで実行されている Pod で、[[セキュリティグループを個別のポッドに割り当てる]](security-groups-for-pods.md) を使用することはできません。
+ Windows ノードで[カスタムネットワーク](cni-custom-network.md)を使用することはできません。
+ `IPv6` を Windows ノードで使用することはできません。
+ Windows ノードは、ノードごとに 1 つの Elastic Network Interface をサポートします。デフォルトでは、Windows ノードごとに実行できる Pod の数は、ノードのインスタンスタイプの Elastic Network Interface ごとに使用できる IP アドレスの数から 1 を引いた数に等しくなります。詳細については、「*Amazon EC2 ユーザーガイド*」の「[各インスタンスタイプのネットワークインターフェイスあたりの IP アドレス](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/using-eni.html#AvailableIpPerENI)」を参照してください。
+ Amazon EKS クラスターでは、ロードバランサーを持つ単一のサービスが、最大 1,024 個のバックエンド Pod をサポートできます。各ポッドには固有の IP アドレスがあります。[OS ビルド 17763.2746](https://support.microsoft.com/en-us/topic/march-22-2022-kb5011551-os-build-17763-2746-preview-690a59cd-059e-40f4-87e8-e9139cc65de4) で始まる [Windows Server 更新プログラム](https://github.com/microsoft/Windows-Containers/issues/93)以降、以前の 64 個の Pod という上限はなくなりました。
+ Windows コンテナは Fargate の Amazon EKS Pod ではサポートされていません。
+ Windows を搭載した Amazon EKS Hybrid Nodes をホストのオペレーティングシステムとして使用することはできません。
+ `vpc-resource-controller` ポッドからはログを取得できません。コントローラーをデータプレーンにデプロイしていたときには取得できていました。
+ `IPv4` アドレスが新しいポッドに割り当てられるまでにはクールダウン期間があります。これは、古い `kube-proxy` ルールが原因で、同じ `IPv4` アドレスを持つ古いポッドにトラフィックが流れるのを防ぎます。
+ コントローラーのソースは GitHub で管理されます。コントローラーに関する投稿や、問題の登録を行うには、GitHub の [project](https://github.com/aws/amazon-vpc-resource-controller-k8s) にアクセスしてください。
+ Windows マネージド型ノードグループのカスタム AMI ID を指定するときは、AWS IAM オーセンティケーター設定マップに `eks:kube-proxy-windows` を追加します。詳細については、「[AMI ID を指定する場合の制限と条件](launch-templates.md#mng-ami-id-conditions)」を参照してください。
+ サブネットで使用可能な IPv4 アドレスを保持することが重要な場合は、「[EKS Best Practices Guide - Windows Networking IP Address Management](https://aws.github.io/aws-eks-best-practices/windows/docs/networking/#ip-address-management)」のガイダンスを参照してください。
+ EKS アクセスエントリに関する考慮事項
+ Windows ノードで使用するアクセスエントリには、タイプとして `EC2_WINDOWS` を指定する必要があります。詳細については、「[アクセスエントリを作成する](creating-access-entries.md)」を参照してください。
Windows ノード用のアクセスエントリを作成するには、次のように指定します。
```
aws eks create-access-entry --cluster-name my-cluster --principal-arn arn:aws:iam::111122223333:role/ --type EC2_Windows
```
## 前提条件
+ 既存のクラスター。
+ CoreDNS を実行するには、クラスターに少なくとも 1 つ (推奨値は少なくとも 2 つ) の Linux ノードまたは Fargate Pod が必要です。レガシー Windows サポートを有効にする場合は、CoreDNS の実行に Linux ノードを使用する必要があります (Fargate Pod は使用できません)。
+ 既存の [Amazon EKS クラスター IAM ロール](cluster-iam-role.md)。
## Windows サポートを有効にする
1. クラスターに Amazon Linux ノードがなく、Pod のセキュリティグループを使用する場合は、次のステップに進みます。それ以外の場合は、[クラスターのロール](cluster-iam-role.md)に `AmazonEKSVPCResourceController` マネージドポリシーがアタッチされていることを確認します。*eksClusterRole* は、自分のクラスターのロール名に置き換えてください。
```
aws iam list-attached-role-policies --role-name eksClusterRole
```
出力例は次のとおりです。
```
{
"AttachedPolicies": [
{
"PolicyName": "AmazonEKSClusterPolicy",
"PolicyArn": "arn:aws:iam::aws:policy/AmazonEKSClusterPolicy"
},
{
"PolicyName": "AmazonEKSVPCResourceController",
"PolicyArn": "arn:aws:iam::aws:policy/AmazonEKSVPCResourceController"
}
]
}
```
前の出力のようにポリシーがアタッチされている場合は、次のステップをスキップします。
1. **[AmazonEKSVPCResourceController](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSVPCResourceController.html)** マネージド型ポリシーを [Amazon EKS クラスターの IAMロール](cluster-iam-role.md)にアタッチします。*eksClusterRole* は、自分のクラスターのロール名に置き換えてください。
```
aws iam attach-role-policy \
--role-name eksClusterRole \
--policy-arn arn:aws:iam::aws:policy/AmazonEKSVPCResourceController
```
1. VPC CNI ConfigMap を更新して Windows IPAM を有効にします。Helm チャートを使用するか、Amazon EKS アドオンとして VPC CNI がクラスターにインストールされた場合、ConfigMap を直接変更できない場合がありますのでご注意ください。Amazon EKS アドオンの設定に関する詳細については、「[Amazon EKS アドオンのためにカスタマイズできるフィールドを決定する](kubernetes-field-management.md)」を参照してください。
1. 次の内容で、*vpc-resource-controller-configmap.yaml* という名前のファイルを作成します。
```
apiVersion: v1
kind: ConfigMap
metadata:
name: amazon-vpc-cni
namespace: kube-system
data:
enable-windows-ipam: "true"
```
1. `ConfigMap` をクラスターに適用する
```
kubectl apply -f vpc-resource-controller-configmap.yaml
```
1. クラスターの認証モードが `aws-auth` configmap を有効にするように設定されている場合は、次の手順を実行します。
+ `aws-auth` `ConfigMap` に、Windows ノードのインスタンスロールに `eks:kube-proxy-windows` RBAC 権限グループを含めるマッピングが含まれていることを確認します。次のコマンドを使用してインストールします。
```
kubectl get configmap aws-auth -n kube-system -o yaml
```
出力例は次のとおりです。
```
apiVersion: v1
kind: ConfigMap
metadata:
name: aws-auth
namespace: kube-system
data:
mapRoles: |
- groups:
- system:bootstrappers
- system:nodes
- eks:kube-proxy-windows # This group is required for Windows DNS resolution to work
rolearn: arn:aws:iam::111122223333:role/eksNodeRole
username: system:node:{{EC2PrivateDNSName}}
[...]
```
グループの下に `eks:kube-proxy-windows` がリストされているはずです。グループが指定されていない場合は、必要なグループを含むように `ConfigMap` を更新するか、作成する必要があります。`aws-auth` `ConfigMap`の詳細については、「[`aws-auth` `ConfigMap` をクラスターに適用する](auth-configmap.md#aws-auth-configmap)」を参照してください。
1. クラスターの認証モードが `aws-auth` configmap を無効にするように設定されている場合は、EKS アクセスエントリを使用できます。Windows インスタンスで使用する新しいノードロールを作成すると、EKS によって `EC2_WINDOWS` タイプのアクセスエントリが自動的に作成されます。
## Windows ポッドをデプロイする
クラスターにポッドをデプロイするときに、さまざまなノードタイプを混在させて実行する場合に使用するオペレーティングシステムを指定する必要があります。
Linux Pod の場合は、マニフェストで以下のノードセレクターテキストを使用します。
```
nodeSelector:
kubernetes.io/os: linux
kubernetes.io/arch: amd64
```
Windows Pod の場合は、マニフェストで以下のノードセレクターテキストを使用します。
```
nodeSelector:
kubernetes.io/os: windows
kubernetes.io/arch: amd64
```
[サンプルアプリケーション](sample-deployment.md)をデプロイして、使用されているノードセレクタを確認できます。
## Windows ノードでより高い Pod 密度をサポートする
Amazon EKS では、各 Pod に VPC の `IPv4` アドレスが割り当てられます。このため、ノード上でさらに多くの Pod を実行するのに十分なリソースがある場合でも、ノードにデプロイできる Pod の数の上限は、使用可能な IP アドレスによって制限されます。Windows ノードでサポートされる Elastic Network Interface は 1 つだけなので、デフォルトでは Windows ノードで使用できる IP アドレスの最大数は次のようになります。
```
Number of private IPv4 addresses for each interface on the node - 1
```
1 つの IP アドレスがネットワークインターフェイスのプライマリ IP アドレスとして使用されるため、Pod に割り当てることはできません。
IP プレフィックスの委任を有効にすると、Windows ノードで Pod 密度をより高めることができます。この機能により、セカンダリ `IPv4` アドレスを割り当てる代わりに、プライマリネットワークインターフェイスに `/28``IPv4` プレフィックスを割り当てることができます。IP プレフィックスを割り当てると、ノードで使用できる `IPv4` アドレスの最大数が次のように増加します。
```
(Number of private IPv4 addresses assigned to the interface attached to the node - 1) * 16
```
使用可能な IP アドレス数が大幅に増加したため、使用可能な IP アドレスによってノード上の Pod の数をスケーリングできる機能が制限されることはありません。詳細については、「[プレフィックスを使用して Amazon EKS ノードに割り当てる IP アドレスを増やす](cni-increase-ip-addresses.md)」を参照してください。