Types of Communication in Amazon EKS


There are multiple types of communication in Amazon EKS environments. Lines of communication include the following:

  • Interpod communication between containers
  • Communication between pods on the same node or pods on different nodes
  • Ingress connections from outside the cluster

In some cases, the default Kubernetes methods are used. In other cases, specifically inter-node communication and ingress methods specific to Amazon EKS are used.

Intrapod communication

Containers in a pod share a Linux namespace and can communicate with each other using localhost. In Kubernetes networking, the IP address with which a container identifies is the same IP address for all entities in the network. All containers can communicate with all other containers in a pod without NAT.

Intrahost communication

In addition to each pod having a Linux namespace, the host node also has a Linux namespace. Each namespace has its own routing table. The pod namespace and host namespace are connected by a Linux virtual Ethernet (veth) device. A pair of veths creates a tunnel between the default host namespace and the pod namespace.

Pod-to-pod communication in the host happens through this veth tunnel. Each node is allocated a network range for containers and each pod gets an IP address in that range allowing containers on the same host to communicate.

Interhost communication

To simplify internode communication, Amazon EKS integrates Amazon VPC networking into Kubernetes through the Amazon VPC CNI plugin for Kubernetes. CNI allows Kubernetes pods to have the same IP address inside the pod as they do on the Amazon VPC network. 

This CNI plugin is an open-source project maintained in the amazon-vpc-cni-k8s repository on GitHub. CNI uses the Amazon EC2 ability to provision multiple network interfaces to a host instance—each with multiple secondary IP addresses—to get multiple IP addresses assigned from the Amazon VPC pool. It then distributes these IP addresses to pods on the host and connects the network interface to the veth port created on the pod. The Linux kernel manages the rest. Therefore, every pod has a real, routable IP address from the Amazon VPC and can easily communicate with other pods, nodes, or AWS services.

At the host, CNI modifies both the default routing table and the network interface routing table. The default routing table is used to route traffic to pods. Each network interface has its own routing table that is used to route outgoing pod traffic. Each pod is assigned one of the network interface’s secondary IP addresses. For example, if a pod sends network traffic out of the instance, the VPC-CNI plugin ensures that the traffic routes through the correct network interface.