Container Network Interface (CNI) in Kubernetes

What is Container Network Interface (CNI)?

Container Network Interface (CNI) in kubernetes functions similarly to a networking manager for containers. CNI enables containers to communicate with one another and with the outside world in the same way that a manager enables employees in a company to communicate and connect.

Consider organizing a large conference with attendees from various companies. You hire a networking coordinator to ensure that attendees communicate and connect smoothly. This coordinator is analogous to the CNI manager in Kubernetes.

The CNI Kubernetes plugin of the cluster configures the network settings when a container is created in a Kubernetes cluster. This process includes assigning IP addresses, configuring network interfaces, defining routing rules, and implementing network policies.

The implementation and functionality of CNI plugins can differ. Some plugins focus on overlay networking, which creates virtual networks that span multiple hosts. Others offer advanced capabilities such as network security, policy enforcement, and observability.

Container runtimes and networking plugins that adhere to the CNI in Kubernetes specification can work together seamlessly regardless of the underlying network infrastructure. This enables organizations to select the networking solution that best meets their requirements while ensuring consistent network connectivity and container management.

Overall, CNI Kubernetes plays an important role in simplifying and standardizing Kubernetes container networking by providing a unified approach to network configuration, management, and policy enforcement within containerized environments.

Networking in Kubernetes

Before jumping directly into the types of Kubernetes networking let's understand the diagram.

The network interfaces in a Kubernetes cluster are controlled by the underlying infrastructure and are not directly accessible or programmable from a container or pod.

The first Ethernet network interface on a Linux system is commonly referred to as eth0. However, in a Kubernetes environment, the names of the network interfaces inside the pods are dynamically assigned and vary depending on the CNI (Container Network Interface) plugin used, for example, eth0, eth1, or ethX.

Kubernetes offers a more abstract and portable networking model using Services and DNS names as opposed to referring to network interfaces by their names. By using a consistent DNS name, services enable you to expose applications running inside a pod to other pods or external clients.

You could, for instance, use a Service to expose a pod that is running a web server so that other pods or nodes can access it by using the Service DNS name. Without having to worry about the underlying network interfaces, Kubernetes will route the network traffic automatically.

Kubernetes networking allows for communication between Kubernetes components as well as between Kubernetes components and external applications. The Kubernetes platform, with its flat network layout that avoids the need to map ports across containers, provides a unique solution to share virtual machines between applications and run distributed systems without dynamically allocated ports.

1. Pod Networking:
   Pods are the basic units of deployment in Kubernetes. Each pod gets its unique IP address, allowing direct communication between pods within the cluster. Pod networking ensures that pods can communicate with each other seamlessly, enabling the building blocks of microservices architectures.

2. Service Networking:
   Services provide a stable endpoint for accessing a group of pods that perform the same function. Services have their IP address, referred to as a Cluster IP, which acts as a single entry point for accessing the pods behind the service. Service networking enables load balancing and service discovery, allowing applications to scale.

Why Use CNI in Kubernetes?

CNI (Container Network Interface) in Kubernetes is a standardized interface between container runtimes and networking plugins. For containerized environments, it provides a consistent and pluggable networking model. CNI is used in Kubernetes for the following reasons:

1. Flexibility:
   Kubernetes CNI provides Kubernetes users with the flexibility and choice to select from a variety of networking plugins that best meet their infrastructure requirements and networking standards. Overlay networking, network security, and connection with existing network infrastructure are all provided by different CNI plugins.
2. Seamless Integration:
   Kubernetes CNI enables the seamless integration of networking solutions with container runtimes. It defines a standardized interface for container runtimes (such as Docker and containerd) to use when interacting with networking plugins. This makes it easier to deploy and manage networking configurations in Kubernetes clusters.
3. Container Portability:
   With CNI in Kubernetes, containers and pods can be moved between Kubernetes clusters or platforms without requiring changes to the networking configuration. The use of a standardized interface ensures that networking configurations remain consistent across different environments.
4. Extensibility & Simplicity:
   Because CNI is expandable, if necessary, you may develop your network plugins. This allows you the freedom to modify Kubernetes networking to suit your unique needs. CNI is made to be easy to use and administer. This makes installing and configuring Kubernetes networking simple.

Different Kubernetes Plugins and Their Need

1. Calico:
   Calico is a highly scalable and adaptable CNI plugin for Kubernetes clusters that provides networking and network policy enforcement. It provides fine-grained network policies for securing pod-to-pod communication and supports both IP-in-IP and VXLAN encapsulation for overlay networking.

2. Flannel:
   Flannel is a simple and lightweight CNI for kubernetes for container communication in Kubernetes clusters that uses an overlay network. It is known for its ease of deployment and configuration and supports a variety of backends, including VXLAN, host-gw, and AWS VPC.

3. Cilium:
   Cilium is a Kubernetes CNI plugin that provides enhanced networking and security capabilities for Kubernetes clusters. It takes advantage of Linux kernel capabilities like BPF (Berkeley Packet Filter) to provide high-performance packet filtering, load balancing, and network visibility at scale.

Network Models Used in Kubernetes

There are various networking methods in Kubernetes for facilitating communication between pods, including pod-to-pod networking, pod-to-service networking, and external communication. Let's take a closer look at these networking models:

1. Pod-to-Pod Communication:

• The primary networking model of Kubernetes is pod-to-pod networking.
• Each Kubernetes pod has its IP address and can connect with other pods in the same cluster.
• Pod-to-pod communication is possible by utilizing the IP address of the sending pod and the port on which the receiving pod is listening.
• This networking topology offers seamless communication between application components running in distinct pods.

2. Pod-to-Service Networking:

• Kubernetes introduces the concept of services to provide a stable endpoint for accessing a group of pods.
• Services act as an abstraction layer, allowing clients to access a logical service rather than individual pods.
• When a service is created, Kubernetes assigns it a Cluster IP, which serves as a stable virtual IP address for accessing the service.
• Requests made to the service's Cluster IP are automatically load-balanced to the underlying pods associated with the service.
• Pod-to-service networking allows pods to communicate with services within the same cluster, abstracting away the complexity of individual pod addresses and providing service discovery and load balancing.

3. External Communication:

• Kubernetes provides the ability for pods and services to communicate with resources outside of the cluster.
• Typically, each node in the cluster is assigned an external IP address that can be used for external communication.
• Kubernetes has several methods for externally exposing services, including NodePort, LoadBalancer, and Ingress.
• NodePort enables a service to be exposed across all nodes through a static port.
• LoadBalancer configures an external load balancer (for example, a cloud provider load balancer) to distribute traffic to the service.
• Ingress allows you to route external traffic to services depending on a variety of rules and configurations.

Kubernetes Networking with Calico

Calico's integration with Kubernetes offers strong networking and network policy features. Each pod is given a distinct IP address by Calico's flat, non-overlay networking paradigm, enabling direct communication. Due to its smooth integration with Kubernetes Network Policies, fine-grained access control is made possible. Within Kubernetes clusters, Calico guarantees scalability and high performance, streamlines network configuration, and improves security. For effective routing, it makes use of common Linux networking components and protocols. With Calico, enterprises can achieve durable, secure, and efficient networking for their containerized workloads in Kubernetes.