Extending Kubernetes or: How I Learned to Stop Worrying and Trust the Spec

Kubernetes Storage is moving to a new model for volume plugin development with the new Container Storage Interface (CSI) specification, and engineers from multiple companies are now implementing CSI drivers. However, switching to this new paradigm is not without its fair share of challenges.

This talk explores some of the important lessons learned from writing a production-grade CSI driver and discusses some of the challenges that come with conforming to an actively evolving spec.

Attendees will learn about dealing with concurrent development across multiple projects, working with different interpretations of the same specification, and getting user traction on a new project when the current alternative “just works.” These issues become more relevant as Kubernetes moves towards an increasingly decoupled architecture.

Transcript

1. Extending Kubernetes or: How I learned to Stop Worrying and Trust the Spec David Zhu
2. About Me • Software Engineer @ Google • SIG-Storage Contributor • Working on/with Container Storage Interface (CSI) Specification since pre-v0.1.0 ◦ Released v1.0.0 ~a week ago • Developer for the GCP Persistent Disk CSI Driver
3. About Me • Recently broke the record for the Houdini Escape Room in SF
4. Kubernetes Storage circa v1.9
5. Code Built into Kubernetes
6. Being a maintainer was hard
7. “Code for storage plugins that are not supported on your platform is still a risk” - Michelle Au, Kubernetes Storage Guru
8. Being a storage vendor was hard
9. “ If we found a critical bug in our plugin after the Kubernetes release, we don’t have a way to release the plugin separately.” - Xing Yang, OpenSDS Developer
10. Some of the Problems to solve 1. Allow vendors to iterate at their own pace a. Release Decoupling 2. Stop crashes in drivers bringing down all of Kubernetes a. Binary Decoupling 3. Reducing maintenance burden for Kubernetes Approvers a. Code Decoupling
11. The Container Storage Interface
12. What is Container Storage Interface (CSI)? • A few sidecar containers • Storage Drivers • Some pieces inside the container orchestrator (such as Kubernetes) • The Specification • Most importantly… lets us move storage provider code out of Kubernetes
13. RPC Boundary
14. CSI Specification Pages 1-3 of 40
15. Lessons Learned
16. Updating the Spec
17. Concurrent Development and Understanding
18. Transparent & Open Development Forum
22. Open Collaboration Promotes Consensus
23. Using the Spec
24. Different Interpretations
25. CSI Sanity Driver A Driver B Driver C Driver D
27. “NotFound” vs. “InvalidArgument”
28. Conformance Tools Maintain Consistency
29. Getting Adoption
30. In-Tree Plugin
31. Adding Value In-Tree Plugin
32. Volume Snapshots
33. Future: Kubernetes E2E Testing Framework Driver A Driver B Driver C Driver D
35. Adding Value Accelerates Adoption
36. Extending to Extra Extensions
37. Open Collaboration Promotes Consensus
38. Conformance Tools Maintain Consistency
39. Adding Value Accelerates Adoption
40. The Specification Isn’t Everything
41. Extending Kubernetes or: How I learned to Stop Worrying and Trust the Spec Build a Consistent Ecosystem and Process Around a Specification David Zhu, Software Engineer @ Google Email: dyzz@google.com Github: davidz627