A Deployment Policy suggests how a Service can be deployed and updated. Different update strategies are applied for stateful services and for stateless services to eliminate the downtimes during updates. To understand more about the different deployment strategies, let us introduce you to replicas, desired replicas and revision history.
What are Replicas ?
Replicas are identical instances of a Service deployment. All replicas carry the same set of configurations, like Container definitions and Policies, except for the Persistent Volume mounts. In a stateful Service, each replica can mount the same static volume or a separate instance of a volume which is dynamically provisioned at the time of creating the replica.
Desired Replicas
Desired replicas denote the desired number of replicas for a Service. If a replica is terminated or is unhealthy, Kubernetes creates a new replica to maintain the desired count.
Please note: desired replicas are NOT the same as minAvailable pods in Kubernetes.
Revision History
Revision history is the number of the recent updates and and roll backs that need to be maintained. By default, revision history is set to 10 ie., 10 revisions are maintained and are available for rollback.
Deployment Strategy for Stateless Service
Update Method
1.Rolling Update : Updates replicas in batches. A few replicas can be left to serve the requests while the rest of the replicas are updated. The batch size for update is decided based on the Desired Replica Count, Max Surge and Max Unavailable.
Max Surge: Maximum Number of replicas that can be created in addition to the desired number of replicas at the time of rolling update
Max Unavailable: Maximum Number of replicas that can be unavailable (unhealthy & terminated) at the time of rolling update
2. Recreate : Brings down all the old replicas at once and then brings up new replicas with the desired changes.
Rolling Update Examples
Scenario 1 : If the Desired Replicas is 4, the max surge is 1, the max unavailable is 0, it takes about 4 iterations to update all the replicas and is slower.
Scenario 2: if the Desired Replicas is 4, the max surge is 2, the max unavailable is 2, Kubernetes updates all the replicas in 1 iteration and is faster.
Scenario 3: if the Desired Replicas is 4, the max surge is 0, the max unavailable is 2, Kubernetes updates all the replicas in 2 iterations and is faster than Scenario 1.
Considerations for rolling updates
MaxUnavailable: When a new replica is created, Kubernetes does not route the requests immediately to the new replica until the Health check for the replica succeeds. Thus it is advisable to set maxUnavailable less than and not equal to the desired count so that at least 1 old replica is available to serve the incoming requests. The choice of using higher values for maxUnavailable can be a tradeoff between speed and availability.
Backward compatibility: During the updates, old and new replicas may coexist and serve the requests in parallel. Hence changes in the new version must be backward compatible with the older version.
MaxSurge: The choice of using higher values for maxSurge can be a tradeoff between speed and the resource consumption. In the above example, scenario 1 is slower as it maintains less number of replicas and thus utilize less resource as compared to Scenario 2 which is faster as it brings up more replicas and thus more resource utilization.
Deployment Strategy for Stateful Service
Ordinal Value
Ordinal value is the order in which replicas for a stateful Service were created. The first replica is created with the ordinal value 0 and the ordinal increases as the new replicas are created. You can find the ordinal value of the replicas by examining the services running in an application.
In the left navigation menu, click on Applications and select an application from the applications list.
Under Services, click on [+] to see the list of replicas and its corresponding ordinal value.
Update Method
Rolling Update : Updates the replicas sequentially starting with replicas that have the largest ordinal value. Kubernetes waits until the newly created replica to be ready and running before updating the next replica.
On Delete : Create a new replica only when an old replica is deleted manually
Partition
All replicas with an ordinal greater than or equal to the partition will be updated. The rest of the replicas will not be updated, and even if they are deleted, they will be recreated with the previous version.
Persistent Volumes during Updates
Kubernetes schedules the new replicas on the same node as the old replicas, so that the Persistent Volumes can be reused and re-mounted during updates. No new dynamic volumes are provisioned.
Steps to create Deployment Policy
1.In the left navigation panel, choose Service Policies and click on Deployment Policies.
2. Choose Create new policy to open the policy creation wizard.
3. Choose the Target Service Type to which the policy will be applied.
4. Choose the attributes based on the Target Service Type.
For Stateful Service type, select the deployment strategy, revision history, desired replicas and partition values.
For Stateless Service type, choose the deployment strategy, revision history, maxUnavailable and maxSurge.
5. Click Create to create a new policy.