Background | Slides |
---|
Speakers
- James Wen, Spotify
Spotify is currently migrating their internal services from Helios to Kubernetes. This talk covers their experience and learnings they have obtained during this process.
Offload cluster management to an automation tool (e.g. Terraform) or managed service if possible.
Keep it simple for developers to reason about.
They have a deployment abstraction layer (Tugboat) that can deploy to their previous platform or Kubernetes. They also have a service they call Compass that determines which Kubernetes cluster(s) applications should be deployed to (e.g. sticky certain apps to particular clusters, deploy the app to N clusters, etc.)
Establish trust through monitoring.
- Monitoring on integration components
- Error
- Latency
- Saturation
- Smoke test —> periodic deploys
- Metrics for:
- Available cluster capacity
- Status of backups
- Scheduling
Plan for and simulate failures.
- Disaster Recovery Testing
- Planned and executed DiRTs
- Cluster deletions
- Master being down
- Validation and improvement of
- Metrics + Alerting
- Playbooks
- Backups
- Planned and executed DiRTs
Track enough data to answer questions.
Metrics/Dashboard to track:
- Resource Utilization
- Cost
- % apps migrated
- Developer productivity
Cost tracking was an effective motivator for many teams to adopt Kubernetes on their own.
Take complexity for your developers.
Allow clients to self-service create namespaces
Use existing tools/abstractions.
Their existing applications had a configuration file for Helios and tooling (Tugboat) that reads their Helios config to deploy. They extended Tugboat to also support Kubernetes yaml files, allowing their development teams to migrate without changing their deployment process.
You as owners are not the audience.
Support can be mutually beneficial.
- Developers will always have questions
- US East Coast + Europe
- Support shifts covering both, where people on these shifts expect to be interrupted to handle client inquiries/issues
Developers need feature parity or better.
The new Kubernetes offering must have feature parity or more with the predecessor offering
- Operational Solidity
- Business Impact
- Self Service Experience
- Important Feature Parity
- Be mindful and deliberate in dictating terminology
- Migrate in stages/series of goals that increase in scope
- Devs will adopt and/or migrate to your Kubernetes offering if it is easy, complete, and compelling
- Talk to other companies about how they do infrastructure/solve infrastructure problems