Kubernetes Deployments - A way to scale pods - a way to immortality

Pods are mortal. They are born and when they die, they are not resurrected. A deployment object is how you can give immortality to pods.

Deployments represent a set of multiple, identical Pods and upgrade them in a controlled way, performing a rolling update(update single or a batch of pods, instead of making changes in all the running pods at once).

A deployment runs multiple replicas of your application and automatically replaces any instances that fail or become unresponsive.

Deployment controller provides declarative updates for Pods and it manages pods running on your cluster.

Deployment controller always strives to make the declared desired state the actual state at a controlled rate.

In this way, deployments ensure that one or more instances of your application are available to serve user requests.

A Deployment manifest, like pod manifest needs

• apiVersion
• kind
• metadata - name, labels, annotations and other information.
• spec - replicas, deployment strategy, pod template, selection and other details.

.spec

The Pod Template or .spec.template and .spec.selector are the only mandatory fields of the .spec

1).spec.template - mandatory

The .spec.template has the exact same schema as a pod except it does not have an apiVersion or Kind. Only a .spec.template.spec.restartPolicy equal to Always is allowed, which is the default, even if not specified.

spec:
    template:   
        metadata: 
        name: wordpress-db
        labels:
            app: wordpress
            type: db
        spec:
            restartPolicy: Always
            containers:
                - name: wordpress-db-container
                  image: mysql:5.7
                  env:
                    - name: MYSQL_ROOT_PASSWORD
                      value: DEVOPS1

2).spec.selector - mandatory

The .spec.selector field defines how the Deployment finds which Pods to manage. Basically, the .spec.selector.matchLabels will match with the label of the pod to manage, which in this case is .selector.template.metadata.labels. If they do not match, it will be rejected by the API.

3).spec.replicas - optional - default Value (1)

It specifies the number of desired pods.

spec:
    replicas: 3
    selector:
        matchLabels:
            app: wordpress
            type: db
    template:   
        metadata: 
        name: wordpress-db
        labels:
            app: wordpress
            type: db
        spec:
            restartPolicy: Always
            containers:
                - name: wordpress-db-container
                  image: mysql:5.7
                  env:
                    - name: MYSQL_ROOT_PASSWORD
                      value: DEVOPS1         

In the above example, the .spec.selector.matchLabels matches the .selector.template.metadata.labels and has a replica of 3 and hence it will always have 3 pods running and if one pod is destroyed, another pod will be created.

4)spec.strategy - optional - default (RollingUpdate)

It specifies the strategy to replace the old pods by new ones. The possible values are RollingUpdate - kill batch or single pods and recreate those but not all and Recreate - all existing Pods are killed before new ones are created

spec:
    replicas: 3
    strategy:
        type: RollingUpdate

Example

apiVersion: apps/v1
kind: Deployment
metadata:
    name: wordpress.db
    labels:
        app: wordpress
        type: db-deployment
spec:
    replicas: 2
    selector:
        matchLabels:
            app: wordpress
            type: db
    template:
        metadata:
            name: wordpress-db
            labels:
                app: wordpress
                type: db
        spec:
            containers:
                - name: wordpress-db-container
                  image: mysql:5.7
                  env:
                  - name: MYSQL_ROOT_PASSWORD
                    value: DEVOPS1
                  ports:
                    - containerPort: 3306
                      name: mysql

Assume that we create another deployment for MySQL with 2 replicas, we have our current setup which we created as below.

We have not actually created the deployment in this post, but we will create a deployment in the forthcoming posts.

These are the basics of deployment which we need to understand to give immortality to the pods (of course pseudo immortality as the entire Kubernetes cluster may go out of commission).