With Replica Sets we now have the definition multiple Pods under a specific version.

In order to be able to manage an upgrade or downgrade of a service without having downtime during the upgrade we have to handle multiple instances of both versions during the upgrade.

The objective of Deployment is to handle this process.

For more information about Deployments checkout the Kubernetes User Guide.

In this Tutorial you'll learn how to use Deployments efficiently to scale and upgrade your application without any downtime of your service.

Deployment Nginx

Let's use a Deployment definition to deploy 2 Nginx instances in our Cluster.

Go to the tutorial chart repo and run the deployment-nginx chart.

Here is the Deployment definition:

kind: Deploymentmetadata: name: nginxspec: replicas: 2 selector: matchLabels: app: nginx template: replicaset matchExpressions: - {key: app, operator: In, values: [nginx]} template: metadata: labels: app: nginx template: replicaset spec: containers: - name: nginx image: nginx:1.10-alpine ports: - containerPort: 80 resources: requests: cpu: 100m memory: 100Mi

Now go to the Deployments section. You'll see the nginx deployment with the 2 Pods.

You'll see that the Deployment has generated a Replica Set and that in turn generated 2 Pods.

Scale Up

The Deployment is configured with 2 replicas, but we can update the definition of the Deployment to increase or decrease the number of Pods and that information is delegated to the Replica Set which in turn is responsible of the number of Pods running.

As an example use the buttons to the right of the Deployment in order to increase the number of Pods to 8.

The Pods are being generated and soon they are all in Running state.

Scale Down

Now decrease the number of Pods to 2 again.

The extra number of Pods are being terminated and removed from the cluster.

Upgrade Image

We currently use Nginx v1.10, but there is a new version of Nginx v1.11 we want to deploy to the cluster.

Let's say we have 8 instances of Nginx running, the objective is to change all of them from v1.10 to v1.11 without loosing service availability.

Let's do this from the CLI using kubectl and we'll monitor the progress using Kubernetic.

kubectl set image deployment/nginx nginx=nginx:1.11-alpine

Deployment will then generate a new Replica Set with the new image version and start increasing one by one the number of instances of the new version while decreasing the number of instances of the old version.

Finally the old Replica Set will be left with 0 instances and the new Replica Set with 8.

Downgrade Image

The process for Downgrade in case something goes wrong with the deployment is can be identical to the upgrade, simply change again the version of the image and let deployment handle the update.

kubectl set image deployment/nginx nginx=nginx:1.10-alpine

Rollback Deployment

But there is an even better way to handle this, you don't need to handle which was the previous version of your deployment, Kubernetes has information about the deployment versions and can handle rollback for you.

kubectl rollout undo deployment/nginx


Go to the Releases section

Delete the release of the deployment-nginx-0.1.0 chart.

This will trigger the deletion of all items generated by the Chart.

results matching ""

    No results matching ""