The contents of this page refer to alpha features in Spinnaker 1.14.
This means we are working on their stability and usability, as well as possibly adding or changing features. Expect rough edges, and file issues as needed.
This guide describes how to take advantage of the Kubernetes V2 provider’s first-class support for common rollout strategies, including dark, highlander, and red/black rollouts.
Rollout Strategy Options
As of version 1.14, you will notice a Rollout Strategy Options section in the Deploy (Manifest) stage. When enabled, these configuration options allow you to associate a workload with one or more services, decide whether the workload should receive traffic, and determine how Spinnaker should handle any previous versions of the workload in the same cluster and namespace.
Select the namespace containing the service(s) you would like to associate with the workload.
Select one or more services you would like to associate with the workload. Spinnaker will add a
traffic.spinnaker.io/load-balancersannotation listing the selected services as described here.
Check this box if you would like the workload to begin receiving traffic from the selected services as soon as it is ready. If you do not check this box, you can add a subsequent Enable (Manifest) stage to begin sending traffic to the workload.
Select a strategy if you would like Spinnaker to handle previous versions of the workload currently deployed to the same cluster and namespace. Select
Noneif you do not want Spinnaker to take any action regarding existing workloads.
Use a dark rollout to deploy a new version of your application alongside the existing version(s), but do not immediately route any traffic to the new version.
Optionally, add subsequent Enable (Manifest) and Disable (Manifest) stage to begin sending traffic to the new version and stop sending traffic to the old version(s).
Use a highlander rollout to deploy a new version of your application alongside the existing version(s), send client traffic to the new version, and then disable and destroy existing versions in the cluster.
Use a red/black rollout to deploy a new version of your application alongside the existing version(s), send client traffic to the new version, and then disable existing versions in the cluster.
Optionally, add subsequent Destroy (Manifest) stages to clean up any unwanted workloads in the cluster.
Alternately, easily roll back to a previous version by configuring an Enable (Manifest) stage or using an ad-hoc Enable operation from the Clusters tab.