Deployment Pipelines for a Descartes Labs Service
Deployment Pipelines for a Descartes Labs Service
Deployment Pipelines for a Descartes Labs Service

At Descartes Labs we’ve been using Spinnaker to deploy our services since the Kubernetes V2 provider launched earlier this year. As a company still new to Spinnaker, we were excited to attend Spinnaker Summit in Seattle two weeks ago where we had the chance to see how others are using Spinnaker with Kubernetes and meet some of the awesome community around Spinnaker.

Descartes Labs deployment triggers and Spinnaker cluster integrations
Descartes Labs deployment triggers and Spinnaker cluster integrations

I took the opportunity to talk about our experiences Getting Familiar with Spinnaker and the Kubernetes V2 Provider (on GKE), where I detailed some of our deployment pipelines. After showing how we use a replica Kubernetes cluster for blackbox tested canaries I demoed how we propagate to production based on Istio generated metrics. I then outlined pipelines for high velocity deployments from Google’s Container Registry using the V2 PubSub trigger and linked to a Halyard customization script which configures those integrations for us automatically.

Edit: You can watch my Spinnaker Summit talk here.

Istio Workload Dashboard showing our latest deployment canary might have some issues
Istio Workload Dashboard showing our latest deployment canary might have some issues

Big takeaways for Descartes Labs:

  • Automated canary analysis is mainstream — the level of adoption of this feature (only introduced in April 2018) was amazing. Descartes Labs is using manual judgements to approve stages of our pipelines so this is a bandwagon we can’t wait to jump on.
  • Automated pipeline generation is tough but tractable — lots of approaches to generating pipelines from code were discussed, both in talks and offline. Managed Pipeline Templates (currently undergoing a re-write) and large third party efforts reinforce what a complex problem this is, but offline chats germinated solid ideas about how we can tackle this more effectively.
  • Istio is so hot right now — as one of the only companies at Spinnaker Summit using Istio in production I became an accidental Istio evangelist with lots of interest in our performance numbers, metrics dashboards, and excitement around the dynamic service graph and service monitoring capabilities furnished by Google’s Stackdriver Service Monitoring. It’s clear Istio has a big part to play in the future of the Kubernetes V2 provider.

I wish I could have seen more talks, but these were some of my highlights:

Spinnaker, Borg and Annealing — Pim van Pelt from Google led a discussion panel detailing a Kubernetes Bridge that allowed Spinnaker to manage Borg infrastructure through Kubernetes custom resource definitions. This facilitated discussion around Google’s Annealing tool which continuously drives internal Google infrastructure towards a declarative DAG encoded representation of desired state. At the end of the presentation Pim asked us to complete this survey if we are interested in seeing this open sourced (yes please!).

Declarative Spinnaker — The Council of Robs discussed why we want declarative infrastructure management (aka Annealing, see above) and what this would look like in Spinnaker.

Gluing It All Together — Oleg Atamanenko from Kublr walked the audience through a Kubernetes V2 deployment strategy leveraging Istio VirtualServices for high granularity canaries/blue-green deployments while using Istio metrics for automated canary analysis.

Schibsted — I caught two great talks by Schibsted folks. Over three thousand deployment pipelines, impressive pipeline templating infrastructure, dynamic evaluation of pipelines as artifacts with full provenance and reproducibility of pipeline execution... these folks are doing a great job of highlighting the scalability and extensibility of Spinnaker.

spinnaker

It was great to see what a strong and considerate community Spinnaker is fostering. I really hope to make it back next year.