Applications running on a Kubernetes cluster are supposed to be accessible either internally from the cluster or externally, from outside the cluster. The implication from the network’s perspective is there may be a Uniform Resource Identifier (URI) or Internet Protocol (IP) address associated with the application. Multiple applications can run on the same Kubernetes worker node, but how can they expose themselves without conflicting with each other? Let’s look at this problem together and dive into the Kubernetes network model.

Port-sharing problems

Traditionally, if there are two different applications running on the same machine, they cannot listen on the same port. If they both try to listen on the same port in the same machine, one application will not launch as the port is in use. This occurs because the network stack prevents multiple applications from using the same IP and port simultaneously. A simple illustration...

For the hands-on part of the book and to get some practice from the demos, scripts, and labs from the book, you will need a Linux environment with a Kubernetes cluster installed (better to use version 1.30 as a minimum). There are several options available for this. You can deploy a Kubernetes cluster on a local machine, cloud provider, or a managed Kubernetes cluster. Having at least two systems is highly recommended for high availability, but if this option is not possible, you can always install two nodes on one machine to simulate the latest. One master node and one worker node are recommended. One node only would also work for most of the exercises.

Containers inside the same Pod share the same Pod IP address. Usually, it is up to application developers to bundle the container images together and to resolve any possible resource usage conflicts such as port listening. In this section, we will dive into the technical details of how the communication happens among the containers inside the Pod and will also highlight the communications that take place beyond the network level.

Linux namespaces and the pause container

Linux namespaces are a feature of the Linux kernel to partition resources for isolation purposes. With namespaces assigned, one set of processes sees one set of resources while another set of processes sees another set of resources. Namespaces are a major fundamental aspect of modern container technology. It is important for you to understand this concept in order to know Kubernetes in depth. So, we set forth all the Linux namespaces with explanations. Since Linux kernel version 4...

Kubernetes Pods are dynamic and ephemeral entities. When a set of Pods is created from a Deployment or a DaemonSet, each Pod gets its own IP address; however, when a Pod dies and restarts, Pods may have a new IP address assigned. This leads to the following two fundamental communication problems, given that a set of Pods (frontend) needs to communicate to another set of Pods (backend):

• Given that the IP addresses may change, what are the valid IP addresses of the target pods?
• Knowing the valid IP addresses, which Pod should we communicate with?

Now, let’s jump into the Kubernetes service, as it is the solution for these two problems.

The Kubernetes service

The Kubernetes service is an abstraction of a grouping of sets of Pods with a definition of how to access the Pods. The set of Pods targeted by a service is usually determined by a selector based on Pod labels. The Kubernetes service also gets an IP address assigned...

Kubernetes Deployments create and destroy Pods dynamically. For a general three-tier web architecture, this can be a problem if the frontend and backend are different Pods. Frontend Pods don’t know how to connect to the backend. Network service abstraction in Kubernetes resolves this problem.

The Kubernetes service enables network access for a logical set of Pods. The logical set of Pods is usually defined using labels. When a network request is made for a service, it selects all the Pods with a given label and forwards the network request to one of the selected Pods.

A Kubernetes service is defined using a YAML Ain’t Markup Language (YAML) file, as follows:

apiVersion: v1
kind: Service
metadata:
  name: service-1
spec:
  type: NodePort
  selector:
    app: app-1
  ports:
    - nodePort: 32766
      protocol: TCP
      port: 80
      targetPort: 9376

In this YAML file, the following applies:

• The type property...

CNI is a Cloud Native Computing Foundation (CNCF) project [2]. Basically, there are three components in this project: a specification, libraries for writing plugins to configure network interfaces in Linux containers, and some supported plugins. When people talk about the CNI, they usually refer to either the specification or the CNI plugins. The relationship between the CNI and CNI plugins is that the CNI plugins are executable binaries that implement the CNI specification. Now, let’s look into the CNI specification and plugins at a high level, and then we will give a brief introduction to two popular CNI plugins, Calico and Cilium.

Kubernetes 1.30 supports CNI plugins for cluster networking.

CNI specification and plugins

The CNI specification is only concerned with the network connectivity of containers and with removing allocated resources when the container is deleted. To elaborate further, first, from a container runtime...

This chapter discussed the typical port resource conflict problem and how the Kubernetes network model tries to avoid this while maintaining good compatibility for migrating applications from the VM to Kubernetes Pods. Next, the communication inside a Pod, among Pods, and from external sources to Pods was discussed.

Finally, we covered the basic concept of the CNI and introduced how Calico works in the Kubernetes environment with a step-by-step guide to install a popular CNI plugin (Cilium). After the first two chapters, we hope you have a basic understanding of how Kubernetes networking components work and how components communicate with each other.

In Chapter 3, Threat Modeling, we’re going to talk about threat modeling.

• [1] Cgroups: https://www.man7.org/training/download/secisol_cgroups_v1_slides.pdf
• [2] CNCF site: https://github.com/containernetworking/cni
• [3] Alexis Ducastel’s article: https://itnext.io/benchmark-results-of-kubernetes-network-plugins-cni-over-40gbit-s-network-2024-156f085a5e4e
• [4] eBPF documentation: https://ebpf.io/what-is-ebpf/
• [5] Installation guide for the Cilium plugin on an AWS EKS cluster: https://docs.cilium.io/en/stable/gettingstarted/k8s-install-default/