So you’ve put all your cloud eggs in the Kubernetes basket — what’s the best way to deploy applications to Kubernetes clusters? Spinnaker.

Why Spinnaker?

Our interview with the Google engineering team that built the original Kubernetes support revealed that Spinnaker provides greater insight and agility to deployments than the native Kubernetes API.

Spinnaker support for Kubernetes uses the official Kubernetes API. Therefore it can do everything that Kubernetes is capable of doing on its own (i.e., with the kubectl command) however, it offers more capabilities. It can:

• Show the health of a Kubernetes cluster
• Map constructs to resources (such as server groups and load balancers)
• Allow for multiple deployment strategies (not offered by Kubernetes)
• Offer blue/green deployments and easy rollbacks (which are not offered with vanilla Kubernetes)

Why Spinnaker over Jenkins?

Most companies are using Jenkins with in-house custom scripts. While Jenkins is a very powerful build server, it is not a complete deployment tool. Here’s a great post that outlines the many problems with Jenkins and Continuous Delivery.

Jenkins is centered around scripts, ad-hoc executions, and passing parameters between them, which means that Jenkins has zero knowledge of what the infrastructure is doing. Not only that, debugging Jenkins plus the glue code is a big challenge.

Spinnaker, on the other hand, has first class support for cloud resources. Servers and deployments are built-in, and no custom scripting is needed. It can point at an existing Kubernetes cluster, where it will “read” the status of the cluster and add its applications on the dashboard as if they were deployed by Spinnaker, all the while not adding any additional metadata on any cloud provider (as it doesn’t need to). Existing Kubernetes deployments can also be used as templates for future deployments.

Who should look at Spinnaker?

Companies that need high scalability, and/or are
running hundreds of VMs should look at Spinnaker and Kubernetes. Armory is working with the Google team to create an even more advanced version of the Kuberentes Cloud Provider, which will be fully announced at a March 13th Meetup in San Francisco.