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 be used to represent a wide range of different resources, such as pods, services, deployments, and so on. Kubernetes objects are defined using the YAML or JSON format.

Also, every object can be controlled by the Kubernetes API. This means that you can create, update, delete, and query objects using the RESTful Kubernetes API. The Kubernetes API is exposed by the kube-apiserver component of the Kubernetes control plane.

The request to fetch information about a pod object might look like this:

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

Each Kubernetes object is defined in a config file with 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:

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
    containers:
    - name: nginx
      image: nginx:1.14.2 # use specific version, not latest

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 above described object 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.

There are a few core objects which you will encounter in almost every Kubernetes cluster. It is important to understand these objects. 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 this makes it harder to scale and update the containers. It is also more difficult to manage the containers because they are tightly coupled. An example might be a pod, which runs two containers, such as a web server and a database. If you want to scale the web server, you have to scale the database as well, 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. This service is basically a load balancer that distributes the traffic to the pods. The grouping of pods is done using labels and selectors, which we will look at later.

This is useful, if you have scaled your application, so that it is running multiple times in pods across your cluster. You can then use a service to group them together and to provide a stable entry point for accessing them.

ReplicaSets

With ReplicaSets, you can define how many pods of a specific type should be running cluster-wide at any given time. This set of pods is called a ReplicaSet. The ReplicaSet makes sure 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 is in this case comparing the desired state (the number of pods) with the actual state (the number of running pods). ReplicaSets are a good way to ensure high availability of your application and to 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. This is called 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 labelled 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 all the pods of a particular application.

This is exactly how services group pods together, for example. 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 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:

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.