Gateway kubernetes deployment
search cancel

Gateway kubernetes deployment


Article ID: 262682


Updated On:


CA API Gateway


Customer deploying kubernetes gateway cluster looking for what options are available for updateStrategy.type   Deployment Strategy



Release : 10.1


Gateway charts use the default rolling strategy 

Kubernetes Deployment strategies:

  • Rolling deployment—replaces pods running the old version of the application with the new version, one by one, without downtime to the cluster.
  1. Recreate—terminates all the pods and replaces them with the new version.
  2. Ramped slow rollout—rolls out replicas of the new version, while in parallel, shutting down old replicas. 
  3. Best-effort controlled rollout—specifies a “max unavailable” parameter which indicates what percentage of existing pods can be unavailable during the upgrade, enabling the rollout to happen much more quickly.
  4. Canary deployment—uses a progressive delivery approach, with one version of the application serving most users, and another, newer version serving a small pool of test users. The test deployment is rolled out to more users if it is successful.


A rolling deployment is the default deployment strategy in Kubernetes. It replaces the existing version of pods with a new version, updating pods slowly one by one, without cluster downtime. 


The rolling update uses a readiness probe to check if a new pod is ready, before starting to scale down pods with the old version. If there is a problem, you can stop an update and roll it back, without stopping the entire cluster. 


To perform a rolling update, simply update the image of your pods using kubectl set image. This will automatically trigger a rolling update.


To refine your deployment strategy, change the parameters in the spec:strategy section of your manifest file. There are two optional parameters—maxSurge and maxUnavailable: 


MaxSurge specifies the maximum number of pods the Deployment is allowed to create at one time. You can specify this as a whole number (e.g. 5), or as a percentage of the total required number of pods (e.g. 10%, always rounded up to the next whole number). If you do not set MaxSurge, the implicit, default value is 25%.

MaxUnavailable specifies the maximum number of pods that are allowed to be unavailable during the rollout. Like MaxSurge, you can define it as an absolute number or a percentage. 

At least one of these parameters must be larger than zero. By changing the values of these parameters, you can define other deployment strategies, as shown below