Updating an existing Deployment requires you to specify a new container image. That is why we version container images in the first place so that you can roll out, and roll back, application changes as required. As we run everything in containers—and containers, by definition, are ephemeral—this enables a host of different deployment strategies that we can implement. There are several deployment strategies, and some of these are set out as follows:

• Recreate: This isthe simplest of all. Delete the old pod and deploy a new one.

• Rolling update: Slowly roll out the pods of the new version while still running the old version, and slowly remove the old pods as the new pods get ready.

• Blue/green: This is aderived deployment strategy where we keep both versions running simultaneously and switch the traffic to the newer version when we want.

• Canary: This appliesto Blue/Green Deployments where we switch a percentage of traffic to the newer version of the application before fully rolling out the release.

• A/B testing: A/B testing is more of a technique to apply to Blue/Green Deployments. This is when you want to roll out the newer version to a subset of willing users and study the usage patterns before completely rolling out the newer version. You do not get A/B testing out of the box with Kubernetes but instead should rely on service mesh technologies that plug in well with Kubernetes, such as Istio, Linkerd, and Traefik.

Kubernetes provides two deployment strategies out of the box—Recreate and RollingUpdate.

Recreate

The Recreate strategy is the most straightforward deployment strategy. When you update the Deployment resource with the Recreate strategy, Kubernetes immediately spins down the old ReplicaSet resource and creates a new one with the required number of replicas along the lines of the following diagram:

Figure 6.2 – Recreate strategy

Kubernetes does not delete the old ReplicaSet resource but instead sets replicas to 0. That is required to roll back to the old version quickly. This approach results in downtime and is something you want to use only in case of a constraint. Thus, this strategy isn’t the default deployment strategy in Kubernetes.

Tip

You can use the Recreate strategy if your application does not support multiple replicas, if it does not support more than a certain number of replicas (such as applications that need to maintain a quorum), or if it does not support multiple versions at once.

Let’s update nginx-deployment with the Recreate strategy. Let’s look at the nginx-recreate.yaml file:

…

spec:

replicas: 3

strategy:

type: Recreate

…

The YAML file now contains a strategy section with a Recreate type. Now, let’s apply the nginx-recreate.yaml file and watch the ReplicaSet resources using the following command:

$ kubectl apply -f nginx-recreate.yaml && kubectl get replicaset -w

deployment.apps/nginx configured
NAME	DESIRED	CURRENT	READY	AGE
nginx-6799fc88d8	0	0	0	0s
nginx-6889dfccd5	0	3	3	7m42s
nginx-6889dfccd5	0	0	0	7m42s
nginx-6799fc88d8	3	0	0	1s
nginx-6799fc88d8	3	3	0	2s
nginx-6799fc88d8	3	3	3	6s

The Deployment resource creates a new ReplicaSet resource—nginx-6799fc88d8—with 0 desired replicas. It then sets 0 desired replicas to the old ReplicaSet resource and waits for the old ReplicaSet resource to be completely evicted. It then starts automatically rolling out the new ReplicaSet resource to the desired images.