Kubernetes Deployments

This document focuses on the manifest based (aka V2) Kubernetes provider.

Kubernetes Deployments

Armory Spinnaker delegates the deployment of containers to Kubernetes. Kubernetes then proceeds with a rolling update deployment which is effectively a rolling blue/green deployment. Pods are created in batches and when a pod is deemed healthy it starts receiving traffic.


We’ve defined a simple pipeline where we first define an artifact (a Docker image) with a version coming from a pipeline parameter. You’d usually get the image from a trigger via container registry or a Jenkins job with the same result.


The second step defines the deployment of that image. It’s a simple “Deploy (Manifest)” stage. Here we’re adding the static deployment manifest via a text field but you’d usually retrieve it as an artifact directly or via a Helm bake stage.


As a matter of fact, the deployment manifest is not entirely static: Spinnaker will replace the image name with the actual tagged name from the bound artifact.

Let’s see how a new version of the container gets deployed with this pipeline: image

Can we change how containers are deployed?

In our example so far, we observed that we go down to 3 running pods and up to 5 non Terminating pods existing simultaneously. You actually have some control over how Kubernetes handles the pod creation. Two parameters will help you:

  • maxSurge sets a limit on how many pods can be created over the desired number of pods. Default is 25%.
  • maxUnavailable sets a limit on how many pods can be non-running. Default is also 25%.

Let’s modify our deployment manifest and ensure that we always have 4 pods running during deployment:


Let’s see how we deploy with our new configuration: image

We keep 4 pods running throughout the deployment and never more than 5 non Terminating pods (4 pods + 25%) existing at any given time.