Mastering Kubernetes Objects

You have already learned about the core components of a Kubernetes cluster. In this lesson, you will learn about Kubernetes objects and how they work together.

Kubernetes objects are entities which are persisted inside the Kubernetes cluster. More precisely, they are persisted inside the etcd key-value store. Kubernetes objects can represent a wide range of different resources, such as Pods, Services, Deployments, etc.

These objects are defined using the YAML or JSON format and can be managed using the RESTful Kubernetes API, which is exposed by the kube-apiserver component of the Kubernetes control plane. This means that you can create, update, delete, and query objects using the API.

Here's an example request to fetch information about a Pod object:

1
GET https://<kubernetes-cluster>.com/api/v1/namespaces/<namespace>/pods/<pod-name>

Each Kubernetes object is defined in a config file in the YAML or JSON format. The config file contains the specification of the object in a declarative way. This enables you to define the desired state of the object. Kubernetes will then permanently check if the actual state of the object matches the desired state. If not, Kubernetes will try to make the actual state match the desired state. This is called the reconciliation loop.

A simple Kubernetes Pod object is declared as follows:

12345678
apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
    containers:
    - name: my-container
      image: nginx:1.21.3

Let's break down the different parts of the Pod object:

• The apiVersion field specifies the version of the Kubernetes API which is used to define the object. Each object can have different API versions.
• The kind field specifies the type of the Kubernetes object.
• The metadata field contains the metadata of the object.
• The spec field contains the specification of the object. The spec field is different for each object type. For example, the spec field of a Pod object contains the specification of the containers that are part of the Pod.

These are the mandatory fields of a Kubernetes object. However, you can also add additional fields to the object.

The object described above will create a Pod with the name my-pod which contains a single container with the name my-container. The container will use the nginx image in version 1.21.3.

There are a few core objects which you will encounter in almost every Kubernetes cluster. It is essential to understand what they are. The following provides an overview of the most important Kubernetes objects:

Pods

As introduced previously, Pods are the smallest deployable units in Kubernetes and are a thin wrapper around one or more containers. Pods are always scheduled to nodes. Pods can be created, updated, and deleted using the Kubernetes API.

Running multiple containers in a single Pod is an anti-pattern. The primary reason is that it makes scaling and updating the containers harder. It is also more difficult to manage the containers as they are tightly coupled. An example might be a Pod that runs two containers, such as a web server and a database. If you want to scale the web server, you must also scale the database, even if this is not necessary.

However, there are a few common scenarios where it makes sense to run multiple containers in a single Pod. For example, if you want to run a sidecar container that provides additional functionality to the main container, such as logging, monitoring or proxying traffic. We will look at sidecar injections in more detail later as we look at service meshes with Istio.

Services

Services group a set of Pods together and provide a stable entry point for accessing them. The Service in the following diagram also provides load-balancing capabilities distributing traffic across multiple Pods. The Pods are grouped using labels and selectors, which we will look at later.

This is especially useful when an application is scaled to run across multiple Pods in a cluster, as the Service can effectively group and provide a stable entry point for accessing them.

ReplicaSets

ReplicaSet is a set of Pods of a specific type that should be running cluster-wide at any given time. The ReplicaSet will ensure that the desired number of Pods is always running. If a Pod is deleted, the ReplicaSet creates a new Pod to replace it. This validation is performed within the reconciliation loop, which compares the desired state (the number of Pods) with the actual state (the number of running Pods). ReplicaSets are a good way to ensure the high availability of applications and leverage the self-healing capabilities of Kubernetes.

Note

It is also important to know that the ReplicaSet does not own the Pods. Instead, it is just responsible for making sure that the desired number of Pods is running. If you delete a Pod, the ReplicaSet will create a new Pod to replace it. However, you can also delete the ReplicaSet without deleting the Pods.

Deployments

Deployments are a high level abstraction on top of ReplicaSets. Deployments can be used to declaratively define the desired state of your application. This includes the number of replicas, the container images and further configuration. Deployments manage ReplicaSets and ReplicaSets manage Pods.

With Deployments you can roll out new versions of your application. This rollout will then be performed in a highly controlled way. The Deployment will create a new ReplicaSet next to the old one. Afterwards, it will start a new ReplicaSet and scale it up to the desired number of replicas. Once the new ReplicaSet is up and running, it will start to scale down the old ReplicaSet. This ensures that there is always at least one ReplicaSet running. This is called a rolling update and it is a very powerful feature of Deployments, since it is a very safe way to roll out new versions of your applications with zero downtime (Zero Downtime Deployment).

Note

There are many other Kubernetes objects, some of which will be covered later in this course. Kubernetes is, in fact, also super extensible. You can define your custom objects and extend the Kubernetes API using Custom Resource Definitions (CRDs).

To learn more about other objects or CRDs, you can check out the Official Kubernetes documentation.

Each Kubernetes object can be labeled with key-value pairs. Labels are used to identify objects. For example, you can label all Pods of a particular application with the label app: my-app. This way, you can easily identify them.

This is an example of how services group Pods together. Services use label selectors to identify the Pods that should be part of the service. A label selector is a query for selecting objects based on their labels. For example, the label selector app: my-app selects all Pods with the label app: my-app.

Both can be defined in the metadata section of the object definition:

12345678910
apiVersion: v1
kind: Pod
metadata:
  name: my-pod
  labels:
    app: my-app
spec:
    containers:
    - name: my-container
      image: nginx

Annotations are similar to labels, but they are not used to identify objects. Annotations can be used to store additional information about an object. These annotations basically enrich the object with semantic metadata. Unlike labels, annotations are not used for identifying, filtering or selecting objects. Annotations are typically used by other tools to store further information about the object.

You can now differentiate between the different Kubernetes objects and their purpose. You also know how they relate to each other and how they can be labeled and grouped together in namespaces.