Chapter 9. Deployments: updating applications declaratively

 

This chapter covers

  • Replacing pods with newer versions
  • Updating managed pods
  • Updating pods declaratively using Deployment resources
  • Performing rolling updates
  • Automatically blocking rollouts of bad versions
  • Controlling the rate of the rollout
  • Reverting pods to a previous version

You now know how to package your app components into containers, group them into pods, provide them with temporary or permanent storage, pass both secret and non-secret config data to them, and allow pods to find and talk to each other. You know how to run a full-fledged system composed of independently running smaller components—microservices, if you will. Is there anything else?

Eventually, you’re going to want to update your app. This chapter covers how to update apps running in a Kubernetes cluster and how Kubernetes helps you move toward a true zero-downtime update process. Although this can be achieved using only ReplicationControllers or ReplicaSets, Kubernetes also provides a Deployment resource that sits on top of ReplicaSets and enables declarative application updates. If you’re not completely sure what that means, keep reading—it’s not as complicated as it sounds.

9.1. Updating applications running in pods

9.1.1. Deleting old pods and replacing them with new ones

9.1.2. Spinning up new pods and then deleting the old ones

9.2. Performing an automatic rolling update with a ReplicationController

9.2.1. Running the initial version of the app

9.2.2. Performing a rolling update with kubectl

9.2.3. Understanding why kubectl rolling-update is now obsolete

9.3. Using Deployments for updating apps declaratively

9.3.1. Creating a Deployment

9.3.2. Updating a Deployment

9.3.3. Rolling back a deployment

9.3.4. Controlling the rate of the rollout

9.3.5. Pausing the rollout process

9.3.6. Blocking rollouts of bad versions

9.4. Summary

sitemap