Using Recreate Strategy with Standard Kubernetes Deployments

Previously, most applications were deployed with what today we call the recreate strategy which we will discuss shortly. For now, we’ll focus on implementing it and observing the outcome.

Changing deployment to Recreate strategy

By default, Kubernetes Deployments use the RollingUpdate strategy. If we do not specify any, that’s the one that is implied. We’ll get to that one later. For now, what we need to do is add the strategy into the deployment.yaml file that defines the deployment.

We entered the local copy of the jx-progressive repository, and we used a bit of sed magic to increase the number of replicas in values.yaml and to add the strategy entry just above replicas in deployment.yaml. If you are not a sed ninja, that command might have been confusing, so let’s output the file and see what we got.

The output, limited to the relevant section, is as follows.

Pushing the changes and observing the outcome

Now that we changed our deployment strategy to recreate, all that’s left is to push it to GitHub, wait until it is deployed, and observe the outcome. Right?

We pushed the changes, and we started watching the activities. Please press ctrl+c to cancel the watcher once you confirm that the newly launched build is finished.

If you’re using serverless Jenkins X, the build of an application does not wait for the activity associated with automatic promotion to finish. So, we’ll confirm whether that is done as well.

⚠️ Please execute the command that follows only if you are using serverless Jenkins X.

You know what needs to be done. Press ctrl+c when the build is finished.

Checking the Pods

Let’s take a look at the Pods we got.

The output is as follows

There’s nothing new here. Judging by the look of the Pods, if we did not change the strategy to Recreate, you would probably think that it is still the default one. The only difference we can notice is in the description of the deployment, so let’s output it.

Inspecting the description of the deployment

The output, limited to the relevant part, is as follows.

Judging by the output, we can confirm that the StrategyType is now Recreate. That’s not a surprise. What is more interesting is the last entry in the Events section. It scaled replicas of the new release to three. Why is that a surprise? Isn’t that the logical action when deploying the first release with the new strategy? Well… It is indeed logical for the first release so we’ll have to create and deploy another to see what’s really going on.

If you had Knative deployment running before, there is a small nuisance we need to fix. Ingress is missing, and I can prove that.

The output claims that no resources were found.

⚠️ Non-Knative users will have Ingress running and will not have to execute the workaround we are about to do. Feel free to skip the few commands that follow. Alternatively, you can run them as well. No harm will be done. Just remember that their purpose is to create the missing Ingress that is already running and that there will be no visible effect.

Why is Ingress missing and how to fix it?

What happened? Why isn’t there Ingress when we saw it countless times before in previous exercises?

Jenkins X creates Ingress resources automatically unless we tell it otherwise. You know that already. What you might not know is that there is a bug (undocumented feature) that prevents Ingress from being created the first time we change the deployment type from Knative to plain-old Kubernetes Deployments. That happens only when we switch and not in consecutive deployments of new releases.

So, all we have to do is deploy a new release, and Jenkins X will pick it up correctly and create the missing Ingress resource the second time. Without it we won’t be able to access the application from outside the cluster. So, all we have to do is make a trivial change and push it to GitHub. That will trigger yet another pipeline activity that will result in ...