Managing Kubernetes with Spinnaker at scale
Jul 7, 2017 by Armory
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:
- Lifting the Sail: How Spinnaker maps resources to Kubernetes a blog post by Ethan Rogers.
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.”
- HOW (AND WHY) WE MOVED TO SPINNAKER by Target’s Tech blog.
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”
- Why (and How) Spinnaker and Kubernetes Work Together Seamlessly a video chat with Lars Wander of Google discussing Spinnaker and Kubernetes. (Get more similar content here).
- Codelab on the Spinnaker.io website to create a set of basic pipelines for deploying code from a Github repo to a Kubernetes cluster in the form of a Docker container.
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.
Recently Published Posts
Welcoming 2022: Reflecting and looking forward
Nearly all cultures globally have some form of celebration marking the Winter Solstice. Common threads found in most observances of the annual event are celebration of family and friends (living and past), reflection of the past year, and some form of giving thanks for continued health and sustenance. Exiting 2021, said celebrations would seem especially […]
Read more →
Resiliency and Load distribution
Introduction When scaling a network service, there are always two concerns: resiliency and load distribution, to understand these concepts let us first understand the broader term “Redundancy”. Redundancy is the duplication of a component to increase reliability of the system, usually in the form of a backup, fail-safe, or to improve actual system performance. Resiliency […]
Read more →
CVE-2021-44228 – log4j (Log4Shell) – an analysis
Today marked a 0-day disclosure of a rather nasty vulnerability in one of the most commonly used frameworks for logging – log4j. This one is nasty on multiple levels. Note that Armory Enterprise is NOT affected by this vulnerability. The impact on this vulnerability is likely huge and is already being exploited. Additionally it can […]
Read more →