Kubernetes Deployments - A way to scale pods - a way to immortality
Tags: kubernetes, devops, tutorial
Published: 2020-07-20 10:56:41

---
series: 'Kubernetes in Private Cloud'
---

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
<ul>
<li>apiVersion
<li>kind
<li>metadata - name, labels, annotations and other information.
<li>spec - replicas, deployment strategy, pod template, selection and other details.
</ul>

##.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.

```yaml
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.

```yaml
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

```yaml
spec:
	replicas: 3
	strategy:
		type: RollingUpdate
```
Example
```yaml
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.

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/9ii1xqydaphisfwz77k7.jpg)

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).