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, and more.

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 then permanently checks if the actual state of the object matches the desired state. If not, Kubernetes tries 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 creates a Pod with the name my-pod which contains a single container with the name my-container. The container uses the nginx image in version 1.21.3.

There are a few core objects which you can find in almost every Kubernetes cluster. See 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 offers 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.

Hint

A Kubernetes Service exposes the application Pods as a network service with a consistent DNS name and IP inside a Kubernetes cluster. To expose the internal Kubernetes Service to the internet, you must create the APIRule custom resource. This approach is similar to creating routes in Cloud Foundry runtime. You will learn more about exposing Services in the unit Discovering Services in Kubernetes.

ReplicaSets

ReplicaSet is a set of Pods of a specific type that are running cluster-wide at any given time. The ReplicaSet ensures 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 use the self-healing capabilities of Kubernetes.

Note

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

Deployments

Deployments are a high level abstraction on top of ReplicaSets. You can use Deployments 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. Such a rollout is performed in a highly controlled way. The Deployment creates a new ReplicaSet next to the old one. Afterwards, it starts a new ReplicaSet and scale it up to the desired number of replicas. Once the new ReplicaSet is up and running, it starts 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 powerful feature of Deployments, since it is a safe way to roll out new versions of your applications with zero downtime (Zero Downtime Deployment).

Hint

To apply a Deployment in Kyma, you use the command kubectl apply -f deployment.yaml. This command is similar to the command cf push in Cloud Foundry runtime. However, in Kubernetes, the Deployment must include information about the artifact (Docker image). Creating and storing the artifacts is not required in Cloud Foundry runtime.

Note

There are many other Kubernetes objects, some of which will be covered later in this course. Kubernetes is, in fact, also 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, 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 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 used to select objects according to their labels. For example, the label selector app: my-app selects all Pods with the label app: my-app.

You can define labels 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, unlike labels, annotations are not used for identifying, filtering or selecting objects. Annotations enrich the object with semantic metadata. Typically, different tools utilize annotations to store additional details 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.