Armory customers often want to better understand the relationship between Kubernetes and Spinnaker.

This is what we typically see happen at large companies:

  • A company has 99% AMI-based deployments or mutable deployments in a data center using Chef or another other configuration management system.
  • An engineering team at the company has determined Kubernetes to be the future. Everyone agrees.
  • Said team has strong opinions on deployment methodologies into Kubernetes and starts building custom tooling to facilitate those deployments.
  • Other engineering leaders at the company who are responsible for the operations of current products realize that a full migration to Kubernetes will take a year (or years -- or more likely, may not fully migrate ever) and will take a massive amount of work to break up monolith apps into microservices. These “old” apps are the ones that pay the bills.
  • These leaders want Spinnaker because it’s a single platform that can create a path to adopting Kubernetes over time while greatly improving the way the other 99% of their apps are deployed.
  • The Kubernetes team resists. They don’t understand how Spinnaker is better than their custom tooling. (Part of the issue we often see here is the sunk cost fallacy).

A Spinnaker User Shows Us How He Deploys to Kubernetes Clusters with Spinnaker

In this post, we'll work to highlight how Spinnaker and Kubernetes differ, how they work best together, and how engineering teams and leaders can get on the same page.

To put it simply: If you use Kubernetes to orchestrate your containers, then you would use Spinnaker to orchestrate your deployments to Kubernetes. Spinnaker also enables deployments to multiple targets across multiple clouds, using a single self-service tool, without writing any scripts. This is great for companies with multiple application teams, all with different paths to production. The larger the company, the more application teams, the more paths to production... the more valuable Spinnaker becomes.

Kubernetes isn’t always enough to give you a fully automated deployment flow from code to production in containers, especially in large companies with complicated deployment pipeline needs. Spinnaker fills this gap by allowing for orchestration of multiple steps through defining sophisticated stages within deployment pipelines and taking a macro-management approach of looking at all of your deployments. Spinnaker enables sophisticated cloud deployment strategies while being customizable for all sorts of workflows.

The responsibility currently falls onto the developers to provide information to Kubernetes to make decisions, so each individual pipeline that is being run on Kubernetes requires glue-code from the developers. This usually entails a series of manual steps by developers that could be automated. By having Spinnaker manage Kubernetes, an organization can shift the responsibility of controlling the deployments from home-grown glue-code to Spinnaker’s process of automating all the deployments.

Here's more great reading on how Kubernetes works with Spinnaker:

In his conclusion Ethan writes "Spinnaker has made a name for itself as a scalable tool that can support any number of requirements. For Kubernetes, this means that operations teams get the resiliency they have come to expect from Kubernetes along with a simple interface to deploying and managing applications hosted on those clusters.


Overall, I’m really impressed with how Spinnaker fits right into the hole that we’ve found in our operations and I hope to see the support for Kubernetes grow over time."

They write, "We’re currently growing our use of container-based deployments via Kubernetes, both internally, as well as on public cloud providers. The presence of a driver for Kubernetes in Spinnaker will enable us to facilitate deployments to any or all of the k8s clusters we’re running"

Getting everyone on the same page:

Armory provides a range of training resources that explain what Spinnaker does, how it works, and how to use it.

We recommend teams follow the steps in this Spinnaker Adoption Playbook to determine if Spinnaker is right for their needs.

When Armory works with customers trying to improve their software delivery sophistication (typically to get to Stages 3-5), we always start by doing a Proof of Concept with one customer team & application, and then we evaluate the deployment benefits generated by that POC. It's a very good way to test the value of Spinnaker in a company's environment, especially if there's internal dialogue about Spinnaker vs. Kubernetes -- because the best approach is often Spinnaker and Kubernetes.