Skip to content

Kubernetes Deployment Strategies

Kubernetes Deployment Strategies are methods used to update applications running in a cluster with minimal downtime and risk. While Kubernetes excels at container management, scheduling, and scaling, the strategies themselves are conceptual and can be implemented in various environments^[400-devops-06-kubernetes-k8s-ithelp-day12-readme.md].

An effective deployment strategy ensures service continuity, allows for testing market acceptance, and provides the ability to roll back to previous versions if issues arise^[400-devops-06-kubernetes-k8s-ithelp-day12-readme.md].

Common Strategies

There are six primary deployment strategies commonly discussed in the context of Kubernetes and DevOps^[400-devops-06-kubernetes-k8s-ithelp-day12-readme.md]:

1. Recreate (重建部署)

The Recreate strategy is a heavy-handed approach where the old version of the application is completely shut down before the new version is brought online^[400-devops-06-kubernetes-k8s-ithelp-day12-readme.md]. This results in a period of downtime determined by how long it takes to stop the old service and start the new one.

  • Pros:
    • Easy to set up.
    • Only one version runs at a time.
    • No extra load on the host during deployment^[400-devops-06-kubernetes-k8s-ithelp-day12-readme.md].
  • Cons:
    • Significant downtime impacting users^[400-devops-06-kubernetes-k8s-ithelp-day12-readme.md].

2. Rolling Update (Ramped / 滾動部署)

Rolling Update (or Ramped) is the default strategy in many Kubernetes setups. It gradually replaces instances of the old version with the new version, typically one by one or in small batches^[400-devops-06-kubernetes-k8s-ithelp-day12-readme.md].

Key parameters to control the rate include: * Max Surge: The maximum number of pods that can be created above the desired replica count. * Max Unavailable: The maximum number of pods that can be unavailable during the update^[400-devops-06-kubernetes-k8s-ithelp-day12-readme.md].

  • Pros:
    • More resource-efficient than Blue/Green deployment.
    • Easy to configure; service remains uninterrupted^[400-devops-06-kubernetes-k8s-ithelp-day12-readme.md].
  • Cons:
    • Slow rollout and rollback process (e.g., updating 100 pods takes time).
    • Old and new versions run simultaneously, making debugging difficult if errors occur^[400-devops-06-kubernetes-k8s-ithelp-day12-readme.md].

3. Blue / Green Deployment

In a Blue / Green deployment, a new version (Green) is deployed alongside the existing version (Blue). The Green version is fully tested and brought online before traffic is switched from Blue to Green at the load balancer level^[400-devops-06-kubernetes-k8s-ithelp-day12-readme.md].

  • Pros:
    • Instant release and rollback capability.
    • Avoids version conflicts; effectively only one version serves live traffic at any given moment.
    • Zero downtime^[400-devops-06-kubernetes-k8s-ithelp-day12-readme.md].
  • Cons:
    • Requires double the resources (costly) to maintain both environments.
    • Handling incomplete transactions during the instant switch can be complex^[400-devops-06-kubernetes-k8s-ithelp-day12-readme.md].

4. Canary Deployment

Canary Deployment is a "gray" release strategy, rather than a black-and-white switch. It involves routing a small percentage of traffic (e.g., 10%) to the new version to verify stability before rolling it out to the entire user base^[400-devops-06-kubernetes-k8s-ithelp-day12-readme.md].

The name derives from the historical practice of miners using canaries to detect toxic gases; similarly, this strategy detects "toxic" bugs early^[400-devops-06-kubernetes-k8s-ithelp-day12-readme.md].

  • Pros:
    • Allows for debugging and monitoring with limited user exposure.
    • Fast rollback and iteration^[400-devops-06-kubernetes-k8s-ithelp-day12-readme.md].
  • Cons:
    • Slow full release cycle.
    • Generally only suitable for compatible iterations; incompatible major versions may cause issues^[400-devops-06-kubernetes-k8s-ithelp-day12-readme.md].

5. A / B Testing

A / B Testing is technically a method for making business decisions based on statistics rather than purely a deployment strategy^[400-devops-06-kubernetes-k8s-ithelp-day12-readme.md]. It often utilizes Canary mechanics to route traffic.

Unlike simple Canary releases, A / B Testing routes traffic based on specific parameters (e.g., cookies, User Agent, region) to compare different user experiences (e.g., UI layouts) while the underlying business logic remains the same^[400-devops-06-kubernetes-k8s-ithelp-day12-readme.md].

  • Pros:
    • Multiple versions run in parallel.
    • Full control over traffic distribution^[400-devops-06-kubernetes-k8s-ithelp-day12-readme.md].
  • Cons:
    • Requires sophisticated load balancing (often via cloud services).
    • Harder to debug and pinpoint issues without distributed tracing^[400-devops-06-kubernetes-k8s-ithelp-day12-readme.md].

6. Shadow Deployment

Shadow Deployment involves running the new version alongside the original one and mirroring live traffic to it^[400-devops-06-kubernetes-k8s-ithelp-day12-readme.md]. This allows for performance testing on the new version without affecting real users. The new version only receives the switch once it is proven stable^[400-devops-06-kubernetes-k8s-ithelp-day12-readme.md].

  • Pros:
    • Performance testing against real production traffic without user impact^[400-devops-06-kubernetes-k8s-ithelp-day12-readme.md].
  • Cons:
    • High cost and complexity (double resources).
    • Risk of unexpected side effects (e.g., a "shadow" order being placed in a database if the application writes data)^[400-devops-06-kubernetes-k8s-ithelp-day12-readme.md].

Implementation

While these strategies are conceptual, tools like [[Spinnaker]] provide robust platforms to define and automate these pipelines, integrating with Jenkins for builds and Kubernetes for orchestration^[400-devops-06-kubernetes-k8s-paas-08spinaker.md].

  • Kubernetes
  • [[Continuous Delivery]]
  • [[Spinnaker]]

Sources

  • 400-devops-06-kubernetes-k8s-ithelp-day12-readme.md
  • 400-devops-06-kubernetes-k8s-paas-08spinaker.md