Sunimal Herath

If I want my app to run in a single pod, I can create a single pod, also, can create a deployment with 1 replica set. What’s the difference? Which one should I use and why?

Okay, while learning Kubernetes, I learnt that I can create pods directly and also, I can use a deployment. So, if I want to create a single pod for my app, why should I use a deployment to do that instead of creating a single pod from a yaml?

I can create a yaml file for my pod using the following command. It uses the publicly available nginx image. Once created, I can edit the yaml file and use my own app image.

kubectl run my-pod --image=nginx --dry-run=client -o yaml > pod.yaml

After removing unwanted lines, the yaml file looks like this.

apiVersion: v1  
kind: Pod  
metadata:  
 labels:  
   run: my-pod  
 name: my-pod  
spec:  
 containers:  
 - image: nginx  
   name: my-pod  
   resources: {}  
 restartPolicy: Always

now I can create the pod (my-pod) using the either of following commands.

kubectl create -f pod.yaml 

or

kubectl apply -f pod.yaml

NAME     READY   STATUS    RESTARTS   AGE  
my-pod   1/1             Running             0                84s

Also, I can create a single pod with a deployment like so from the following command. Same as the pod creation, first I can use a publicly available image (i.e. nginx) to create the yaml file.

kubectl create deployment my-depl --image=nginx --dry-run=client -o yaml > deployment.yaml

Once edited and removed the unwanted lines, the deployement.yaml file will look like this.

apiVersion: apps/v1  
kind: Deployment  
metadata:  
 labels:  
   app: my-depl  
 name: my-depl  
spec:  
 replicas: 1  
 selector:  
   matchLabels:  
     app: my-depl  
 template:  
   metadata:  
     labels:  
       app: my-depl  
   spec:  
     containers:  
     - image: nginx  
       name: nginx

And now I can edit this yaml file to use my own app image (in this example, I keep the nginx as I don’t have my own app image) and keep the replicas as 1 which means, once deployed, it will only create only one pod.

I can deploy it using the following command.

kubectl apply -f deployment.yaml

Since Kubernetes creating the pod according to the manifest, it does the pod naming.

NAME                                              READY   STATUS    RESTARTS   AGE  
my-depl-7769658b49-bjnsj   1/1           Running              0              3m39s

So, what’s the difference between these two methods of creating pods? First one was created by me and if the pod crashes, there’s no self healing and I have to re-create it manually. On the other hand, if the pod created with the deployment crashes, Kubernetes will recreate it for me (since Kubernetes is the one who created it in the first place). Also, if there’s an update to my app, all I need to do is edit the yaml file and mention the updated the version under image and Kubernetes takes care of the update (e.g. rolling updates) automatically. On the other hand, I need to edit the yaml file and recreate the pod manually if I create the pod myself.

Around 2005, I went with two colleagues and our team leader to present (or maybe deploy, I can’t remember exactly) the in-house web application we had built for the client. It was built using ASP.Net WebForms and connects with a MS SQL Server instance. I remember installing IIS, transferring the application successfully, but it didn’t work as expected because something was missing (I don’t remember what exactly, since it’s been nearly 20 years) and I remember calling another colleague who’s already in the office to bring another CD (not the application) to fix the issue. The environment we built the application in wasn’t the same as the one we deployed it to, so we ran into all sorts of unexpected errors we had to fix on-site.

This is where container technology really comes in handy. Now we can deploy web

applications in containers that package everything they need such as code-base, runtime, libraries, etc. into a single unit (a container image). All you need is a container engine, and it can run anywhere and guaranteed to behave the same as it did on the developed machine.

Even though container technology eases the headache of deployment, it’s still not enough for modern micro-service architecture. Each micro-service, running in its own container, needs to be managed, preventing outages, spinning up new instances when demand spikes, and so on. That’s where Kubernetes comes in. With Kubernetes, we can now automate, manage, and scale containerized applications up or down as needed.