spinnaker

What does each Spinnaker deployment strategy mean?

I would like to know what each strategy means and how they work behind the scenes (i.e., Highlander, Red/Black, Rolling Push). It would be very useful to have this information on the official website.

Thanks

Solution

  • There is useful information out there that can help you with your question, I'll do my best to summarize it below.

    Type and Strategies of Deployments Introduction

    "There are a variety of techniques to deploy new applications to production, so choosing the right strategy is an important decision, weighing the options in terms of the impact of change on the system, and on the endusers."

    1. Recreate: (also known as Highlander) Version A is terminated then version B is rolled out.
    1. Ramped (also known as Rolling-Update or Incremental): Version B is slowly rolled out and replacing version A.
    1. Blue/Green (also known as Red/Black): Version B is released alongside version A, then the traffic is switched to version B.
    1. Canary: Version B is released to a subset of users, then proceed to a full rollout.
    1. A/B Testing: Version B is released to a subset of users under specific condition.
    1. Shadow: Version B receives real-world traffic alongside version A and doesn’t impact the response.

    Type and Strategies of Deployments Summary Table

    enter image description here

    Spinnaker Deployment Strategies

    Spinnaker treats cloud-native deployment strategies as first class constructs, handling the underlying orchestration such as verifying health checks, disabling old server groups and enabling new server groups.

    Spinnaker supported deployment strategies (in active development):

    Illustrated in the Figure below as follows: enter image description here

    1. Highlander: This deployment strategy is aptly named after the film Highlander because of the famous line, "there can be only one." With this strategy, there is a load balancer fronting a single cluster. Highlander destroys the previous cluster after the deployment is completed. This is the simplest strategy, and it works well when rollback speed is unimportant or infrastructure costs need to be kept down.

    2. Red/Black: This deployment strategy is also referred to as Blue/Green. The Red/Black strategy uses a load balancer and two target clusters / server groups (known as red/black or blue/green). The load balancer routes traffic to the active (enabled) cluster / server group. Then, a new deployment replaces servers (w/ K8s provider -> Replica Sets & Pods) in the disabled cluster / server group. When the newly enabled cluster / server group is ready, the load balancer routes traffic to this cluster and the previous cluster becomes disabled. The currently disabled cluster / server group (previously enabled cluster / server groups) is kept around by spinnaker in case a rollback is needed for the next X deployments (which is a configurable parameter).

    1. Rolling Red/Black: is a slower red/black with more possible verification points. The process is the same as red/black, but difference is in how traffic switches over. The above image illustrates this difference. Blue is the enabled cluster. Blue instances are gradually replaced by new instances in the green cluster until all enabled instances are running the newest version. The rollout may occur in 20% increments, so it can be 80/20, 60/40, 40/60, 20/80, or 100%. Both blue/green clusters receive traffic until the rollout is complete.

    2. Canary: deployments is a process in which a change is partially deployed, then tested against baseline metrics before continuing. This process reduces the risk that a change will cause problems when it has been completely rolled out by limiting your blast radius to a small percentage of your user-base. The baseline metrics are set when configuring the canary. Metrics may be error count or latency. Higher-than-baseline error counts or latency spikes kill the canary, and thus stop the pipeline.