The Spinnaker community is about to unveil a new, manifest-based version of the Kubernetes cloud driver for Spinnaker, built in collaboration between Armory and Google, which is currently in a closed community review. It will was unveiled at a March 13th meetup at Gusto HQ in San Francisco.
Want to give it a try? Early Access instructions are here.
Why A Kubernetes V2 Provider?
Spinnaker is an opinionated platform that was used to deploy VM based autoscaling groups but needed a more Kubernetes centric approach to Kubernetes based deployments. Most Kubernetes users already have processes that output manifests, but it has been impossible to import those manifests into Spinnaker until now. The V2 provider addresses the ability to use these manifests as part of your deployment pipelines in Spinnaker.
Why Use Spinnaker to Deploy to Kubernetes?
Like Spinnaker, there are many CI/CD tools have a concept of "pipelines". Spinnaker differs by providing first-class support for deployment semantics within a pipeline such as scaling replicasets, sophisticated rollout strategies, replicaset promotions, destroying replicasets, deployment/cluster visualization, and manifest versioning. Typically these types of activities require developers to build a significant amount of "glue code" just to make their deployments work. Spinnaker gives you all this out-of-the-box.
Current State of the Kubernetes V2 Provider:
The V2 Provider is still in development but has made significant progress. To date there are the following stages available:
- Deploy Manifest
- Delete Manifest
- Scale Manifest
- Rollback Manifest
Versioned deployments (Spinnaker appends the version on the manifest identifier) of Kubernetes manifests within Spinnaker pipelines allowing for even easier rollbacks. You can follow community progress at Github: https://github.com/spinnaker/spinnaker/projects/2