AWS eks documentation change
Summary
Formatting improvements and clarifications in network flow documentation: added backticks around IPs/CIDRs, fixed typos, improved sentence structure, and standardized AWS references. Added explicit mention of DNAT (Destination Network Address Translation) in iptables processing.
Security assessment
Changes are primarily documentation clarifications and formatting improvements. While DNAT explanation adds technical detail about network translation, this is a standard networking concept rather than addressing a specific security vulnerability. No evidence of security patches, vulnerability disclosures, or new security controls being documented.
Diff
diff --git a/eks/latest/userguide/hybrid-nodes-concepts-traffic-flows.md b/eks/latest/userguide/hybrid-nodes-concepts-traffic-flows.md index 2a11b0e07..13d370c53 100644 --- a//eks/latest/userguide/hybrid-nodes-concepts-traffic-flows.md +++ b//eks/latest/userguide/hybrid-nodes-concepts-traffic-flows.md @@ -13 +13,3 @@ To contribute to this user guide, choose the **Edit this page on GitHub** link t -This page details the network traffic flows for EKS Hybrid Nodes with diagrams showing the end-to-end network paths for the different traffic types. The following traffic flows are covered: +This page details the network traffic flows for EKS Hybrid Nodes with diagrams showing the end-to-end network paths for the different traffic types. + +The following traffic flows are covered: @@ -40 +42 @@ When the `kubelet` on a hybrid node needs to communicate with the EKS control pl -The `kubelet` performs a DNS lookup for the endpoint (e.g., ` [https://xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.gr7.us-west-2.eks.amazonaws.com](https://xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.gr7.us-west-2.eks.amazonaws.com) `). In a public access cluster, this resolves to a public IP address (say `54.239.118.52`) that belongs to the EKS service running in {aws}. The `kubelet` then creates a secure HTTPS request to this endpoint. The initial packet looks like this: +The `kubelet` performs a DNS lookup for the endpoint (for example, ` [https://xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.gr7.us-west-2.eks.amazonaws.com](https://xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.gr7.us-west-2.eks.amazonaws.com) `). In a public access cluster, this resolves to a public IP address (say `54.239.118.52`) that belongs to the EKS service running in AWS. The `kubelet` then creates a secure HTTPS request to this endpoint. The initial packet looks like this: @@ -57 +59 @@ For public traffic, the router typically forwards the packet to an internet gate -The packet travels across the public internet and transit networks until it reaches {aws}'s network. {aws}'s network routes the packet to the EKS service endpoint in the appropriate region. When the packet reaches the EKS service, it’s forwarded to the actual EKS control plane for your cluster. +The packet travels across the public internet and transit networks until it reaches AWS's network. AWS's network routes the packet to the EKS service endpoint in the appropriate region. When the packet reaches the EKS service, it’s forwarded to the actual EKS control plane for your cluster. @@ -67 +69 @@ After the EKS control plane processes the `kubelet` request, it sends a response -The EKS control plane creates a response packet with its public IP as the source and the hybrid node’s IP as the destination: +The EKS control plane creates a response packet. This packet has the public IP as the source and the hybrid node’s IP as the destination: @@ -82 +84 @@ The response packet travels back through the internet, following the routing pat -Your on-premises router receives the packet and recognizes the destination IP (10.80.0.2) as belonging to your local network. It forwards the packet through your local network infrastructure until it reaches the target hybrid node, where the `kubelet` receives and processes the response. +Your on-premises router receives the packet and recognizes the destination IP (`10.80.0.2`) as belonging to your local network. It forwards the packet through your local network infrastructure until it reaches the target hybrid node, where the `kubelet` receives and processes the response. @@ -86 +88 @@ Your on-premises router receives the packet and recognizes the destination IP (1 -The traffic originated from the `kube-proxy` on the hybrid node to the EKS control plane follows the same path as the traffic from the `kubelet` to the EKS control plane by using the public internet (if you enable public endpoint access for the cluster). +If you enable public endpoint access for the cluster, the return traffic uses the public internet. This traffiic originates from the `kube-proxy` on the hybrid node to the EKS control plane and follows the same path as the traffic from the `kubelet` to the EKS control plane. @@ -96 +98 @@ The traffic originated from the `kube-proxy` on the hybrid node to the EKS contr -The EKS Kubernetes API server retrieves the node’s IP address (10.80.0.2) from the node object’s status. It then routes this request through its ENI in the VPC, as the destination IP belongs to the configured remote node CIDR (10.80.0.0/16). The initial packet looks like this: +The EKS Kubernetes API server retrieves the node’s IP address (`10.80.0.2`) from the node object’s status. It then routes this request through its ENI in the VPC, as the destination IP belongs to the configured remote node CIDR (`10.80.0.0/16`). The initial packet looks like this: @@ -123 +125 @@ The packet arrives at your local on-premises router that handles traffic for the -The local router identifies that the destination IP (10.80.0.2) address belongs to its directly connected network and forwards the packet directly to the target hybrid node, where the `kubelet` receives and processes the request. +The local router identifies that the destination IP (`10.80.0.2`) address belongs to its directly connected network and forwards the packet directly to the target hybrid node, where the `kubelet` receives and processes the request. @@ -138 +140 @@ After the hybrid node’s `kubelet` processes the request, it sends back a respo -The `kubelet` on the hybrid node (10.80.0.2) creates a response packet with the original source IP as the destination. The destination doesn’t belong to the local network so its sent to the host’s default gateway, which is the local router. +The `kubelet` on the hybrid node (`10.80.0.2`) creates a response packet with the original source IP as the destination. The destination doesn’t belong to the local network so its sent to the host’s default gateway, which is the local router. @@ -142 +144 @@ The `kubelet` on the hybrid node (10.80.0.2) creates a response packet with the -The router determines that the destination IP (10.0.0.132) belongs to 10.0.0.0/16, which has a route pointing to the gateway connecting to {aws}. +The router determines that the destination IP (`10.0.0.132`) belongs to `10.0.0.0/16`, which has a route pointing to the gateway connecting to AWS. @@ -154 +156 @@ When the packet arrives in the VPC, the route tables identify that the destinati -The VPC networking layer forwards the packet to the subnet with the EKS control plane ENI (10.0.0.132). +The VPC networking layer forwards the packet to the subnet with the EKS control plane ENI (`10.0.0.132`). @@ -191 +193 @@ The packet enters the node’s network stack where `netfilter` hooks trigger the - 2. The matching rule jumps to the `KUBE-SVC-XXX` chain for the `kubernetes` service (packets destined for `172.16.0.1:443`), which contains load balancing rules. `kubernetes` service (packets destined for `172.16.0.1:443`), which has load balancing rules. + 2. The matching rule jumps to the `KUBE-SVC-XXX` chain for the `kubernetes` service (packets destined for `172.16.0.1:443`), which contains load balancing rules. @@ -195 +197 @@ The packet enters the node’s network stack where `netfilter` hooks trigger the - 4. The selected `KUBE-SEP-XXX` chain has the actual DNAT rule that changes the destination IP from the service IP to the selected IP. + 4. The selected `KUBE-SEP-XXX` chain has the actual rule that changes the destination IP from the service IP to the selected IP. This is called Destination Network Address Translation (DNAT). @@ -213 +215 @@ The node forwards the packet to its default gateway because the destination IP i -The local router determines that the destination IP (10.0.0.132) belongs to the VPC CIDR (10.0.0.0/16) and forwards it to the gateway connecting to {aws}. +The local router determines that the destination IP (`10.0.0.132`) belongs to the VPC CIDR (`10.0.0.0/16`) and forwards it to the gateway connecting to AWS. @@ -221 +223 @@ The packet travels through your established connection (such as Direct Connect o -The VPC networking layer routes the packet to the correct subnet where the EKS control plane ENI (10.0.0.132) is located. +The VPC networking layer routes the packet to the correct subnet where the EKS control plane ENI (`10.0.0.132`) is located. @@ -242 +244 @@ The EKS Kubernetes API server creates a response packet with the original source -Because the destination IP belongs to the configured remote pod CIDR (10.85.0.0/16), it sends it through its ENI in the VPC with the subnet’s router as the next hop. +Because the destination IP belongs to the configured remote pod CIDR (`10.85.0.0/16`), it sends it through its ENI in the VPC with the subnet’s router as the next hop. @@ -246 +248 @@ Because the destination IP belongs to the configured remote pod CIDR (10.85.0.0/ -The VPC route table contains an entry for the remote pod CIDR (10.85.0.0/16), directing this traffic to the VPC-to-onprem gateway. +The VPC route table contains an entry for the remote pod CIDR (`10.85.0.0/16`), directing this traffic to the VPC-to-onprem gateway. @@ -262 +264 @@ The router’s table has an entry for `10.85.1.0/24` with `10.80.0.2` as the nex -As the packet is processed by the node’s network stack, `conntrack` (a part of `netfilter`) matches the packet with the connection the pod initially establish and since DNAT was originally applied, it reverses this by rewriting the source IP from the EKS control plane ENI’s IP to the `kubernetes` service IP: +As the packet is processed by the node’s network stack, `conntrack` (a part of `netfilter`) matches the packet with the connection the pod initially establish. Since DNAT was originally applied, `conntrack` reverses the DNAT by rewriting the source IP from the EKS control plane ENI’s IP to the `kubernetes` service IP: @@ -322 +324 @@ The node forwards the packet to its default gateway because the destination IP i -The local router determines that the destination IP (10.0.0.132) belongs to the VPC CIDR (10.0.0.0/16) and forwards it to the gateway connecting to {aws}. +The local router determines that the destination IP (`10.0.0.132`) belongs to the VPC CIDR (`10.0.0.0/16`) and forwards it to the gateway connecting to AWS. @@ -330 +332 @@ The packet travels through your established connection (such as Direct Connect o -The VPC networking layer routes the packet to the correct subnet where the EKS control plane ENI (10.0.0.132) is located. +The VPC networking layer routes the packet to the correct subnet where the EKS control plane ENI (`10.0.0.132`) is located. @@ -351 +353 @@ The EKS Kubernetes API server creates a response packet with the original source -Because the destination IP belongs to the configured remote node CIDR (10.80.0.0/16), it sends it through its ENI in the VPC with the subnet’s router as the next hop. +Because the destination IP belongs to the configured remote node CIDR (`10.80.0.0/16`), it sends it through its ENI in the VPC with the subnet’s router as the next hop. @@ -355 +357 @@ Because the destination IP belongs to the configured remote node CIDR (10.80.0.0 -The VPC route table contains an entry for the remote node CIDR (10.80.0.0/16), directing this traffic to the VPC-to-onprem gateway. +The VPC route table contains an entry for the remote node CIDR (`10.80.0.0/16`), directing this traffic to the VPC-to-onprem gateway. @@ -367 +369 @@ The packet arrives at your local on-premises router. -The local router identifies that the destination IP (10.80.0.2) address belongs to its directly connected network and forwards the packet directly to the target hybrid node. +The local router identifies that the destination IP (`10.80.0.2`) address belongs to its directly connected network and forwards the packet directly to the target hybrid node. @@ -407 +409 @@ When a webhook is configured in the cluster and a relevant API operation trigger -Assuming the webhook pod is running on a hybrid node with IP 10.85.1.23, the EKS Kubernetes API server creates an HTTPS request to the webhook endpoint. The initial packet is sent through the EKS control plane ENI in your VPC because the destination IP 10.85.1.23 belongs to the configured remote pod CIDR (10.85.0.0/16). The packet looks like this: +Assuming the webhook pod is running on a hybrid node with IP `10.85.1.23`, the EKS Kubernetes API server creates an HTTPS request to the webhook endpoint. The initial packet is sent through the EKS control plane ENI in your VPC because the destination IP `10.85.1.23` belongs to the configured remote pod CIDR (`10.85.0.0/16`). The packet looks like this: @@ -422 +424 @@ The packet leaves the EKS control plane ENI and enters the VPC networking layer -The VPC route table for the subnet containing the EKS control plane ENI contains a specific route for the remote pod CIDR (10.85.0.0/16). This routing rule directs the packet to the VPC-to-onprem gateway (for example, a Virtual Private Gateway for Direct Connect or VPN connections): +The VPC route table for the subnet containing the EKS control plane ENI contains a specific route for the remote pod CIDR (`10.85.0.0/16`). This routing rule directs the packet to the VPC-to-onprem gateway (for example, a Virtual Private Gateway for Direct Connect or VPN connections): @@ -437 +439 @@ The packet arrives at your local on-premises router. The router consults its rou -In this case, the router’s route table contains an entry indicating that the 10.85.1.0/24 subnet is reachable via the hybrid node with IP 10.80.0.2: +In this case, the router’s route table contains an entry indicating that the `10.85.1.0/24` subnet is reachable through the hybrid node with IP `10.80.0.2`: @@ -445 +447 @@ In this case, the router’s route table contains an entry indicating that the 1 -Based on the routing table entry, the router forwards the packet to the hybrid node (10.80.0.2). When the packet arrives at the node, it looks the same as when the EKS Kubernetes API server sent it, with the destination IP still being the pod’s IP. +Based on the routing table entry, the router forwards the packet to the hybrid node (`10.80.0.2`). When the packet arrives at the node, it looks the same as when the EKS Kubernetes API server sent it, with the destination IP still being the pod’s IP. @@ -471 +473 @@ The webhook pod creates a response packet with its own IP as the source and the -The CNI identifies that this packet is destined for an external network (not a local pod). If the CNI passes the packet to the node’s network stack with the original source IP preserved. +The CNI identifies that this packet goes to an external network (not a local pod). If the CNI passes the packet to the node’s network stack with the original source IP preserved. @@ -475 +477 @@ The CNI identifies that this packet is destined for an external network (not a l -The node determines that the destination IP (10.0.0.132) is not in the local network and forwards the packet to its default gateway (the local router). +The node determines that the destination IP (`10.0.0.132`) is not in the local network and forwards the packet to its default gateway (the local router). @@ -479 +481 @@ The node determines that the destination IP (10.0.0.132) is not in the local net -The local router consults its routing table and determines that the destination IP (10.0.0.132) belongs to the VPC CIDR (10.0.0.0/16). It forwards the packet to the gateway connecting to {aws}. +The local router consults its routing table and determines that the destination IP (`10.0.0.132`) belongs to the VPC CIDR (`10.0.0.0/16`). It forwards the packet to the gateway connecting to AWS. @@ -489 +491 @@ When the packet arrives in the VPC, the route tables identify that the destinati -**2 & 1\. EKS control plane ENI Reception** +**2\. and 1. EKS control plane ENI Reception** @@ -508 +510 @@ This traffic flow demonstrates why remote pod CIDRs must be properly configured -This section explains how pods running on different hybrid nodes communicate with each other. This example assumes your CNI uses VXLAN for encapsulation, which is common for CNIs such as Cilium or Calico. The overall process is similar for other encapsulation protocols such as `Geneve` or IP-in-IP. +This section explains how pods running on different hybrid nodes communicate with each other. This example assumes your CNI uses VXLAN for encapsulation, which is common for CNIs such as Cilium or Calico. The overall process is similar for other encapsulation protocols such as Geneve or IP-in-IP. @@ -514 +516 @@ This section explains how pods running on different hybrid nodes communicate wit -Pod A (10.85.1.56) on Node 1 wants to send traffic to Pod B (10.85.2.67) on Node 2. The initial packet looks like this: +Pod A (`10.85.1.56`) on Node 1 wants to send traffic to Pod B (`10.85.2.67`) on Node 2. The initial packet looks like this: @@ -525 +527 @@ Pod A (10.85.1.56) on Node 1 wants to send traffic to Pod B (10.85.2.67) on Node -When Pod A’s packet leaves its network namespace, the CNI intercepts it. The CNI consults its routing table and determines: - The destination IP (10.85.2.67) belongs to the pod CIDR - This IP is not on the local node but belongs to Node 2 (10.80.0.3) - The packet needs to be encapsulated with VXLAN. +When Pod A’s packet leaves its network namespace, the CNI intercepts it. The CNI consults its routing table and determines: - The destination IP (`10.85.2.67`) belongs to the pod CIDR - This IP is not on the local node but belongs to Node 2 (`10.80.0.3`) - The packet needs to be encapsulated with VXLAN. @@ -538 +540 @@ The CNI encapsulates the entire original packet inside a VXLAN frame. This effec -Key points about this encapsulation: - The outer packet is addressed from Node 1 (10.80.0.2) to Node 2 (10.80.0.3) - UDP port 8472 is the VXLAN port Cilium uses by default - The VXLAN Network Identifier (VNI) identifies which overlay network this packet belongs to - The entire original packet (with Pod A’s IP as source and Pod B’s IP as destination) is preserved intact inside +Key points about this encapsulation: - The outer packet is addressed from Node 1 (`10.80.0.2`) to Node 2 (`10.80.0.3`) - UDP port `8472` is the VXLAN port Cilium uses by default - The VXLAN Network Identifier (VNI) identifies which overlay network this packet belongs to - The entire original packet (with Pod A’s IP as source and Pod B’s IP as destination) is preserved intact inside @@ -540 +542 @@ Key points about this encapsulation: - The outer packet is addressed from Node 1 -The encapsulated packet now enters the regular networking stack of Node 1 and is processed like any other packet: +The encapsulated packet now enters the regular networking stack of Node 1 and is processed in the same way as any other packet: @@ -542 +544 @@ The encapsulated packet now enters the regular networking stack of Node 1 and is - 1. **Node Network Processing** : Node 1’s network stack routes the packet based on its destination (10.80.0.3) + 1. **Node Network Processing** : Node 1’s network stack routes the packet based on its destination (`10.80.0.3`) @@ -557 +559 @@ The encapsulated packet now enters the regular networking stack of Node 1 and is -When the encapsulated packet arrives at Node 2 (10.80.0.3): +When the encapsulated packet arrives at Node 2 (`10.80.0.3`): @@ -559 +561 @@ When the encapsulated packet arrives at Node 2 (10.80.0.3): - 1. The node’s network stack receives it and identifies it as a VXLAN packet (UDP port 4789) + 1. The node’s network stack receives it and identifies it as a VXLAN packet (UDP port `4789`) @@ -586 +588 @@ The CNI on Node 2 processes the VXLAN packet: -The CNI on Node 2 examines the destination IP (10.85.2.67) and: +The CNI on Node 2 examines the destination IP (`10.85.2.67`) and: @@ -601 +603 @@ When Pod B responds to Pod A, the entire process happens in reverse: - 1. Pod B sends a packet to Pod A (10.85.1.56) + 1. Pod B sends a packet to Pod A (`10.85.1.56`) @@ -603 +605 @@ When Pod B responds to Pod A, the entire process happens in reverse: - 2. Node 2’s CNI encapsulates it with VXLAN, setting the destination to Node 1 (10.80.0.2) + 2. Node 2’s CNI encapsulates it with VXLAN, setting the destination to Node 1 (`10.80.0.2`) @@ -620 +622 @@ When Pod B responds to Pod A, the entire process happens in reverse: -Pod A (10.0.0.56) on the EC2 Node wants to send traffic to Pod B (10.85.1.56) on the Hybrid Node. The initial packet looks like this: +Pod A (`10.0.0.56`) on the EC2 Node wants to send traffic to Pod B (`10.85.1.56`) on the Hybrid Node. The initial packet looks like this: @@ -633 +635 @@ With the VPC CNI, Pod A has an IP from the VPC CIDR and is directly attached to -The VPC route table contains a specific route for the Remote Pod CIDR (10.85.0.0/16), directing this traffic to the VPC-to-onprem gateway: +The VPC route table contains a specific route for the Remote Pod CIDR (`10.85.0.0/16`), directing this traffic to the VPC-to-onprem gateway: @@ -650 +652 @@ The packet arrives at your local on-premises router. The router consults its rou -The router’s table contains an entry indicating that the 10.85.1.0/24 subnet is reachable via the hybrid node with IP 10.80.0.2: +The router’s table has an entry indicating that the `10.85.1.0/24` subnet is reachable through the hybrid node with IP `10.80.0.2`: @@ -658 +660 @@ The router’s table contains an entry indicating that the 10.85.1.0/24 subnet i -The router forwards the packet to the Hybrid Node (10.80.0.2). When the packet arrives at the node, it still has Pod A’s IP as the source and Pod B’s IP as the destination. +The router forwards the packet to the hybrid node (`10.80.0.2`). When the packet arrives at the node, it still has Pod A’s IP as the source and Pod B’s IP as the destination. @@ -686 +688 @@ The CNI identifies that this packet is destined for an external network and pass -The node determines that the destination IP (10.0.0.56) does not belong to the local network and forwards the packet to its default gateway (the local router). +The node determines that the destination IP (`10.0.0.56`) does not belong to the local network and forwards the packet to its default gateway (the local router). @@ -690 +692 @@ The node determines that the destination IP (10.0.0.56) does not belong to the l -The local router consults its routing table and determines that the destination IP (10.0.0.56) belongs to the VPC CIDR (10.0.0.0/16). It forwards the packet to the gateway connecting to {aws}. +The local router consults its routing table and determines that the destination IP (`10.0.0.56`) belongs to the VPC CIDR (`10.0.0.0/16`). It forwards the packet to the gateway connecting to AWS. @@ -721 +723 @@ Kubernetes concepts -Troubleshooting +Hybrid nodes nodeadm