Skip to main content

Kubernetes V1 & V2 – What’s the Difference?

May 9, 2018 by Ethan Rogers

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.

Recently Published Posts

October 20, 2021
by Jason McIntosh

Monitoring Spinnaker: Part 1

Overview One of the questions that comes up a lot is how you monitor Spinnaker itself.  Not the apps Spinnaker is deploying, but Spinnaker itself and how it’s performing.  This is a question that has a lot of different answers. There are a few guidelines, but many of the answers are the same as how […]

Read more

October 18, 2021
by David Morgenthaler

The Importance of Patents: Interview with Nick Petrella, Head of Legal

    In honor of Armory’s recent acquisition of a patent for continuous software deployment, we sat down with Nick Petrella, Head of Legal, for a casual conversation covering a wide range of subjects, from patent law to Nick’s background as a software engineer and why he made the leap to the law. Check out […]

Read more

October 11, 2021
by Carl Timm

Armory Agent for Kubernetes Simplifies K8s Complexity

I’ll be upfront with you, I’m a sucker for a good origin story. It’s one of the reasons I spent hours engrossed in the Marvel Cinematic Universe not too long ago.  Rooting for incredibly flawed individuals with an outsized sense of duty and superpowers to back it up….What’s not to love?  My partner has a […]

Read more