Kubernetes V1 & V2 – What’s the Difference?

Note: This content refers to Spinnaker’s legacy Kubernetes provider (V1), which is scheduled for deletion in Spinnaker 1.21. We recommend using the manifest-based provider (V2) instead.

Chances are if you’ve been investigating or evaluating Spinnaker within the last few months you’ve seen a lot of talk about the Kubernetes V1 and V2 providers. Since the difference isn’t immediately apparent, I wanted to give you an in-depth look at why the community built this integration and the value that each one provides. I hope that it makes it easier to decide which one to use and how your team might benefit from utilizing Spinnaker to deploy your workloads to Kubernetes.

The V1 Provider

The V1 Kubernetes provider was the first iteration of Kubernetes integration for Spinnaker. This provider started by mapping relevant Kubernetes resources into their Spinnaker counterparts such as Load Balancers, (Services) and Server Groups (ReplicaSets) (you can read more about this here). By doing this, the Kubernetes integration felt like any other cloud provider within Spinnaker which made the experience a lot more consistent, especially for teams using Spinnaker with multiple clouds.

I like to think of the V1 provider as Kubernetes with training wheels.It lets teams get spun up quickly by providing a simple UI, exposing all the properties of these resources, and putting them into familiar terms.

This approach, however, was very restrictive and didn’t work well for teams who already had established Kubernetes workflows. I knew users who desperately wanted to use Spinnaker but weren’t able to as it didn’t support all of their use cases. This approach also made it difficult to support new features as they were released for Kubernetes because a change in the API meant we also had to make a change in Spinnaker to support it. Furthermore, if the underlying client library were missing some functionality, a change would have to be made in the library and then pulled into Spinnaker.

Despite the engineering overhead involved with maintaining the Kubernetes V1 provider, I still believe it provides a lot of value. As I mentioned before, for teams who want to use Kubernetes but aren’t familiar with everything it provides, the V1 provider lays everything out in a simple way and gives users enough power to deliver value to their customers reliably and safely.

The V2 Provider

Due to some of the restrictions mentioned above, and a significant amount of feedback from the community, work on the Kubernetes V2 provider started in Q2 2017. Instead of mapping a subset of Kubernetes resources into Spinnaker 1-for-1, the V2 provider takes a wholly different approach by incorporating the concept of Artifact driven deployments. V2 also makes it possible to deploy all types of Kubernetes resources with Spinnaker via Kubernetes manifests, a concept already well understood by the community. Spinnaker does this by treating these manifests as deployable artifacts and can reference them from any repository like Github or S3. As these manifests change over time, Spinnaker will handle their rollout and promotion across various environments, a process which previously had to be scripted and handled by off-the-shelf CI tools. Since the majority of Kubernetes users are already deploying these manifests, teams can adopt Spinnaker at their own pace, slowly migrating deployments away from homegrown solutions.

There are a couple of nuances about the V2 provider that make it powerful, especially for those who are transitioning from preexisting tooling. Under the hood, Spinnaker is using kubectl to apply your manifests. The use of kubectl means that as you roll out your manifests you continue to get the same result as you’d expect from any kubectl apply and teams can expect the same behavior across all of their tooling as they migrate to Spinnaker. Also, to support robust rollbacks, ConfigMap and Secret resources are versioned alongside your Deployments. As these resources change over time, you’re always guaranteed safe and predictable rollbacks. Each time a ConfigMap or Secret changes, Spinnaker will create these resources with a specific version number, v001 for example, and pin any references to it in your Deployment to that version. If the resource changes, the version will be updated in the Deployment such that the resource is consistent in the event of a rollback. Doing this ensures that all of the resources deployed into Kubernetes are treated in an Immutable fashion, a core tenant of Spinnaker’s philosophy.

I like to think of the V2 provider as a means of meeting the Kubernetes community where they’re at and making the platform more accessible to a broader audience.

Aside from making manifest deployment a native concept within Spinnaker, we are currently exploring ways to integrate popular tools like Helm and other templating frameworks to reduce the barrier of entry. By doing this, we can make it easier for teams to adopt Spinnaker without a significant amount of overhead thereby alleviating the feeling that all previous work is sunk cost.

Regardless of the Kubernetes integration your team decides to use, adopting Spinnaker opens up a mass of features that other frameworks or tools lack. Spinnaker offers a lot of enterprise-grade features like Automated Canary Analysis and Chaos Engineering that make deployments safer and more reliable. To take advantage of these features without Spinnaker would mean integrating your existing toolset with each and learning how to take advantage of them. The features mentioned above are also available for all cloud providers that Spinnaker supports which means that you only need a single tool for your deployments across your entire business, making them consistent and understood by everyone within your engineering organization.

At the time of this writing, the current stable release of Spinnaker is 1.7.2, and the Kubernetes V2 provider is in an Alpha. As more and more users begin adopting the new provider, we’ve gotten a lot of great feedback, and it continues to get better daily. If you’ve tested the V2 provider and have any feedback or encounter any issues, be sure to leave let us know by filing an issue on Github.

The Kubernetes V2 provider is a community effort and wouldn’t have been possible without contributions from companies like Google, Armory, Datadog, Spotify, Joel Wilson at Cognite and other community members.