Kubernetes is built to run distributed systems over a cluster of machines. Kubernetes networking allows Kubernetes components to communicate with each other and with other applications such as communication between pods, containers, services, and external services. This nature of Kubernetes makes networking a necessary component of Kubernetes deployment, and with the understanding of the Kubernetes networking model, we can run, monitor, and troubleshoot the applications.

What is Kubernetes Networking?

Kubernetes networking allows Kubernetes components like Pods, containers, API server, etc. to communicate with each other. The Kubernetes platform is different from other networking platforms because it is based on a flat network structure that eliminates the need to map host ports to container ports. The Kubernetes platform provides a way to run distributed systems, sharing machines between applications without dynamically allocating the ports. The dynamic port allocation brings a lot of complications to the system.

Check out: Certified Kubernetes Administrator (CKA). A Kubernetes certification makes your resume look good and stand out from the competition. As companies rely more and more on Kubernetes, your expertise will be an immediate asset.

Common CNI Plugins for Kubernetes

Container Network Interface (CNI) is a Cloud Native Computing Foundation project. It consists of a specification and libraries for writing plugins to configure network interfaces in Linux containers, along with a number of plugins. CNI concerns itself only with network connectivity of containers and removing allocated resources when the container is deleted. Kubernetes uses CNI as an interface between network providers and Kubernetes pod networking.

Some common CNI used are:

  • Flannel—an open-source network fabric designed for k8s. Flannel operates through a binary agent on each of your hosts. This agent allocates subnet leases to hosts and uses etcd to store configuration data.
  • Project Calico—an open-source networking provider and policy engine. Calico enables you to create a scalable networking solution to connect Kubernetes pods. It also enables you to enforce security policies on your host networking or service mesh layers.
  • Weave Net—a proprietary networking toolkit you can use to create a virtual network. Weave Net includes features for resilience, scalability, security, multicast networking, and service discovery. It is based on decentralized architecture and doesn’t require any external configuration services or storage.

Check this out: Since Kubernetes is the most ‘hot & trending‘ in the containerization world, most of the IT professionals are Kubernetes certification aspirants because of the undisputed value it holds. Let’s come to the good news, Certified Kubernetes Administrator (CKA)

Ingress and Egress Traffic

Ingress – simply means incoming traffic. Traffic to a pod from an external network endpoint outside the cluster is allowed if ingress from that endpoint is allowed to the pod. It is composed of all the data communications and network traffic originating from external networks and destined for a node in the host network.

Egress is the reverse of ingress traffic, which means outgoing traffic. The traffic from a pod to an external network endpoint outside the cluster is allowed if egress is allowed from the pod to that endpoint. In egress, all traffic is directed towards an external network and originated from inside the host network.

Note: Know more about Kubernetes Network policy 

Cluster Networking

In a standard Kubernetes deployment, there are several networking variations you should be aware of. Below are the most common networking situations to know.

Also read: Docker vs Virtual Machine to understand what is their difference.

Container-to-container Networking

The smallest object we can deploy in Kubernetes is the pod, however, within each pod, you may want to run multiple containers. A common use-case for this is a helper where a secondary container helps a primary container with tasks such as pushing and pulling data. Container to container communication within a K8s pod uses either the shared file system or the localhost network interface.

Pod-to-Pod Networking

Pod-to-pod networking can occur for pods within the same node or across nodes. Each of your nodes has a classless inter-domain routing (CIDR) block. This block is a defined set of unique IP addresses that are assigned to pods within that node. This ensures that each pod is provided with a unique IP regardless of which node it is in.

There are 2 types of communication.

  • Inter-node communication
  • Intra-node communication

Also Check: our previous blog on helm Kubernetes

Pod-to-Service Networking

Kubernetes is designed to allow pods to be replaced dynamically, as needed. This means that pod IP addresses are not durable unless special precautions are taken, such as for stateful applications. To address this issue and ensure that communication with and between pods is maintained, Kubernetes uses services.

Kubernetes services manage pod states and enable you to track pod IP addresses over time. These services abstract pod addresses by assigning a single virtual IP (a cluster IP) to a group of pod IPs. Then, any traffic sent to the virtual IP is distributed to the associated pods.

This service IP enables pods to be created and destroyed as needed without affecting overall communications. It also enables Kubernetes services to act as in-cluster load balancers, distributing traffic as needed among associated pods.

Internet-to-Service Networking

The final networking situation that is needed for most deployments is between the Internet and services. Whether you are using Kubernetes for internal or external applications, you generally need Internet connectivity. This connectivity enables users to access your services and distributed teams to collaborate.

When setting up external access, there are two techniques you need to use — egress and ingress. These are policies that you can set up with either whitelisting or blacklisting to control traffic into and out of your network.

Also Read: Our blog post on Kubernetes delete deployment. Click here

What are Services in Kubernetes?

Kubernetes Service provides the IP Address, a single DNS name, and a Load Balancer to a set of Pods. A Service identifies its member Pods with a selector. For a Pod to be a member of the Service, the Pod must have all of the labels specified in the selector. A label is an arbitrary key/value pair that is attached to an object. K8s Services are also a REST object and also an abstraction that defines a logical set of pods and a policy for accessing the pod set.

Services select Pods based on their labels. When a network request is made to the service, it selects all Pods in the cluster matching the service’s selector, chooses one of them, and forwards the network request to it. Let us look at the core attributes of any kind of service in Kubernetes:

  • Label selector that locates pods
  • ClusterIP IP address & assigned port number
  • Port definitions
  • Optional mapping of incoming ports to a targetPort

Check Out: Kubernetes Monitoring Tools. Click here

ClusterIP

ClusterIP is the default Service type in Kubernetes. In this Service, Kubernetes creates a stable IP Address that is accessible from all the nodes in the cluster. The scope of this service is confined within the cluster only.
The main use case of this service is to connect our Frontend Pods to our Backend Pods as we don’t expose backend Pods to the outside world because of security reasons.

NodePort

NodePort exposes the Service on each Node’s IP at a static port (the NodePort). NodePort builds on top of ClusterIP to create a mapping from each Worker Node’s static IP on a specified (or Kubernetes has chosen) Port. We can contact the NodePort service, from outside the cluster, by requesting <Node IP>:<Nodeport>. The only main use case of NodePort Service is to expose our Pods to the outside world.
Note: We can only expose the ports 30000-32767.

LoadBalancer

The LoadBalancer Service is a standard way for exposing our Nodes to the outside world or the internet. We have multiple Pods deployed on multiple Nodes, to access our application we can use any of the Public IP of any node and node port. But there are some problems in this scenario, like which Nodes IP we will provide to the clients and how will the traffic balance between the multiple nodes into the cluster. A simple solution for this will be LoadBalancer.

Also Read: Kubernetes Labels and Kubernetes Annotations are one of the main components which provide a way for adding additional metadata to our Kubernetes Objects.

Ingress Controller

Ingress Controller is an intelligent Load Balancer. Ingress is a high-level abstraction responsible for allowing simple host or URL based HTTP routing. It is always implemented using a third-party proxy. These implementations are nothing but Ingress Controller. It is a Layer-7 load balancer.

Also Read: Know everything about Ingress Controller.

DNS in Kubernetes

The Domain Name System (DNS) is the networking system in place that allows us to resolve human-friendly names to unique IP addresses. By default, most Kubernetes clusters automatically configure an internal DNS service to provide a lightweight mechanism for service discovery.  Kube-DNS and CoreDNS are two established DNS solutions for defining DNS naming rules and resolving pod and service DNS to their corresponding cluster IPs. With DNS, Kubernetes services can be referenced by name that will correspond to any number of backend pods managed by the service.

A DNS Pod consists of three separate containers:

  • Kubedns: watches the Kubernetes master for changes in Services and Endpoints, and maintains in-memory lookup structures to serve DNS requests.
  • Dnsmasq: adds DNS caching to improve performance.
  • Sidecar: provides a single health check endpoint to perform health checks for dnsmasq and kubedns.

Check out: our blog on how to install Kubernetes

Related/References

Leave a Reply

Your email address will not be published. Required fields are marked *