Scalable Spark Deployment using Kubernetes - Part 9 : Service Update and Rollback

In last few blog posts on kubernetes, we have discussed about how to build and scale spark cluster. Once services are deployed, we also
need to update services time to time. When we update a service, we need to make sure that, it don’t interrupt the working of other
services. Kubernetes has built in support for the service update and rollbacks. This makes changing services on kubernetes
much easier than doing them manually in other platforms.

In this ninth blog of the series, I will be discussing about service update and rollback in kubernetes.
You can access all the posts in the series here.

Updating Service

In our discussion of deployment abstraction, I told that deployment helps us to handle life cycle of a service. Currently,
we are running the spark version 2.1.0. Let’s say we want to change it to 1.6.3 without changing the
configuration. We can use deployment abstraction for achieving the same.

The below are the steps to change spark version from 2.1.0 to 1.6.3 using deployment abstraction.

1. Generate Spark Image for 1.6.3

As we did for spark 2.1.0, we first need to have an image of the spark 1.6.3. This can be easily done by changing docker file as below.

ENV spark_ver 1.6.3

Once we update the docker file, we need to build new image with below command.

docker build -t spark-1.6.3-bin-hadoop2.6 .

Now we have our new spark image ready.

2. Set Images to Deployment

The below two commands sets new images to already running spark-master and spark-worker deployments

The above commands reverses the spark version back to 2.1.0. This ability to quickly undo the service is
powerful. If something goes wrong, we can rollback the service to it’s previous state without much effort.

Conclusion

Kubernetes has native support for service update and rollback. Using deployment abstraction we can easily roll out the changes to
our services without effecting other services.