Friday, October 7, 2022
HomeSoftware EngineeringVarieties of communication in Amazon EKS

Varieties of communication in Amazon EKS


blank

There are a number of sorts of communication in Amazon EKS environments. Traces of communication embrace the next:

  • Interpod communication between containers
  • Communication between pods on the identical node or pods on completely different nodes
  • Ingress connections from exterior the cluster

In some circumstances, the default Kubernetes strategies are used. In different circumstances, particularly inter-node communication and ingress strategies particular to Amazon EKS are used.

Intrapod communication

blank

Containers in a pod share a Linux namespace and might talk with one another utilizing localhost. In Kubernetes networking, the IP tackle with which a container identifies is identical IP tackle for all entities within the community. All containers can talk with all different containers in a pod with out NAT.

Intrahost communication

blank

Along with every pod having a Linux namespace, the host node additionally has a Linux namespace. Every namespace has its personal routing desk. The pod namespace and host namespace are linked by a Linux digital Ethernet (veth) machine. A pair of veths creates a tunnel between the default host namespace and the pod namespace.

Pod-to-pod communication within the host occurs via this veth tunnel. Every node is allotted a community vary for containers and every pod will get an IP tackle in that vary permitting containers on the identical host to speak.

Interhost communication

blank

To simplify internode communication, Amazon EKS integrates Amazon VPC networking into Kubernetes via the Amazon VPC CNI plugin for Kubernetes. CNI permits Kubernetes pods to have the identical IP tackle contained in the pod as they do on the Amazon VPC community. 

This CNI plugin is an open-source venture maintained within the amazon-vpc-cni-k8s repository on GitHub. CNI makes use of the Amazon EC2 means to provision a number of community interfaces to a number occasion—every with a number of secondary IP addresses—to get a number of IP addresses assigned from the Amazon VPC pool. It then distributes these IP addresses to pods on the host and connects the community interface to the veth port created on the pod. The Linux kernel manages the remainder. Due to this fact, each pod has an actual, routable IP tackle from the Amazon VPC and might simply talk with different pods, nodes, or AWS providers.

On the host, CNI modifies each the default routing desk and the community interface routing desk. The default routing desk is used to route visitors to pods. Every community interface has its personal routing desk that’s used to route outgoing pod visitors. Every pod is assigned one of many community interface’s secondary IP addresses. For instance, if a pod sends community visitors out of the occasion, the VPC-CNI plugin ensures that the visitors routes via the proper community interface.

RELATED ARTICLES

LEAVE A REPLY

Please enter your comment!
Please enter your name here

Most Popular

Recent Comments