Spinnaker Speak for Kubernetes Users

Aug 22, 2016 by Ben Mappen

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.

Share this post:

Recently Published Posts

Navigating AWS Deployment Targets with Armory

Jan 20, 2023

Many organizations look to Amazon Web Services (AWS) to host and deploy their applications in the cloud. However, they’re finding that their deployment tooling, often built as an extension of their legacy continuous integration (CI), is one of the main impediments to adopting cloud services.  Custom-scripted production pipelines built with in-house tooling need to be […]

Read more

Release Roundup – January 2023

Jan 11, 2023

Get the latest product news on Continuous Deployment-as-a-Service and the most recent release for Continuous Deployment Self Hosted, 2.28.2. Welcome to 2023!  Just like every organization, Armory is looking for ways to improve our practices and deliver more value (and faster!) to you, our customers. That’s why our engineering team is working to deliver features, […]

Read more

Learn Continuous Deployment with Armory and Wilco

Jan 6, 2023

Armory is excited to announce we have launched an interactive, narrative-driven developer experience that teaches continuous deployment concepts. And now you can try it out for yourself! Wilco, also known as the “flight simulator” for software developers, allows companies to create engaging interactive developer challenges (called quests) that enable developers to acquire and practice skills […]

Read more