Orchestrating VM & Container Deployments
-
Upload
lars-wander -
Category
Software
-
view
103 -
download
0
Transcript of Orchestrating VM & Container Deployments
Orchestrating VM & Container Deployments
Google's Motivations
● Tooling has always been a priority at Google
● 2B lines of code
● 50% of code changes monthly
● 30k submits / day
● 6000 builds / hour
● 9000 releases / day
Google's Motivations
● Netflix and Spinnaker’s core tenets align with Google’s
● Take advantage of massive elastic infrastructure
● Immutable infrastructure
● Continuous delivery
● Self-service tools
Google's Motivations
● Our internal platform and tooling is container oriented
● Develop out the Google Cloud Platform toolset for VMs, containers and PaaS
● Spinnaker is a great starting point for VM oriented tooling
● Contribute to OSS that aligns with our culture and goals
● Kubernetes, Bazel
● Working towards an open cloud - choices, transition, flexibility
● Long term commitment to the Spinnaker project
● Dedicated engineering team
● Several internal (and external!) teams are using Spinnaker
Google's (OSS) Motivations
Quick Spinnaker Project History● Started by Netflix in 2014
○ An evolution of earlier Netflix projects (incl. Asgard)
● Google involved since early on
● Many additional companies and individuals are involved now○ Target, Veritas, Microsoft, Schibsted, Pivotal, Kenzan, Armory, ...
● Support for many cloud platforms, and growing
● Open sourced in November 2015
Terminology & Cluster Management
Spinnaker promotes model of:Build candidate → Test in running system → Push to production
Similar process used internally at Google
Bake Deploy Disable orDestroy
Trigger
OSPKG (.deb)
WebhookBuild/TestPush
Commit
Your favorite CI system
Deployment Strategy
New AutoScaling Group
Old AutoScaling Group
AWS/EC2images
Old ManagedInstance Group
New ManagedInstance Group
images
Deployment Strategy
GCE
Bake & Deploy VM Demo
Bake Deploy Disable orDestroy
Trigger
Old ManagedInstance Group
New ManagedInstance Group
images
Deployment Strategy
GCE
Deployment Strategy
New Replica Set
Old Replica Setdocker
images
OSPKG (.deb)
WebhookBuild/TestPush
Commit
Kubernetes
Trigger
Same operations for containers!
DockerRegistry
Kubernetes Deployments API
Great for limiting resource utilization.
Ensures deployments are rolled out slowly.
Puts little pressure on downstream dependencies.
Kubernetes Deployments API
Can’t be paused deterministically for validation.
High rollback cost.
Rollouts are always linear.
Rolling Red Black
Rollout user-defined target percentages. (1% → 2% → 10% → 50% → 100%)
Validation at every stage.
Puts little pressure on downstream dependencies.
Fast rollbacks.
Rolling Red Black
Overprovisioning comes at the cost of rollback speed.
(Fake) Rolling Red Black Demo
Target Percentages = 1% → 2% → 10% → 50% → 100%
Over Provisioning = 10%
Rolling Red BlackOld Server Group New Server Group
Enabled: 100Running: 100
Enabled: 0Running: 0
Rolling Red BlackOld Server Group New Server Group
Enabled: 99Running: 100
Enabled: 1Running: 1
Rolling Red BlackOld Server Group New Server Group
Enabled: 98Running: 100
Enabled: 2Running: 2
Rolling Red BlackOld Server Group New Server Group
Enabled: 90Running: 100
Enabled: 10Running: 10
Rolling Red BlackOld Server Group New Server Group
Enabled: 50Running: 60
Enabled: 50Running: 50
Rolling Red BlackOld Server Group New Server Group
Enabled: 0Running: 10
Enabled: 100Running: 100
Future Spinnaker Plans● Native canary support
● Template language for Pipelines
● Easier configuration using Halyard○ Support for target platforms contributed by multiple companies
● “1.0” release in April
Key Takeaways● Google is committed to the Spinnaker project
● There’s more to Continuous Delivery than updating a server group
● Spinnaker makes it easy for developers to confidently rollout to production
● Spinnaker provides orchestration not possible with your cloud alone
Thank you● Provision Spinnaker with Helm:
https://github.com/kubernetes/charts/tree/master/stable/spinnaker
● Questions?
spinnaker.io