Deployment

In the previous tutorial, we saw how to create a Pod using a YAML file. However, we also mentioned that creating Pods directly is not recommended in Kubernetes.

Instead, we use higher-level controllers like Deployments to manage the lifecycle of Pods.

A Deployment is a Kubernetes resource that provides declarative updates for Pods and ReplicaSets. It allows you to define the desired state of your application and ensures that the actual state matches the desired state.

A Deployment manages the creation and scaling of Pods, as well as rolling updates and rollbacks. It ensures that the specified number of replicas of a Pod are running at all times. If a Pod fails or is deleted, the Deployment will automatically create a new one to replace it.

Create a Deployment

To create a Deployment, you can use a YAML file that defines the desired state of the Deployment. Here's an example of a simple Deployment definition:

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

Here's what this manifest file defines:

• apiVersion: Specifies the API version of the Kubernetes resource.
• kind: Specifies the type of Kubernetes resource, in this case, a Deployment.
• metadata: Contains metadata about the Deployment, such as its name and labels. Our deployment name is 'nginx-deployment'.
• spec: Defines the desired state of the Deployment, including the number of replicas, the selector for matching Pods, and the template for creating Pods.

You can save this YAML content to a file named deployment.yaml and then run the following command to create the Deployment:

kubectl apply -f deployment.yaml

Let's see the status of our deployment.

kubectl get deployments

vagrant@vagrant:~/kubernetes-tutorial$ kubectl get deployments
NAME               READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   1/1     1            1           25s

The above output shows:

• The name of the deployment is nginx-deployment.
• The READY column indicates that 1 out of 1 desired replicas are ready.
• The UP-TO-DATE column indicates that 1 replica is up-to-date with the deployment specification.
• The AVAILABLE column indicates that 1 replica is available to serve requests.
• The AGE indicates the amount of time that the deployment has been running.

Let's see the pods running under this deployment:

kubectl get pods

vagrant@vagrant:~/kubernetes-tutorial$ kubectl get pods
NAME                                READY   STATUS    RESTARTS   AGE
nginx-deployment-77bc6bd484-qf6gn   1/1     Running   0          5m38s

The above output shows that a Pod named nginx-deployment-77bc6bd484-qf6gn is running, which is managed by the nginx-deployment. Since the replicas field in our deployment configuration is 1, only one pod is running.

As we learned, let's delete the running pod and see if the deployment is able to create a new one.

kubectl delete pod nginx-deployment-77bc6bd484-qf6gn

vagrant@vagrant:~/kubernetes-tutorial$ kubectl delete pod nginx-deployment-77bc6bd484-qf6gn
pod "nginx-deployment-77bc6bd484-qf6gn" deleted

Now, let's check the status of the deployment again.

kubectl get deployments

vagrant@vagrant:~/kubernetes-tutorial$ kubectl get deployments
NAME               READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   1/1     1            1           15m

As we can see, the deployment is still showing that 1 replica is ready and available. Now, let's check the pods again.

kubectl get pods

vagrant@vagrant:~/kubernetes-tutorial$ kubectl get pods
NAME                                READY   STATUS    RESTARTS   AGE
nginx-deployment-77bc6bd484-qvsr2   1/1     Running   0          2m38s

As we can see, a new Pod named nginx-deployment-77bc6bd484-qvsr2 has been created and is running. This demonstrates that the Deployment controller has successfully created a new Pod to replace the one that was deleted, ensuring that the desired state of having 1 replica is maintained.

This is how the self-healing is achieved in Kubernetes.