Part IV: Cluster Management

Building Basic Workloads

6 min readJul 5, 2022

Back to the Basics

Now that the cluster is online and stable the focus of this document shifts to cluster management. Let’s discuss some of the basic components of Kubernetes.

Look at this beautiful cluster. Just look at it. Ok. Let’s continue.

Kubernetes Components

The control plane runs multiple agents, including kube-apiserver, etcd, kube-scheduler, and kube-controller-manager. The kube-apiserver agent receives and forwards all requests from the other agents and is responsible for maintaining the persistent state of the database.

The worker node’s primary agent is the kubelet, which is responsible for handling data sent from the master’s kube-apiserver, as well as maintaining the node’s configuration, deploying pods and controllers, downloading container images, and running the container runtime.

Additional details regarding all Kubernetes components are found at this link.

Let’s Talk About Microservices

Microservices architecture (often shortened to microservices) refers to an architectural style for developing applications.
Microservices allow a large application to be separated into smaller independent parts, with each part having its own realm of responsibility.
Containers are a well-suited microservices architecture example, since they let you focus on developing the services without worrying about the dependencies.
Modern cloud-native applications are usually built as microservices using containers.

Reference: What is microservices architecture?

Kubernetes Pods

Pods are composed of one or more containers that make up an application.

They can be started using a single command or by creating a yaml configuration file.

For instance, this command creates a pod that starts a container running nginx.

kubectl run nginx --image nginx

The same could be done using a configuration file.

apiVersion: v1
kind: Podmetadata:
  name: nginxspec:
  containers:
  - name: nginx
    image: nginx:1.14.2

Configuration files provide details for multiple containers along with container resources, i.e. storage volumes for sharing data or cpu and memory restrictions, that compose a pod.

Official documentation about Pods can be found here.

Kubernetes ReplicaSets

ReplicaSets manage one or multiple pods.

They are similar to auto-scaling groups, as they monitor pods to ensure a specific number, i.e. replicas, is running. If a number of pods is running other than what is specified, the ReplicaSet creates or deletes pods, as necessary.

The image below shows how a ReplicaSet is constructed using YAML.

Image captured from Official Documentation

Run the following command to create the ReplicaSet. This assumes the above file is named replica-set.yaml.

kubectl create -f replica-set.yaml

Official documentation about Pods can be found here.

Kubernetes Deployments

Deployments manage ReplicaSets, which essentially means Deployments scale and replicate sets of pods.

The image below shows how a Deployment is constructed using YAML.

Image captured from original documentation

Run this command to create the Deployment. This assumes the above file is named deployment.yaml.

kubectl create -f deployment.yaml

Remember This

Deployments manage ReplicaSets.
ReplicaSets manage Pods.
Pods consist of one or more containers.

Hands-On Practice

Create a Pod

The easiest way to create a pod is via the command line, but let’s create a pod using a yaml file, which will be named dualpod.yaml.

This pod will consist of a container running nginx and another running python.

apiVersion: v1
kind: Podmetadata:
  name: nginx-pythonspec:
  containers:
  - name: nginx
    image: nginx
  - name: python
    image: python

Create the pod.

kubectl create -f dualpod.yaml

>>> Something went wrong <<<

The status of the new pod is not ‘Running’ but ‘CrashLoopBackOff’.

Let’s get more more details about the pod.

kubectl describe pod nginx-python

The nginx container is running while the python container has a status of CrashLoopBackOff.

CrashLoopBackOff is a status message that indicates one of your pods is in a constant state of flux — one or more containers are failing and restarting repeatedly. — from containiq.com

As an administrator, know that one of the first things to check for errors is the associated log file(s).

Unfortunately, only the nginx container has log entries.

kubectl logs nginx-python nginx

Can the python container be started by itself from the command line?

kubectl run python --image=python

The python container still did not start so maybe the problem is with the container image itself.

My theory is this.

Containers remain alive as long as it is running a process. Like the “Hello World” docker container image, this python container image more than likely starts and then stops since it is not running any commands.

Let’s give the python container a command to run, and see it this resolves the issue.

Here is the updated yaml file.

Two lines were added so the container knows what to execute at startup.

Let’s create the pod again.

kubectl create -f dualpods.yaml

Problem resolved.

Both containers are running in the pod ( the Ready column shows 2/2), and the python container log shows the output of the command it ran at startup.

Create a ReplicaSet

Below are the contents of a yaml file that defines the ReplicaSet, which ensures 5 identical pods with nginx and python containers are active at all times.

Create the ReplicaSet.

kubectl create -f replicaset.yaml

There are now 5 pods running.

Let’s delete a pod, and see what happens.

First, list all the pods.

kubectl get pods

Now delete one of the pods.

kubectl delete pod pythonwebservice-2bxsg

The pod was successfully deleted, but the ReplicaSet definition specified 5 pods should run so it creates a new pod.

The old pod’s name included “2bxsg”.
The new pod’s name has “2h416”.

Create a Deployment

Below is the yaml file for the Deployment, which states there should be 3 ReplicaSets running at all times.

kubectl create -f deploy.yaml

A Deployment of 3 ReplicaSets is now running.

A Quick Review

Here is everything running on the Kubernetes cluster.

kubectl get all

To get more details on each workload, use the “kubectl get” command with the “-o wide” option for the deployment, replicaset, and pods.

kubectl get deployments
kubectl get replicasets
kubectl get pods

To gain more hands-on experience, add various containers to the Pod, create different ReplicaSets and Deployments.

Figure out how internet traffic can access your cluster.

Continue to build skills by trying something new and by breaking things to see what happens.