Enhancing Spinnaker’s Kubernetes support to ease app deployments
Andrew Phillips
Product Manager, Google Cloud
For lots of developers, using containers and Kubernetes often means working to implement continuous integration and continuous delivery (CI/CD) to automate software delivery. And now, Spinnaker, the open-source continuous delivery platform developed jointly by Google and Netflix, includes a new Kubernetes provider (Spinnaker’s way of supporting target runtimes) that greatly enhances the Kubernetes CI/CD experience.
Announced last week at Spinnaker Summit 2018 as part of the Spinnaker 1.10 release, you can now take advantage of the full flexibility of Kubernetes, while abstracting away much of the complexity of managing manifests, so developers can just focus on doing what they love—writing code. Spinnaker’s updated Kubernetes provider also integrates with the Helm package manager to template your manifests, and includes initial support for traffic shaping via Istio.
As more leading enterprises adopt Spinnaker for organization-wide continuous delivery, it's great to see Spinnaker continuing to add support for container management platforms, simplifying the process for more developers.
Andy Glover, Director of Delivery Engineering, Netflix
It’s still early days for continuous delivery in Kubernetes environments, and release engineering teams look to Spinnaker to provide a software delivery framework with best practices right out of the box. At the same time, organizations that are new to Kubernetes need to be able to experiment with all its features and resource types, to design an environment that works best for them.
Spinnaker’s redesigned Kubernetes support, which we developed with the Spinnaker community, gives teams full access to all Kubernetes resources via manifests. It also automatically takes care of some of the lower-level complexities of manifest management, such as correct handling of labels, to provide a tailored user experience for non-experts. Release engineering teams can set up Kubernetes how they want for their company and package up the resulting pipelines as “golden paths” for multiple development teams.This lets them get started quickly and avoid lots of complex scripting and low-level manifest manipulation. At the same time, they can still use any Kubernetes features they need.
Schibsted Media Group is a large media conglomerate owning media houses in Scandinavia and online marketplaces worldwide that runs on multiple clouds, including Google Cloud Platform and Kubernetes for containerized workloads, and uses Spinnaker to automate a robust deployment pipeline.
The new integration embraces Kubernetes principles and brings the strengths and flexibility of Kubernetes into Spinnaker. Using this integration, we deploy roughly 280 times a week across multiple environments making sure that users only have access to environments that they are entitled to.
Gard Rimestad, DevOps Engineer, Schibsted
Understanding CI/CD for Kubernetes with Spinnaker
There are two common approaches to automating application deployments to Kubernetes: scripting the deployment flow with a general-purpose orchestrator such as Jenkins; or using one of a number of Kubernetes-focused CI/CD offerings that are still relatively new in the market.
Scripting using general-purpose orchestrators is brittle and error-prone, and both approaches require individual developers to have in-depth knowledge of Kubernetes manifests—a bottleneck you probably want to avoid when running at scale.
The new Spinnaker Kubernetes provider addresses these challenges in a number of ways:
Automatically retrieves the right manifests for a given set of container images to be released, i.e., the ones that match the commit version from which the images were built
Supports the repository layout and control flow of a GitOps-style process, if desired
Generates multiple manifests for staging, QA, and production environments as part of the pipeline, with support for Helm, and eventually other popular templating engines
Automatically sets the container image version in the manifests that will be deployed. In line with best practices, it does this using digests rather than tags, avoiding complex scripting
Gives release engineering teams the ability to restrict developers’ access to Kubernetes namespaces, clusters, and resource types
Supports automatic versioning of config maps, so that rolling back an application also results in the appropriate configuration settings being restored
Automatically sets Application CRD-compliant labels and annotations, for better discovery in Kubernetes
Understands custom Kubernetes extensions (CRDs), which more advanced teams use to build company-specific abstractions
