In this post, following the principles of Kubernetes Architecture, we will explore four different types of communication and networking within K8S.

Network Challenges

During the monolithic era of applications, all business logic was contained within the same application and network. With the advent of microservices, this logic becomes decoupled, and to maintain some level of “coupling,” networks and communication become essential. Network creation usually presents complications and can be challenging to understand and implement, and Kubernetes is no exception. To address this, we will discuss four different network challenges:

1. Container-to-container communication within Pods.
2. Pod-to-Pod communication within the same node and across cluster nodes.
3. Pod-to-Service communication within the same namespace and across cluster namespaces.
4. External communication to services, allowing clients to access applications within a cluster.

Container-to-Container Communication within Pods

The operating system uses its features to create an isolated network namespace for each container at runtime. Containers or the host OS share this network namespace.

When a Pod starts, a namespace is created within the Pod, and all containers within the Pod share that namespace, enabling them to communicate with each other via localhost.

Pod-to-Pod Communication

In Kubernetes clusters, Pods are scheduled on random nodes. Pods can communicate with other Pods in the cluster without needing Network Address Translation (NAT), regardless of their nodes.. This is a fundamental requirement of any Kubernetes networking implementation.

Kubernetes’ network model aims to reduce complexity and treats Pods as virtual machines on a network. Each VM, or in this case, each Pod, is assigned an IP address, following the “IP-per-Pod” model. This ensures Pod-to-Pod communication, similar to how virtual machines can communicate with each other.

Containers share the Pod’s network namespace and must coordinate port allocation within the Pod, just like applications on a VM would. They communicate with each other via localhost within the Pod. However, containers integrate with the overall Kubernetes network model using the Container Network Interface (CNI), supported by CNI plugins. CNI is a set of specifications and libraries that allow plugins to configure container networking. Most CNI plugins are third-party software-defined networking (SDN) solutions that implement the Kubernetes network model. In addition to addressing the fundamental requirement of the network model, some network solutions offer support for network policies. Flannel, Weave, and Calico are just a few SDN solutions available for Kubernetes clusters.

Pod-to-External Communication

Successfully deployed applications within a Pod in a Kubernetes cluster need to be accessible from the outside. Kubernetes enables this accessibility by enabling a series of services that encapsulate network rules within the node cluster. Services are exposed externally thanks to Kube-proxy.

Conclusion

In this post, we provided an overview of communication and networking in the Kubernetes Architecture. In the next post, we will dive deeper and explore the different types of Kubernetes objects.