Part IV: Cluster Management
Building Basic Workloads
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.
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.
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.
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.