KUBERNETES: Deployment

Stephen Olabode
4 min readNov 20, 2019

In this post, I’ll basically explain what I understand deployment in kubernetes to be, its architecture, a few commands that are used to get some extra little information on your deployments and I’ll do all these on my local machine using KIND(Kubernetes in Docker) with some screenshots to make it a little more. First of all, I’ll like to talk about replication in deployment, or as some will call it, replica set. This could be identified as the the newer generation of replication controller, this is because it supports a selector based on filtering on a new set of values. The Replica set is used to build and maintain multiple (two or more) pods within your node servers. It ensures that the specified number of pods run at the same time and it maintains these pods by replacing them whenever there’s any termination or failure among the existing pods. That said, let’s do a deep dive into what deployment really is.

Deployment simply is a declaration in Kubernetes that enables flexibility in application deployments and updates. This makes the deployment of your applications much easier than when you deploy your apps with the “replication controller” declaration. It offers more flexibility which in turn gives more control over the state of your application and all of that. Some of the control this declaration gives you asides the basic creation of pods includes; deployments update i.e. to deploy a newer version, deployment rolling update i.e. to be able to apply upgrades/downgrades to an active application with zero downtime, this is done by applying these changes in steps and stages such that your application still has a steady uptime. Other controls that this offers are rollbacks, that is the ability to go back to previous updates (or versions) and the pause/resume control i.e. the ability to rollback updates to a certain percentage.

Below is an example of a deployment yaml file architecture to give an idea to how it is declared.

apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: my-apache-deployment
spec:
replicas: 3
template:
metadata:
labels:
app: my-apache
spec:
containers:
- name: my-apache-container1
image: httpd
ports:
- containerPort: 80

The apiVersion is simply the server version that’s in use, then the kind is the declaration object to be used. We then have the metadata which contains basic information about the container like the name and the specifications of the pod which contains the replica set, the pod labels, templates which has its own metadata also and its label. The template furthermore has it’s own spec which includes the name of the container, its image and its port.

Like i stated earlier, i’ll be using the ‘KIND’ to maintain my cluster on my local machine, showing some commands along the way. First thing to do, of course, is to setup the cluster using the “kind create cluster” command, then i did the “kubectl get nodes” to give a list of my servers and as you can see, i have one master node and three worker nodes.

Seeing the nodes are created already, next thing that was done was to create a deployment with the deployment yaml file shown above. The simple command to get that working is the “kubectl apply -f <deployment.yaml>”, in this case, my deployment.yaml file is httpd-basic-deployment.yml. As shown in the code above, the .yml file has three pod replicas i.e. three pods will be created and distributed along the 3 worker nodes.

After a few minutes, when you do your “kubectl get pods -o wide”, the pods created should be running just as shown below. Once this is done, that simply means you have an active deployment running on your nodes and then you can nowgo further to try some commands as shown below.

The kubernetes deployment declaration has its own little commands which provides some extra information about its state and other things. I’ll run through a few of these commands and provide a little explanation on each of these commands.
kubectl get deployments: this simply provides info about the current state of your deployment.
kubectl get rs: this gives basic info about the replication set.
kubectl get pods --show-labels: this gives info about the pods available together with the labels associated to each pod.
kubectl rollout status deployment/ “deployment_name”: this provides the status of the current deployment.
kubectl set image deployment/“deployment_name” “current_image=new_image”: this is to update the current image being used by the current deployment to a newer version
kubectl edit deployment/“deployment_name”: this helps to edit the current deployment declaration
kubectl rollout status deployment/“deployment_name”: this provides the status of the current rollout
kubectl rollout history deployment/“deployment_name”: this provides the rollout history of the deployment
kubectl rollout undo deployment/“deployment_name”: this reverses the latest rollout to the previous version
kubectl rollout undo deployment/“deployment_name” --to-revision=n: this provides an avenue to rollback to your preferred version.

This will be all as regards deployment, i hope it provides a little enlightenment on what deployment in kubernetes is. Thanks for reading through.

--

--

Stephen Olabode

DevOps Engineer | AWS Enthusiast | Cloud Computing | Solutions Architect