Limitations of using Windows Nodes with EKS Cluster

The following are the limitations of using Windows nodes with the EKS cluster:

  • Amazon EC2 instance types C3, C4, D2, I2, M4 (excluding m4.16xlarge), M6a.x, and R3 instances are not supported for Windows workloads.
  • Host networking mode is not supported for Windows workloads.
  • Amazon EKS clusters must contain one or more Linux or Fargate nodes to run core system pods that only run on Linux, such as CoreDNS.
  • You cannot use Security groups for pods with pods running on Windows nodes.
  • You cannot use custom networking with Windows nodes.
  • You cannot use IP prefixes with Windows nodes. This is a requirement for using IPv6, so you cannot use IPv6 with Windows nodes either.
  • Windows nodes support one elastic network interface per node. The number of pods that you can run per Windows node is equal to the number of IP addresses available per elastic network interface for the node's instance type, minus one.
  • In an Amazon EKS cluster, a single service with a load balancer can support up to 1024 back-end pods. Each pod has its own unique IP address.
  • You cannot deploy Windows managed nodes. You can only create self-managed Windows nodes.
  • Windows containers are not supported for Amazon EKS pods on Fargate.
  • You cannot retrieve logs from the vpc-resource-controller pod. Earlier, you could do this if you had deployed the controller to the data plane.
  • There is a cool down period before an IPv4 address is assigned to a new Pod. This prevents traffic from flowing to an older Pod with the same IPv4 address due to stale kube-proxy rules.
  • The kubelet and kube-proxy event logs are redirected to the EKS Windows Event Log and are set to a 200 MB limit.