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
- metadata - name, labels, annotations and other information.
- spec - replicas, deployment strategy, pod template, selection and other details.
The Pod Template or
.spec.selector are the only mandatory fields of 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
.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.
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.
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
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).