What are the Deployment Strategies in Kubernetes?

Deployment Strategies in Kubernetes

Kubernetes Deployment strategies replace Pods with new application versions. Controlling resource utilization, application availability, and rollout pace requires the right technique. The deployment manifest’s .spec.strategy outlines various tactics.

Rolling Update Strategy (Default)

In Kubernetes, the default approach is RollingUpdate. By progressively reducing outdated ReplicaSets and increasing a new one, it offers a systematic, scaled migration from one version of an application to a newer one.

• Mechanism: Throughout the update, it maintains a minimum percentage of healthy clones to guarantee that the program stays accessible. The Deployment controller updates the entire set by first creating a new Pod and then removing an old one.
• Key Parameters: Two extra fields allow administrators to fine-tune this process:
  • Max Unavailable: This indicates how many Pods may be inaccessible at most during the upgrade. It may be expressed as a percentage (the default is 25%) or as an absolute figure.
  • Max Surge: This indicates the highest number of Pods that can be produced in excess of the intended replica count. For instance, the new ReplicaSet can scale up instantly if it is set to 30% such that the total number of old and new Pods does not beyond 130% of the intended state.
• Benefits: No downtime, easy transfer.
• Drawbacks: Two copies of the program will serve traffic simultaneously, which can take time.

You can also read What is Kubernetes Cloud Controller Manager?

Recreate Strategy

A more straightforward method is the Recreate strategy, which terminates all current Pods before creating any new ones.

1. Mechanism: The controller instantly terminates all Pods of the previous revision when a deployment is upgraded. Before starting to create new revision Pods, it must be successfully removed.
2. Use Cases: This approach is frequently employed for systems that cannot manage two versions operating simultaneously because of data consistency or singleton constraints, or in development settings where user activity is not a major concern.
3. Drawbacks: During the time between the old version’s shutdown and the new version’s ready, there will unavoidably be service outages.

Blue/Green Deployment

A Blue/Green strategy is implemented by maintaining two distinct environments, albeit it is not a built-in “type” in the Deployment specification like RollingUpdate or Recreate.

• Mechanism: The “green” version is the latest release, while the “blue” version is the stable environment as of right now. Alongside the blue version, the green version is tested and deployed in production. The administrator modifies the Service selection label to point to the green Pods after verification.
• Benefits: Because traffic is transferred all at once, it provides a quick transition and prevents versioning problems. By only changing the Service label back to the blue version, it also enables almost instantaneous rollbacks.
• Drawbacks: Because both the old and new versions must operate at full capacity until the cutover is finished, this approach doubles resource use.

You can also read What is a Kubernetes Controller Manager?

Canary Deployment

Before a formal release, a new version is made available to a select group of users or servers through a canary deployment.

1. Mechanism: A new version operating on a reduced selection of Pods is directed to a limited number of users. A second deployment with fewer replicas and the service’s new image and labels is often needed.
2. Advanced Traffic Splitting: Service meshes like Istio control traffic flow specifics (5% new, 95% stable) for complex canary releases. It can be turned back without affecting most users if the “canary” version exhibits problems.
3. Benefits: It allows for testing new functionality in a real-world production environment with minimal risk. If the “canary” version shows issues, it can be rolled back without impacting the majority of users.

Shadow (Mirroring)

Mechanism: A copy of the live traffic is transferred to the new version, but its responses are never provided to the user and are destroyed.

Best for:  Testing data consistency, load, and performance under actual production demand without endangering user experience.

A/B Testing

• Mechanism: Based on cookies or geography, specific user segments are directed to different versions to compare business KPIs and user behavior.
• Use it to make data-driven decisions, validate UX improvements, or compare feature implementations.
• Benefits: Data-driven decisions. comprehensive traffic allocation control.
• Drawbacks: Needs a service mesh and complicated routing algorithms. To collect data that is statistically significant, there must be enough traffic.

You can also read Kind: A Practical Guide to Local Kubernetes Clusters

Management and Rollout Controls

Kubernetes offers a number of tools for efficiently managing these tactics:

• Rollerbacks: Kubernetes defaults to the last ten rollouts. If a rollout fails due to image pull difficulties or readiness probe failures, administrators can use kubectl rollout undo to restore stability.
• Pausing and Resuming: A rollout can be halted to make several modifications to a Pod template, such as upgrading the image and resource limitations, without generating multiple rollouts. After improvements are made, the rollout is repeated to apply all updates concurrently.
• Readiness Probes: The Deployment controller uses readiness probes to check if a new Pod can receive traffic. If Pods fail these probes, the deployment may stop to prevent a faulty version from shutting down the service.
• Progress deadlines: The .spec.progressDeadlineSeconds field controller should wait Seconds before declaring a rollout failure. Higher-level orchestrators can monitor this condition and act, even if Kubernetes does not automatically roll back on timeouts.
• Proportional Scaling: The controller applies proportionate scaling when a deployment is scaled manually or by an autoscaler during a RollingUpdate. To reduce the chance of overloading the new, possibly untested version, it distributes the extra copies across the active ReplicaSets according to their existing size.

You can also read How to Get Started Kubernetes? Explained Briefly