Skip to content

Commit

Permalink
Merge pull request #391 from dumlutimuralp/master
Browse files Browse the repository at this point in the history
Update on cluster subnet recommendation
  • Loading branch information
jicowan authored Sep 26, 2023
2 parents 7d8df9c + 6d4102a commit 85eb7ab
Showing 1 changed file with 3 additions and 1 deletion.
4 changes: 3 additions & 1 deletion content/networking/subnets/index.md
Original file line number Diff line number Diff line change
Expand Up @@ -64,7 +64,9 @@ Amazon EKS clusters support both IPv4 and IPv6. By default, EKS clusters use IPv

Amazon EKS recommends you use at least two subnets that are in different Availability Zones during cluster creation. The subnets you pass in during cluster creation are known as cluster subnets. When you create a cluster, Amazon EKS creates up to 4 cross account (x-account or x-ENIs) ENIs in the subnets that you specify. The x-ENIs are always deployed and are used for cluster administration traffic such as log delivery, exec, and proxy. Please refer to the EKS user guide for complete [VPC and subnet requirement](https://docs.aws.amazon.com/eks/latest/userguide/network_reqs.html#network-requirements-subnets) details.

Kubernetes worker nodes can run in the cluster subnets, but it is not recommended. You can create new subnets dedicated to run nodes and any Kubernetes resources. Nodes can run in either a public or a private subnet. Whether a subnet is public or private refers to whether traffic within the subnet is routed through an [internet gateway](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html). Public subnets have a route table entry to the internet through the internet gateway, but private subnets don't.
Kubernetes worker nodes can run in the cluster subnets, but it is not recommended. During [cluster upgrades](https://aws.github.io/aws-eks-best-practices/upgrades/#verify-available-ip-addresses) Amazon EKS provisions additional ENIs in the cluster subnets. When your cluster scales out, worker nodes and pods may consume the available IPs in the cluster subnet. Hence in order to make sure there are enough available IPs you might want to consider using dedicated cluster subnets with /28 netmask.

Kubernetes worker nodes can run in either a public or a private subnet. Whether a subnet is public or private refers to whether traffic within the subnet is routed through an [internet gateway](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html). Public subnets have a route table entry to the internet through the internet gateway, but private subnets don't.

The traffic that originates somewhere else and reaches your nodes is called *ingress*. Traffic that originates from the nodes and leaves the network is called *egress*. Nodes with public or elastic IP addresses (EIPs) within a subnet configured with an internet gateway allow ingress from outside of the VPC. Private subnets usually include a [NAT gateway](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html), which only allows ingress traffic to the nodes from within the VPC while still allowing traffic *from* the nodes to leave the VPC (*egress*).

Expand Down

0 comments on commit 85eb7ab

Please sign in to comment.