Continuous Delivery

Topics we've discussed so far enable us to run our services in Kubernetes. With the monitoring system, we've gained more confidence in our service. The next thing we'd like to achieve to set our service on course is how to deliver our latest features as well as ameliorations to our service continuously in Kubernetes, and we'll learn it with the following topics in this chapter:

• Updating Kubernetes resources
• Setting up a delivery pipeline
• Techniques to improve the deployment process

Updating resources

The property of Continuous Delivery is as what we described in Chapter 1, Introduction to DevOps, a set of operations including the Continuous Integration (CI) and ensuing deployment tasks. The CI flow comprises elements like version control systems, buildings, and different levels of automated tests. Tools to implement CI functions are usually at the application layer which can be independent to underlying infrastructure, but when it comes to achieving deployment, understanding and dealing with infrastructure is inevitable since the deployment tasks are tightly bound to the platform that our application is running on. In the environment that software runs on physical or virtual machines, we'd utilize configuration management tools, orchestrators, and scripts to deploy our software. However, if we're running our service on an application platform like...

Building a delivery pipeline

Implementing a continuous delivery pipeline for containerized applications is quite simple. Let's remember what we have learnt about Docker and Kubernetes so far and organize them into the CD pipeline. Suppose we've done our code, Dockerfile, and corresponding Kubernetes templates. To deploy them to our cluster, we'd go through the following steps:

1. docker build: Produces an executable immutable artifact.
2. docker run: Verifies if the build works with some simple test.

3. docker tag: Tags the build with meaningful versions if it's good.
4. docker push: Moves the build to the artifacts repository for distribution.
5. kubectl apply: Deploys the build to a desired environment.
6. kubectl rollout status: tracks the progress of deployment tasks.

That's all for a simple but viable delivery pipeline.

...

Gaining deeper understanding of pods

Although the birth and the death are merely a wink during a pod's lifetime, they are the most fragile point of a service. Common situations in the real world such as routing requests to an unready box, or brutally cutting all in-flight connections to a terminating machine, are all what we want to avoid. As a result, even Kubernetes takes care of most things for us, and we should know how to configure it correctly to gain more confident in deploying.

Starting a pod

By default, Kubernetes transfers a pod's state to Running as soon as a pod launches. If the pod is behind a service, the endpoint controller registers an endpoint to Kubernetes immediately. Later on kube-proxy observes...

Summary

In this chapter, we've discussed topics not only on building a continuous delivery pipeline, but also on techniques to strengthen our every deployment task. The rolling update of pods is a powerful tool that performs updates in a controlled fashion. To trigger a rolling update, what we need to do is update the pod's specification. Although the update is managed by Kubernetes, we can still control it with kubectl rollout.

Later on, we fabricated an extensible continuous delivery pipeline by GitHub/DockerHub/Travis-CI. Next, we moved our steps to learn more about the life of pods to prevent any possible failure, including using the readiness and liveness probe to protect a pod, initializing a pod with Init containers, handling SIGTERM properly by writing Dockerfile in the exec form, leveraging life cycle hooks to stall a pod's readiness as well as its termination...