Hi all,

In my previous blog I shared my experience creating environments dynamically using the default deployment strategy provided by helm ( “rolling” ), but sometimes you could need to implement some more complex deployment strategies like in your “prd” environment.

I can name a few common deployment strategies in k8s world like blue green, canary, rolling, canary preview, canary preview vs baseline, and them could be implemented in minutes in your SAP CAP application for SAP Kyma Runtime using Argo Rollouts, yes another fantastic controller that will manage the creation, scaling, and deletion of Replica-sets.

Uses cases for Argo Rollouts:

• A user wants to run last-minute functional tests on the new version before it starts to serve production traffic. With the BlueGreen strategy, Argo Rollouts allows users to specify a preview service and an active service. The Rollout will configure the preview service to send traffic to the new version while the active service continues to receive production traffic. Once a user is satisfied, they can promote the preview service to be the new active service. (example)
• Before a new version starts receiving live traffic, a generic set of steps need to be executed beforehand. With the BlueGreen Strategy, the user can bring up the new version without it receiving traffic from the active service. Once those steps finish executing, the rollout can cut over traffic to the new version.
• A user wants to give a small percentage of the production traffic to a new version of their application for a couple of hours. Afterward, they want to scale down the new version and look at some metrics to determine if the new version is performant compared to the old version. Then they will decide if they want to roll out the new version for all of the production traffic or stick with the current version. With the canary strategy, the rollout can scale up a ReplicaSet with the new version to receive a specified percentage of traffic, wait for a specified amount of time, set the percentage back to 0, and then wait to rollout out to service all of the traffic once the user is satisfied.
• A user wants to slowly give the new version more production traffic. They start by giving it a small percentage of the live traffic and wait a while before giving the new version more traffic. Eventually, the new version will receive all the production traffic. With the canary strategy, the user specifies the percentages they want the new version to receive and the amount of time to wait between percentages.
• A user wants to use the normal Rolling Update strategy from the deployment. If a user uses the canary strategy with no steps, the rollout will use the max surge and max unavailable values to roll to the new version.

Before going deeper in the changes to perform in your SAP CAP application to implement these deployment strategies provided by Argo Rollouts I would make a few generic comments:

• To let to Argo Rollouts to manage your replica-sets you need to just replace the “apiVersion” & “kind” of your deployment.yaml file to:
  • apiVersion: argoproj.io/v1alpha1
  • kind: Rollout
• And finally you need to set desired strategy parameters

Too much theory let’s try it 😉

1-Blue Green

In this deployment strategy a new replica-set is created after a change is detected by the controller with the same amount of replicas with a post fix “-preview”, so in a point of time you have 2 versions of your SAP CAP application running in parallel, depending of your configurations you can expose or not the new created replica with the new changes:

1-Blue green – definition 1/3 – rollout

1-Blue green – definition 2/3 – service preview

1-Blue green – definition 3/3 – api rule preview

After deploying your SAP CAP application you will see the following application created in Argo CD, pay attention to the rollout & preview objects:

1-Blue green – result 1/4 – deployed app

You can see bellow the deployed application from network point of view, there are two services ( the productive & preview one ) pointing to the same pods:

1-Blue green – result 2/4 – networking

After applying changes & sync them into Argo CD the controller will create new pods with the latest changes and those pods can be accessed from the preview service:

1-Blue green – result 3/4

After that you “promote” the “preview” version you will see that the old pods are replaced by the new ones:

1-Blue green – result 4/4

2-Rolling

This deployment strategy is doing exactly the same than the deployment object in k8s, just adding new pods and removing the old ones:

1-Rolling – definition 1/1

Deploy the SAP CAP application using Argo CD, and you will see:

1-Rolling – result 1/3

Bellow you can find the network view of the app:

1-Rolling – result 2/3

Here there is no human intervention, just rolling the new version of the pods and removing the old ones

1-Rolling – result 3/3

3-Canary

Things start to get interesting with this deployment strategy, the controller will create a new replica-set with new pods and removing old pods, but you can set “steps” where you specify the time to wait for next step to execute or if you set it as empty then human approval is required to continue with the deployment and also you can specify the weight:

3-Canary – definition 1/1

You deploy the SAP CAP application using Argo CD:

3-Canary – result 1/3

Network point of view of the app:

3-Canary – result 2/3

After a change is made & sync. you will see how the replica-set is creating and removing pods following the steps desired:

3-Canary – result 3/3

4-Canary preview

As you can imagine with this deployment strategy the replica-set will be able to generate a preview pod with the new version of your application for a certain time defined and later will execute the steps of your desired strategy:

4-Canary preview – definition 1/5

4-Canary preview – definition 2/5

4-Canary preview – definition 3/5

4-Canary preview – definition 4/5

4-Canary preview – definition 5/5

After that you change & sync the SAP CAP application you are able to see the new pod:

4-Canary preview – result 1/3

From network point of view you are able to test this new version for a period of time without affecting the productive pods

4-Canary preview – result 2/3

After sometime the roll out continue as desired

4-Canary preview – result 3/3

5-Canary vs baseline

Last but not least this deployment strategy creates a preview and a baseline after a new change is sync, the preview contains a the new version of the application and the baseline contains the old version of your application without affecting the productive application

5-Canary vs baseline – definition 1/7

5-Canary vs baseline – definition 2/7

5-Canary vs baseline – definition 3/7

5-Canary vs baseline – definition 4/7

5-Canary vs baseline – definition 5/7

5-Canary vs baseline – definition 6/7

5-Canary vs baseline – definition 7/7

After made & sync the changes to your application you will see how the new pods are added:

5-Canary vs baseline – result 1/3

From networking point of view: current pods + preview + baseline

5-Canary vs baseline – result 2/3

After that you perform your testing the roll out continues and the preview & baselines are deleted

5-Canary vs baseline – result 3/3

I hope that after seeing all these deployment strategies provided by Argo Rollouts you will think twice before use the “rolling” default deployment strategy in production 🙂

Kind Regards.

Max.