148422597X Kubernetes Management Design Patterns [Vohra 2017-01-29] {E559F6BB}

CHAPTER 8
Using Rolling Updates
It is common for a replication controller specification or a container image to be updated. If a replication
controller is created from an earlier image or definition file, the replication controller will need to be updated.
Problem
If the Docker image or controller specification for a replication controller has been updated while the replication
controller’s pods are running, the replication controller will need to be deleted and a new replication controller
created based on the updated Docker image or controller specification. Shutting down an application will
cause the application to become unavailable. One of the DevOps and Agile software development best
practices is Continuous Deployment. The objective of Continuous Deployment is to minimize the lead time
between a new application release/build being developed and being used in production.
Solution
During a rolling update, pods for any earlier version replication controller are terminated and pods for the
new controller started. The earlier version pods are shut down using a “graceful termination” mechanism,
which provides a callback into a container a configurable amount of time before the container is terminated
to allow the container to shut down gracefully, which implies that the in-memory state of the container is
persisted and the open connections are closed. The “graceful termination” mechanism Kubernetes makes
use of is a single-container management design pattern.
As shown in Figure 8-1, for the rolling update of a replication controller RC1 to RC2, RC1 initially has
three pods and RC2 no pods. In the next phase, RC1 has two pods and RC2 one pod. In the third phase RC1
has one pod and RC2 two pods. When the rolling update is completed RC1 has no pods and RC2 three pods.
The rolling update is performed one pod at a time.
© Deepak Vohra 2017
D. Vohra, Kubernetes Management Design Patterns, DOI 10.1007/978-1-4842-2598-1_8
171