Blue-Green Deployments with Spinnaker

Internal

• Blue-Green Deployments
• Spinnaker

Overview

This article documents a pipeline that deploys a release in a Stage environment, waits for testing, removes the release from Stage, and deploys the same release in Prod, while preserving the previous release in Prod. The Stage and Prod are serviced by two different namespaces ('of-stage' and 'of-prod'). The application is a Helm-packaged Kubernetes application, but some of the Kubernetes resources, such as the Ingress and the Service, are created manually directly in Spinnaker, one for each namespace. Also, ReplicaSets are used instead of Deployments, because Spinnaker does not handle Deployments well.

Create Services

Create the ingresses

Create two Services ("stage" and "prod") within the Spinnaker Application.

Load Balancers → Create Load Balancer

Select the right "account" (Kubernetes cluster)

Manifest (do not forget to adjust the namespace):

apiVersion: v1
kind: Service
metadata:
  name: stage
  namespace: of02
spec:
  type: ClusterIP
  selector:
    stage: 'true' # this label will be dynamically applied to the workload pods
  ports:
    - port: 8080
      name: http
      targetPort: 8080

apiVersion: v1
kind: Service
metadata:
  name: prod
  namespace: of02
spec:
  type: ClusterIP
  selector:
    prod: 'true' # this label will be dynamically applied to the workload pods
  ports:
    - port: 8080
      name: http
      targetPort: 8080

Create the Pipeline

It will be a "deploy to stage → manual testing → manual judgement → deploy to prod" pipeline.

Name: "Stage - Manual Testing - Prod" (no "→" allowed in name)

Add stage → Bake (Manifest). Stage name: "Render Helm Chart". This stage will render the helm chart, apply the configuration overlay and overwrite the image tag. For more details, see:

Bake (Manifest)

Add stage → Deploy (Manifest). Stage name: "Deploy in Stage". This stage will deploy the Helm chart and associate the workload with the "stage" service. For more details, see:

Deploy (Manifest)

At this stage, we do enable Rollout Strategy Options, so we can associate the workload with the "stage" service.

Enable: "Spinnaker manages traffic based on your selected strategy" → Service(s) Namespace → Service(s): "stage" → Traffic: Send client requests to new pods → Strategy: "None". ⚠️ "None" is mandatory here, other strategy might delete production.

• Link to detailed explanations of what happens for each of the rollout strategies from the point of view of 1) services 2) replicasets 3) pods.
• Understand the relationship between the replicasets and the Spinnaker cluster

Add stage → Manual Judgement. Stage name: "Wait on Stage Testing"

Add stage → Deploy (Manifest). Stage name: "Deploy in Prod". This stage will deploy the same Helm chart that was tested in Stage and associate the workload with the "prod" service. For more details, see:

Deploy (Manifest)

At this stage, we do enable Rollout Strategy Options:

Enable: "Spinnaker manages traffic based on your selected strategy"

Organizatorium

TO PROCESS:

• https://blog.spinnaker.io/introducing-rollout-strategies-in-the-kubernetes-v2-provider-8bbffea109a
• https://spinnaker.io/docs/guides/user/kubernetes-v2/rollout-strategies/#redblack-rollouts
• https://spinnaker.io/docs/guides/user/kubernetes-v2/traffic-management/
• https://www.opsmx.com/blog/spinnaker-pipeline-blue-green-strategy-with-external-versioning-and-kubernetes-deployment-object/
• https://www.opsmx.com/blog/spinnaker-integration-with-istio/