TL;DR — Spinnaker’s advanced deployment strategies, including canary, blue‑green, and rolling updates, let you reduce risk while accelerating release velocity. By integrating with Kubernetes, Istio, and cloud load balancers, you can automate traffic shifting, automated rollback, and multi‑cluster coordination. This post walks through the architecture and practical patterns you need to master for production‑grade continuous delivery.

Spinnaker has evolved from a simple deployment tool into a full‑fledged continuous delivery platform that orchestrates releases across multiple clouds and on‑premises data centers. For engineering teams already running Kubernetes, Spinnaker offers a declarative way to define pipelines, enforce gating rules, and execute sophisticated deployment patterns without writing bespoke scripts. In this article we’ll explore the core components that make Spinnaker tick, then dive into canary, blue‑green, rolling, and A/B deployment strategies, and finally discuss patterns that have proven reliable in production environments.

Architecture Overview

Spinnaker’s architecture is composed of several microservices that each own a slice of the pipeline lifecycle:

  • Deck – the web UI that lets users visualize pipelines and trigger manual stages.
  • Gate – the API gateway that authenticates requests and routes them to downstream services.
  • Orca – the orchestration engine that executes pipeline stages, manages task state, and handles retries.
  • Rosco – builds machine images (AMIs, container images) used by later stages.
  • Front50 – stores pipeline configurations and metadata in a versioned store.
  • Clouddriver – abstracts cloud provider specifics (AWS, GCP, Azure) and provides a unified resource model.

These services communicate via a combination of REST APIs and a message bus (typically Kafka or Pub/Sub), allowing Spinnaker to scale horizontally and survive partial outages. When integrated with Kubernetes, Clouddriver can read cluster state directly via the Kubernetes API, while Orca can invoke kubectl or use the Spinnaker‑provided Kubernetes provider to create, update, or delete resources.

A typical pipeline consists of the following stages:

  1. Source – pull code from a repository (e.g., GitHub) and trigger on push.
  2. Build – compile the application and produce a Docker image tag.
  3. Deploy (Canary) – push the new image to a small subset of pods.
  4. Analysis – evaluate metrics (error rate, latency) to decide whether to proceed.
  5. Deploy (Full) – roll out the new version to the entire fleet.
  6. Cleanup – optionally remove old replica sets or images.

Advanced Deployment Strategies

Canary Deployments

Canary releases expose a new version to a small percentage of traffic, allowing you to validate correctness before a full rollout. Spinnaker can drive canary traffic using:

  • Istio virtual services to split traffic by weight.
  • NGINX Ingress annotations to route based on header or cookie.
  • AWS ALB listener rules for HTTP traffic.

The pipeline stage Canary in Spinnaker accepts a JSON configuration that specifies the traffic split, the analysis interval, and the criteria for promotion or rollback. Below is an example of a canary stage definition in YAML:

- name: canary
  type: canary
  context:
    traffic:
      - set: canary
        weight: 10
    analysis:
      interval: 30
      templates:
        - name: error-rate
          expression: |
            sum(rate(http_requests_total{code=~"5.."}[5m])) /
            sum(rate(http_requests_total[5m]))
      threshold: 0.01
      action: rollback

In this snippet, 10 % of traffic is routed to the canary version. The analysis template computes the error rate over a five‑minute window; if it exceeds 1 %, Spinnaker automatically rolls back to the previous stable version.

Blue‑Green Deployments

Blue‑green releases maintain two identical production environments (blue and green). At any moment, only one environment serves live traffic. Swapping is instantaneous because it involves updating the load balancer target group or DNS record.

Spinnaker models this with Server Group management. You create a new server group with the updated image, run health checks, and then perform a “Enable/Disable” operation on the load balancer to shift traffic. The advantage is zero downtime; the downside is the need for duplicate infrastructure during the transition.

A simplified Spinnaker stage for blue‑green looks like:

- name: deploy-green
  type: deploy
  context:
    cloudProvider: kubernetes
    application: myapp
    stack: green
    target:
      type: serverGroup
      name: myapp-green

After successful health checks, you can use a “Manual Judgment” stage or an automated “Traffic Shift” stage to switch the load balancer to the green server group.

Rolling Updates

Rolling updates replace pods incrementally, ensuring that at least a configurable number of pods remain available. This is the default strategy for Kubernetes Deployment objects. Spinnaker can orchestrate a rolling update by:

  1. Creating a new replica set with the new image.
  2. Scaling the new set up while scaling the old set down.
  3. Monitoring pod readiness and container health.

The maxSurge and maxUnavailable fields control the pace. In Spinnaker’s UI you can set these under the “Rolling” strategy:

strategy:
  type: rolling
  rolling:
    maxSurge: 1
    maxUnavailable: 0

Because Spinnaker reads the Kubernetes API, it can detect when the new pods become ready and automatically proceed, or pause for manual approval if you configure a “Manual Judgment” stage.

A/B Testing and Feature Flags

A/B testing requires routing distinct user segments to different versions of a service. While Spinnaker does not replace a dedicated feature‑flag service, it can integrate with tools like LaunchDarkly or Unleash to toggle features. The typical flow is:

  • Deploy two canary server groups (A and B).
  • Use a feature‑flag service to assign users to variant A or B.
  • Collect business metrics (conversion, click‑through) via your observability stack.
  • Promote the winning variant to 100 % traffic.

Spinnaker can automate the data collection by invoking a custom script in a “Script” stage, then feeding the result into a “Decision” stage that determines promotion.

Patterns in Production

Multi‑Cluster Coordination

Many organizations run workloads across multiple Kubernetes clusters (e.g., regional clusters for latency). Spinnaker can deploy to several clusters sequentially or in parallel using “Parallel” stages. To maintain consistency, you should:

  • Store pipeline definitions in a versioned repository (e.g., Git) and use Spinnaker’s pipeline‑as‑code feature.
  • Tag each deployment with a unique application version to simplify rollback.
  • Leverage Spinnaker’s “Cluster” provider to target specific clusters by name.

Canary Analysis with Prometheus

Integrating Prometheus metrics into canary analysis is a common production pattern. Spinnaker’s Canary Analysis stage supports custom expressions that query Prometheus. For example, to detect a rise in 5xx errors:

analysis:
  templates:
    - name: prometheus-5xx
      expression: |
        sum(rate(http_requests_total{code=~"5.."}[2m])) /
        sum(rate(http_requests_total[2m]))
      threshold: 0.005

If the ratio exceeds 0.5 %, Spinnaker triggers a rollback, providing automated safety nets.

Immutable Infrastructure and Image Tagging

Adopting an immutable approach means each deployment creates a new server group with a unique container image tag. Spinnaker encourages this by generating tags from the commit SHA. A best‑practice pipeline includes:

  • Build stage that pushes the image to a registry with a tag like {{version}}-{{git.sha}}.
  • Deploy stage that references the exact tag, eliminating “it works on my machine” issues.
  • Cleanup stage that prunes old server groups after a retention period.

Security and Compliance

In regulated environments, you may need to enforce that only signed images are deployed. Spinnaker can integrate with Notary or Cosign via a “Webhook” stage that validates the image signature before proceeding. Additionally, you can use OPA (Open Policy Agent) policies to block deployments that lack required labels or annotations.

Key Takeaways

  • Spinnaker abstracts cloud‑specific APIs, letting you define deployment strategies declaratively.
  • Canary, blue‑green, and rolling updates each serve distinct risk tolerance and downtime requirements.
  • Automated analysis driven by Prometheus or custom scripts enables safe, data‑backed promotions.
  • Multi‑cluster pipelines and immutable image tagging are essential for scaling CD across organizations.
  • Embedding security checks (signature verification, OPA) into the pipeline ensures compliance without sacrificing velocity.

Further Reading