Kubernetes Networking: An overview

Kubernetes is the most common environment for deploying modern infrastructures. It allows you to run different parts of your infrastructure in different instances. From one side it minimizes impact of one element failure to other elements, and from another side, it gives you the opportunity to scale your app dynamically according to the load level.

And in this case the connections between different instances and with the external world becomes extremely important. So, Kubernetes networking becomes a critical aspect of your infrastructure because it directly impacts the performance, availability and security of your applications. What’s more, it is not a one-size-fits-all solution, as there are multiple networking models and plugins to choose from, each with its own benefits and trade-offs. But without proper network configuration your applications may face issues with latency, packet loss or even downtimes which will be very difficult to determine and to solve.

In this article we will provide an overview of Kubernetes networking, including the basic concepts, networking models and plugins. We will also discuss some common challenges that can arise with Kubernetes networking and provide the best practices for configuring it effectively. By the end of this article, you should have a better understanding of Kubernetes networking and be able to apply best practices to optimize the networking performance of your Kubernetes.

Kubernetes Network Overview

In Kubernetes networking refers to the communication between containers, pods and services in a cluster. To understand Kubernetes networking, it’s essential to understand the following concepts:

• Kubernetes Networking Models: In the context of Kubernetes, networking models describe how network traffic is routed between containers, pods, and services within a cluster, and how communication is managed across multiple nodes.

• Kubernetes Networking Plugins: Kubernetes networking plugins are add-ons that provide additional functionality and features to Kubernetes networking, such as network security, load balancing, and traffic management. These plugins work with different networking models.

• CoreDNS: CoreDNS is a flexible and highly scalable DNS server that is used as the default DNS server in Kubernetes. CoreDNS provides service discovery, pod DNS resolution, and support for custom DNS backends using plugins.

• Ingress: Ingress is an API object that provides a way to manage external access to services in a Kubernetes cluster. Ingress allows for the configuration of HTTP and HTTPS routing rules that map incoming traffic to specific services within the cluster based on the requested URL.

We will try to briefly introduce the specified concepts in order to form a general understanding of how the networks are structured in Kubernetes.

Kubernetes Network Models and Plugins

Kubernetes supports different network models to enable communication between pods and services within a cluster. These models are

• Host-Based Networking: In host-based networking. Each pod is assigned a unique IP address from the host machine’s subnet. This allows for efficient intra-node communication, but can be challenging for cross-node communication. It may be preferable to use it for high-performance workloads, like machine learning apps, for very large deployments, container-native network solutions or network-intense applications such as databases.

• Overlay Networking: Overlay networking uses an overlay network that runs on top of the physical network infrastructure to enable communication between pods across nodes. This allows for greater flexibility and scalability but can introduce additional latency and overhead. It is good for multi-tenant environments to separate network overlay for each tenant, hybrid cloud environments to enable communication between on-premises and cloud-based resources, for some legacy applications which may require specific IP address ranges. Or if you want just to simplify your network configuration and latency is not critical for you.

• Underlay Networking: Underlay networking uses the existing physical network infrastructure to enable communication between pods across nodes. This model is simpler and more efficient than overlay but may require additional configuration and management. So it may be used for the same cases as host-based, but additionally it will give you more simplicity in configuration, more performance and more security features. But you should remember that it is less flexible and scalable than a host-based model.

However in Kubernetes, networking models are typically defined indirectly through the use of a networking plugin. Each networking plugin implements a specific networking model and provides additional functionality and features, such as network security, load balancing, and traffic management. When configuring Kubernetes networking, it is generally recommended to choose a networking plugin that provides the necessary networking model for your specific use case. Defining a networking model directly can be complex and error-prone, and it is generally easier and more reliable to rely on a networking plugin that has been tested and validated by the Kubernetes community.

Here is a list of some common weepers, which, of course, is not exhaustive:

• Flannel: Flannel is a popular networking plugin that provides a simple overlay network using either the host-based or overlay network model.

• Calico: Calico is a network plugin that provides network security and policy enforcement using the underlay network model.

• Cilium: Cilium is a network plugin that provides both network security and load balancing using the host-based network model.

It is important to choose the right network model and plugin based on your application’s needs and the network infrastructure in place.

Kubernetes Services

Service is an abstraction that defines a logical set of pods and a policy by which to access them. Services enable communication between pods, even if they are running on different nodes in the cluster or have been created or destroyed dynamically.

When a service is created in Kubernetes, it assigned a unique IP address and DNS name. The IP address is used to route traffic to the service, while DNS name is used to discover the service within the cluster. The service acts as a load balancer for pods that are associated with it, distributing incoming traffic evenly among them.

Services are closely related to pods in Kubernetes, as they provide a way to access and manage groups of pods. Each service is associated with one or more pods, which are identified by labels. When a pod is created or destroyed, the service automatically updates its list of associated pods, ensuring that incoming traffic is always routed to available pods.

There are several types of services in Kubernetes. We will briefly look at each of them:

• ClusterIP: ClusterIP is the default service type in Kubernetes, and it provides a stable IP address for accessing a set of pods within a cluster.The service is only accessible within the cluster and is not exposed to the outside world.

• NodePort: NodePort service exposes a pod to outside world by mapping a port on each node in the cluster to the pod’s port. This enables access to the pod from outside the cluster, but it is not very flexible. One service bond the port of nodes and no other apps in Kubernetes can use this port any more. For example you won’t we able to host several web apps which should listen for 443 port in you cluster if you use nodePort services. We will see how to solve this situation further. And also, this solution can also introduce security risks.

• LoadBalancer: This kind of service provides a way to expose a set of pods to outside world through a load balancer such as cloud load balancer or some metallLb solutions. This enables incoming traffic to be distributed among the pods in a balanced way. LoadBalancer service type is often used in cloud-based Kubernetes deployments. The load balancer can be configured to route the traffic specific port on the service, which is then distributed among the pods associated with the service.

• ExternalName: ExternalName service maps a service to an external DNS name, enabling pods within the cluster to access external services using a consistent naming convention.

• Headless: This service type is used to disable load balancing behavior of Kubernetes and enable direct access to individual pods. This can be useful for stateful applications that require direct access to specific pods.

DNS in Kubernetes

DNS is one of the important parts in Kubernetes networking. It is used to enable communication between services using domain names rather than IP addresses. By default Kubernetes does not resolve pods names as it is not very common to address directly to pods. Instead of it we communicate with them by services.

Kubernetes uses CoreDNS as its default DNS service. Which is a DNS server that is designed to be highly scalable and flexible. CoreDNS exists in a form of pods in a kube-system namespace with its own autoscaler.

The fully qualified name for the service consists of the cluster domain .cluster.local for example, .svc subdomain, .namespaceName subdomain and service name. It can look like nodejs.myapp.svs.cluster.local. Unlike services, pods' names are resolved not with their real names. Instead, CoreDNS takes the pod’s IP address, replaces dots by dashes and uses it like a pod name. For example if the pod has IP address 10.0.12.134, it will be transformed to domain name 10-0-12-134. Like services, pods have FQDN. To make it, we should add .namespaceName, .pod subdomains and cluster, local domain. It can look like 10-0-12-134.myapp.pod.cluster.local. You may reach a service with its only name from the same namespace, but if you need to address it from another namespace, you should add at least namespaceName subdomain or use FQDN of a service.

Ingress in Kubernetes

In Kubernetes, Ingress is an PAI object that provides a way to manage external access to services in a Kubernetes cluster. Ingress allows for the configuration of HTTP and HTTPS routing rules that map incoming traffic to specific services within the cluster based on the requested URL.

In traditional Kubernetes networking, services are exposed directly to the internet or to other clusters through the use of NodePort or LoadBalancer services. This approach can be complex and error-prone, and it may not provide the necessary control of flexibility for more complex application architectures.

In contrast, Ingress provides a simpler and more flexible way to manage external access to services in Kubernetes. Ingress defines a set of routing rules that map incoming traffic to services based on the requested URL, enabling more gradual control over traffic routing and load balancing.

Ingress also provides additional features such as SSL/TLS termination, name-based virtual hosting, and support for custom plugins. This enables more advanced networking configurations, such as multi-tenant environments or complex application architectures.

Conclusion

In conclusion, Kubernetes networking is a critical component of building and managing modern, scalable applications in Kubernetes clusters. It provides several networking models, including host-based, overlay and underlay networking, each with its benefits and trade-offs. Choosing the appropriate networking model depends on the specific needs of your deployment, and Kubernetes networking plugins can provide additional functionality and features to enhance networking capabilities.

DNS, Ingress and services are also important concepts in Kubernetes networking, providing a standardized way to manage domain name resolution, external access and load balancing for pods and services. By understanding these concepts and how they work together, you can create more efficient, resilient and scalable applications in the Kubernetes cluster.