Kubernetes objects

The storage and compute resources of the system are classified into different objects that reflect the current state of the cluster. Objects are defined using a .yaml spec and the Kubernetes API is used to create and manage the objects. We are going to cover some common Kubernetes objects in detail in the following subsections.

Pods

The Pod is the basic building block of a Kubernetes cluster. It’s a group of one or more containers that are expected to co-exist on a single host. Containers within a Pod can reference each other using localhost or inter-process communications (IPCs).

Replica sets

Replica sets ensure that a given number of Pods are running in a system at any given time. However, it is better to use deployments instead of replica sets because replica sets do not offer the same enhanced features, flexibility, and management capabilities for workloads as deployments. Deployments encapsulate replica sets and Pods. Additionally, deployments provide the ability to carry out rolling updates.

Deployments

Kubernetes deployments help scale Pods up or down based on labels and selectors. The YAML spec for a deployment consists of replicas, which is the number of instances of Pods that are required, and templates, which are identical to Pod specifications.

Services

A Kubernetes service is an abstraction of an application. A service enables network access for Pods. Services and deployments work in conjunction to ease the management and communication between different pods of an application. Kubernetes services will be explored in more detail in the next chapter, Chapter 2, Kubernetes Networking.

Volumes

Container storage is ephemeral by nature, which means that they are created on the fly and exist only for a short duration, typically to assist with debugging or inspecting the state of a running Pod. If the container crashes or reboots, it restarts from its original state, which means any changes made to the filesystem or runtime state during the container’s lifecycle are lost upon restart. Kubernetes volumes help solve this problem. A container can use volumes to store a state. A Kubernetes volume has a lifetime of a Pod, unless we are using PersistentVolume [3]; as soon as the Pod perishes, the volume is cleaned up as well. Volumes are also needed when multiple containers are running in a Pod and need to share files. A Pod can mount any number of volume types concurrently.

Namespaces

Namespaces help a physical cluster to be divided into multiple virtual clusters. Multiple objects can be isolated within different namespaces. One use case of namespaces is on multi-tenant clusters, where different teams and users share the same system. Default Kubernetes ships with four namespaces: default, kube-system, kube-public, and kube-node-lease.

Service accounts

Pods that need to interact with kube-apiserver use service accounts to identify themselves. By default, Kubernetes is provisioned with a list of default service accounts: kube-proxy, kube-dns, node-controller, and so on. Additional service accounts can be created to enforce custom access control. When you create a cluster, Kubernetes automatically creates the default service account for every namespace in your cluster.

Network policies

A network policy defines a set of rules of how a group of Pods is allowed to communicate with each other and other network endpoints. Any incoming and outgoing network connections are gated by the network policy. By default, a Pod can communicate with all Pods.

Pod security admission

The PodSecurityPolicy was deprecated in Kubernetes v1.21 and removed from Kubernetes in v1.25. The Kubernetes Pod Security Standards (PSS) define different isolation levels for Pods. These standards let you define how you want to restrict the behavior of Pods. Kubernetes offers a built-in Pod Security admission controller to enforce the Pod Security Standards as an alternative to PodSecurityPolicy.

You now have an understanding of the fundamentals of Kubernetes objects, including essential components such as Pods, Deployments, and Network Policies, which are critical when deploying a cluster. While Kubernetes has become the de facto standard for container orchestration and managing cloud-native applications, it is not always the best fit for every organization or use case. DevOps teams and system administrators may seek Kubernetes alternatives. Next, you will see some alternatives to Kubernetes.