Spinnaker Speak for Kubernetes Users

With the rapid adoption of Docker and Kubernetes many people are looking for new tools to support the new infrastructure that is being created by this change.

Many folks interested in Spinnaker ask us ‘But does it work well with Kubernetes?’. Not only does it work well together, Spinnaker’s deployment model matches the tenants of Kubernetes perfectly. Below I’ll translate the Spinnaker nomenclature to Kubernetes concepts.

Instances – Instances are the equivalent to Kubernetes pods. Pods are a collection of container and used to represent one instance of an entire stack.

Server Groups – These groups are equivalent to replication controllers within Kubernetes. Note, that replication controllers (service groups) have version numbers within Spinnaker in the form of v0XXX so that you know what version matches the pipeline and thus the build of the app making it simple to know exactly what is in each server group. Wether you use the UI or have applications already deployed to your Kubernetes cluster, Spinnaker will create or pull the yaml from Kubernetes making it simple to see what properties are in the particular server group.

Clusters – Clusters are a grouping of server groups that may contain multiple versions of server groups. This allows you to roll back/forward or canary easily. See below of a screenshot of what a disabled server group looks like

Load Balancers – Load balancers are services within Kubernetes. This allows you to easily & quickly associate clusters to services (load balancers) to expose the service within the Kubernetes cluster or externally to the internet. Just like server groups, YAMLs are created on the backend for the service. The Kind is Service which is different than the ReplicationController you see in the server group screen shots.

Baking – This term comes from “Baking an AMI” or creating an image from a template VM on AWS. In docker speak, its simply building an image and pushing the image to a docker registry of your choice. Because creating an image with Docker is trivial you will almost never use a ‘baking’ step with the exception if you want to port any of your non-kubernetes applications.