Deploy the real world applications

Application Deployments

At this point, we know how and why of Namespaces now let’s do a deep dive on Deployment so we can understand much better on how application deployments work.

Before we learn about deployments, Let’s do a quick comparison between Pods & Deployments. This comparison is critical to understand the working nature of kubernetes.

What are Pods?

Kubernetes Pods are the smallest fundamental unit of deployment. It’s a group of containers that shares the same storage and even the same network resources.

Each kubernetes pods has a unique IP, storage and a configuration that is required for a pod to run. A pod that run more than one container can share resources and information more seamlessly between them. Also, because of the same network, both containers can locate each other at localhost.

In case of a static pods, these static pods have no replication and other controllers taking care. If the static pod dies no new pod will get spinned up. However, Deployments are different.

Labs on Pod

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx:latest
    ports:
    - containerPort: 80

Let’s run the nginx pod using the yaml configured above.

## Set the cluster context
kubectl config use-context docker-desktop
Switched to context "docker-desktop".

Save the above yaml as nginx-pod.yaml

## Apply the Pod yaml
kubectl apply -f nginx-pod.yaml
pod/nginx created

Now, that we’ve our pod created, let’s have look at that.

Use the following command to list the pods in default namespace.

kubectl get pods
NAME    READY   STATUS    RESTARTS   AGE
nginx   1/1     Running   0          2m19s

Bravo! We got out first pod running.

Let’s move onto the deployments

What are Deployments?

A deployment specifies an application lifecycle, the deployment includes the working with controller and changing the deployments current state to a desired state.

The deployments defines the behaviour of Pods and pods assignment to the app. In case the Pods fails, Kubernetes will spinup a new container to achieve the desired state of the deployment.

Labs on Deployments

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: nginx-deploy
  name: nginx-deploy
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx-deploy
  template:
    metadata:
      labels:
        app: nginx-deploy
    spec:
      containers:
      - image: nginx:latest
        name: nginx
        ports:
        - containerPort: 80

Use the above yaml and save it as nginx-deploy

Let’s apply this onto our cluster.

kubectl apply -f nginx-deploy.yaml
deployment.apps/nginx-deploy created

List out the deployments in the default namespace

kubectl get deploy
NAME           READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deploy   1/1     1            1           51s

So, we’ve reached at a point where our applications pods are being controller by Deployments. What will happen if we delete the pod generate from this deployment?

Let’s do that

## Get the pods

kubectl get pods
NAME                            READY   STATUS    RESTARTS   AGE
nginx-deploy-7496796997-nfklp   1/1     Running   0          2m41s
## Let's delete this pod

kubectl delete pod nginx-deploy-7496796997-nfklp
pod "nginx-deploy-7496796997-nfklp" deleted

We’ve deleted the pod and guess what? Kubernetes has spinned up a new pod. Let’s check the pod again

kubectl get pods
NAME                            READY   STATUS              RESTARTS   AGE
nginx-deploy-7496796997-mkwsh   0/1     ContainerCreating   0          6s
nginx-deploy-7496796997-mkwsh   1/1     Running             0          91s

What if the deployment fails?

Let’s explore some possible phases of pod lifecycle

  • Pending – The Pod has been accepted by the Kubernetes cluster, but one or more of the containers has not been set up and made ready to run. This includes time a Pod spends waiting to be scheduled as well as the time spent downloading container images over the network.
  • Running – The Pod has been bound to a node, and all of the containers have been created. At least one container is still running, or is in the process of starting or restarting.
  • Succeeded – All containers in the Pod have terminated in success, and will not be restarted.
  • Failed – All containers in the Pod have terminated, and at least one container has terminated in failure. That is, the container either exited with non-zero status or was terminated by the system.
  • Unknown – For some reason the state of the Pod could not be obtained. This phase typically occurs due to an error in communicating with the node where the Pod should be running.

Now, Let’s go back to out nginx-deploy.yaml and make some mistake

...
- name: nginx
  image: nginx:alpa
...

I’ve mistakenly specified the wrong image tag. Instead of nginx:latest, i specified nginx:alpa. What will happen now?

Let’s see the status of out deployment

kubectl get deploy
NAME           READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deploy   0/1     1            0           33s

It looks like our deployment is not ready! Let’s dig deeper.

## List out the pods

kubectl get pods
NAME                           READY   STATUS             RESTARTS   AGE
nginx-deploy-cbbdd86d9-z7j9n   0/1     ImagePullBackOff   0          2m6s

Ouch! Pod has encountered some error. It state ImagePullBackOff What could that mean?

Let’s describe the Pod and get some more information regarding this.

kubectl describe pod nginx-deploy-cbbdd86d9-z7j9n

We can see from the Pod events that it had a difficulty while pulling the specified image

Failed to pull image "nginx:alpa": rpc error: code = Unknown desc = Error response from daemon: manifest for nginx:alpa not found: manifest unknown: manifest unknown

I noticed that, I mistakenly specified incorrect image tag. It should be alpine instead of alpa. Let’s fix this.

Edit the Deployment

kubectl edit deploy nginx-deploy

Change the image tag to alpine and save it.

Now, if we see our deployments, we can see that pod is in running status.

NAME                           READY   STATUS    RESTARTS   AGE
nginx-deploy-fc6884c76-nvk8d   1/1     Running   0          58s

Now, that we know what pods and deployments are but have were we able to access these applications? How can we access our applications? Here, Kubernetes Services comes into the play!

    Leave a Reply

    Your email address will not be published. Required fields are marked *