Continuous Delivery

At the beginning of this book, we started by containerizing our applications, orchestrating them with Kubernetes, persisting their data, and exposing our service to the outside world. Later, we gained more confidence in our services by setting up monitoring and logging, and we made them scale in and out in a fully automatic manner. We'd now like to set our service on course by delivering our latest features and improvements to our services continuously in Kubernetes. We'll learn about the following topics in this chapter:

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

Updating resources

Continuous Delivery (CD), as we described in Chapter 1, Introduction to DevOps, is a set of operations including Continuous Integration (CI) and the ensuing deployment tasks. The CI flow is made up of elements such as version control systems, buildings, and different levels of validation, which aim to eliminate the effort to integrate every change in the main release line. Tools to implement functions are usually at the application layer, which might be independent to the underlying infrastructure. Even so, when it comes to the deployment part, understanding and dealing with infrastructure is still inevitable. Deployment tasks are tightly coupled with the platform our application is running on, no matter which practice, continuous delivery or continuous deployment, we're implementing. For instance, in an environment where the software runs on baremetal...

Building a delivery pipeline

Implementing a CD pipeline for containerized applications is quite simple. Let's recall what practices we learned about Docker and Kubernetes so far and organize those practices into the CD pipeline. Suppose we've finished our code, Dockerfile, and corresponding Kubernetes templates. To deploy these to our cluster, we'd go through the following steps:

1. docker build: Produces an executable and immutable artifact
2. docker run: Verifies whether the build works with a 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

This is all we need for a simple but viable delivery pipeline.

Here, we use the term continuous delivery...

Gaining a deeper understanding of pods

Although birth and death are merely a blink during a pod's lifetime, they're also the most fragile points of a service. We want to avoid common situations such as routing requests to an unready box or brutally cutting all in-flight connections to a terminating machine. As a consequence, even if Kubernetes takes care of most things for us, we should know how to configure our service properly to make sure every feature is delivered perfectly.

Starting a pod

By default, Kubernetes moves 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 the...

Summary

In this chapter, we've discussed topics related to building a continuous delivery pipeline and how to strengthen our deployment tasks. The rolling update of a pod is a powerful tool that allows us to perform updates in a controlled fashion. To trigger a rolling update, what we need to do is change the pod's specification in a controller that supports that rolling update. Additionally, although the update is managed by Kubernetes, we can still control it with kubectl rollout to a certain extent.

Later on, we fabricated an extensible continuous delivery pipeline using GitHub/DockerHub/Travis-CI. We then moved on to learn more about the life cycle of pods to prevent any possible failures, including using the readiness and liveness probes to protect a pod; initializing a pod with init containers; handling SIGTERM properly by picking the right composition of invocation...