Kubernetes Deployment Strategy - Recreate

Recreate is the simplest deployment strategy. A recreate deployment would go something like this. Version 1 of the app is deployed. Deployment starts, all pods running version 1 of the app are deleted. Immediately followed by version 2 of the application being deployed. The biggest draw back with recreate deployments is the small window of downtime.

Manual Recreate Deployment

The self healing nature of Kubernetes makes a manual recreate deployment very easy. Because the ReplicationController or ReplicaSet managing the pods of your application will replace terminated pods you can simply modify the template of them prior to deleting the pods and it will deploy newer pods for you using the updated image specified in the template.

Recreate Deploys with Kubernetes Deployment Resource

The Kubernetes Deployment resource provides declarative updates to your applications. In the previous example you had to think through the update process. You had to figure out what commands to run and in which order to run them. With the Deployment resource you define the strategy you want to use and set the behaviors you want to see and Kubernetes figures out the rest. Converting our update to use the Deployment resource vs. using kubectl looks like this.

The Deployment resource can be thought of as a wrapper around your replication controller or replicaset. By default the Deployment resources strategy is to perform a rolling update. You can change that by defining .spec.strategy.type as Recreate. Reference line 13 in the above manifest.

What Happened?

When using a Recreate deployment strategy in Kubernetes, the following actions occur.

1. The Deployment resource created a ReplicaSet that was using v1 of the container image.
2. The ReplicaSet created 3 pods using v1 image.
3. The image in the deployment was changed to v2.
4. The Kubernetes noticed this change and created a new ReplicaSet that uses v2 of the image.
5. Kubernetes set the ReplicaSet using v1 replica count to 0.
6. The v1 ReplicaSet deleted all of its pods.
7. Kubernetes changed the replica count on the v2 ReplicaSet to 3.
8. The v2 ReplicaSet created 3 new pods all using v2 of the image.
9. Update complete!

When to Use

1. Your application can withstand a short amount downtime.
2. When your application does not support having new and old versions of your application code running at the same time.

Labs & Code Samples

All the manifests and cost samples can be found in this repo or in the gits linked in the post.