Stepping up your continuous delivery with Kubernetes and Spinnaker

The discussion around containers has graduated from which are the core components to which is the best way to manage these components. What’s been established in the almost five years of containers is that Docker’s container specification will be the standard for the container runtime and that Kubernetes will be the container orchestrator of choice for most organizations. While this is great progress, there remain other questions about aspects like container networking, security, and end-to-end management. When it comes to deployments, the new kid on the block is not Kubernetes, but a Kubernetes-centric deployment tool called Spinnaker.

Setting the stage — Jenkins

Spinnaker

Jenkins rose to popularity almost a decade ago at the start of the DevOps movement. The focus of this movement was continuous integration. Indeed, CI was the best way to get started with DevOps if you came from a waterfall model of software delivery. CI focused on automating the initial phases of the development pipeline. It could automate builds, thus cutting short the work of developers as they contribute code. This was a big time saver for large teams and helped unify the team’s operations. Jenkins further managed test automation by integrating with other open source testing frameworks like Selenium.

This was a step up from the manual operations of the times before. Automation of these initial steps of the pipeline brought more predictability, accuracy with changes, better traceability, and more control over how code passed from developer to end user. With the initial stages automated, organizations were happy to have some automation while managing deployments manually.

A glimpse of automated deployments — Chef and Puppet

Spinnaker
Around the same time, another trend was sweeping the world of DevOps — infrastructure as code. Companies like Chef and Puppet saw the need to better manage configuration for cloud instances, in this case only VMs, as containers had not yet appeared on the scene.

Their main foe was “configuration drift,” which is an issue caused because of slow, consistent changes with cloud instances that are not easy to keep track of over time, leading to a completely different configuration after a few iterations. Their solution was to treat infrastructure as code. According to this, you’d specify the configuration for your cloud instances in a data file. This would include settings for compute capacity, memory, storage volumes, and more. Once this file is created, a tool like Chef or Puppet would read the instructions in the file and execute them in the cloud platform.

From here, any further changes need not be made directly on the instances. Rather, you just update the template file by adding new fields or editing values of existing fields. These changes are recorded and the change history is easily viewable no matter how far back the changes go. This brings more certainty and confidence to infrastructure management. The missing link — deployments

These tools greatly helped improve efficiency across the development lifecycle. Jenkins optimized the early stages of development while Chef and Puppet managed the instances that powered various environments. Jenkins made life easier for developers and QA, and configuration management tools simplified things for Ops teams. What was missing was a tool that could bring together both these approaches to better manage deployments.

While tools like Jenkins, Chef, and Puppet made some things easier, they were also hard to manage over time. The numerous slave nodes of Jenkins were resource-heavy. Though there’s a universe of Jenkins plugins, managing these plugins was equally challenging. Configuration management tools and their playbooks, cookbooks, and manifests were equally complex. Further, these tools were built during the era of VMs and were not natural at scaling up to operating at container speed. The sheer volume and pace of changes with containers would stretch these configuration management systems to their limits.

Enter Kubernetes

Along came Kubernetes, and it was immediately superior to configuration management tools because of how container-centric it was. Rather than configure individual instances, Kubernetes grouped multiple container instances in groups of pods. It then manages these pods at a higher level of abstraction than configuration management tools.

Further, replicas of pods help ensure high availability. Kubernetes automatically ensures the adequate number of replicas are available so that when pods fail or are retired, their replicas take over their workloads.

Importantly, Kubernetes is a wide-reaching architecture with support for plugins for networking. There has been a lot of activity in the Kubernetes networking space recently with robust tools like Istio, Linkerd, Weave, and Flannel ushering in the era of the “service mesh.” This is the ideal type of networking for containers where services communicate many-to-many. It brings better management of load balancing, service discovery, and monitoring of microservices.

The last mile: Deployments with Spinnaker

Spinnaker
Spinnaker

With these building blocks in place, it’s now the right time to ask the question about how to best manage deployments. To be sure, deployments are the most complex challenge to figure out in the pipeline, even more than builds, tests, and infrastructure. Deployments are where the rubber hits the road. It’s a reality check that bares how efficient the previous steps in the pipeline are. It has real and sometimes far-reaching consequences. End users’ experience of the application is directly affected by how well deployments are handled. Which updates are released, and which are deemed unfit for release is an important question to ask when deploying. Especially, at the pace of container-based development, updates and new features are added at blistering speeds, and deployments can struggle to keep pace. Thus, was born the need for a new tool to manage deployments — Spinnaker.

With origins at Netflix, Spinnaker was born out of an open source tool named Asgard that Netflix developed to better manage its AWS resources. Google then collaborated with Netflix to take Asgard beyond AWS, able to manage resources in other cloud platforms as well. The end result was Spinnaker.

Spinnaker stands at the point of intersection between various tools in the container lifecycle. It integrates well with Git repositories, Jenkins, and other CI tools, configuration management tools like Chef and Puppet, and monitoring tools like Prometheus. It doesn’t look to replace CI tools but rather leverages the strengths of CI tools for the initial phases of development while it itself focuses on optimizing the last mile.

How Spinnaker works

Spinnaker has two focuses — cluster management and deployment management. With cluster management, it brings improvements to how infrastructure is managed. It manages clusters that can be located in a single cloud platform or a mix of platforms. It has advanced controls to view and manage these clusters complete with visualizations where necessary.

Speaking about visualization, Spinnaker helps manage deployments in the form of pipelines. You can create these easy to handle pipelines with each “stage” of the lifecycle defined clearly. You can make the easy stage as simple or as complex as you like. Further, with minute variations, you can make sweeping changes in the pipeline. Pipelines drastically reduce the time it takes to make changes and makes even the most complex changes look simple and manageable.

What does all this result in? A mature deployment culture. From doing infrequent big releases, you can finally move to fast-paced, continuous updates that are characteristic of Agile and DevOps methodologies. Spinnaker enables rolling updates, canary releases, and effortless rollbacks when releases don’t go as planned.

The best part is that Spinnaker can handle deployments across various cloud platforms — AWS, Azure, Google Cloud, OpenShift, DC/OS, Oracle, and more. This brings ultimate freedom from vendor lock-in and lets you think big about how to better optimize operations and save on costs. The original promise of Kubernetes was not just better management of containers, but vendor neutrality. Spinnaker is making this promise a reality.

Better deployment strategy

What started with the DevOps movement and tools like Jenkins and Chef came to age with Docker and Kubernetes. And this progress has culminated in a tool like Spinnaker that doesn’t try to reinvent the wheel but builds on previous advances to deliver a much superior deployment strategy. That is the biggest win and is what users of containers were really after in the first place.

Featured image: Flickr / Andrew Hurley

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top