When to rebuild things that already exist
summary
A new library called crates implements a kubectl‑style, frictionless Python client to replace a patchwork of autogenerated Kubernetes clients, async wrappers and kubectl via subprocess calls that made dask‑kubernetes hard to maintain. The project removes multiple dependencies, collapses inconsistent auth flows, implements missing features like port‑forward handshakes, and lets the codebase shrink as contributors stop wrestling with three different clients. Adoption spikes on Hacker News to 486→500 stars, landing it as the second‑most‑starred Kubernetes Python client.
AI-written summary · about
chapters (13)
- 0:00Introduction
- 1:45Kubernetes Python ecosystem
- 3:52Evaluating Kubernetes libraries
- 6:43Wrapping existing libraries
- 8:50kubectl’s design inspiration
- 9:53Build vs contribute decision
- 13:46Goals for new library
- 14:49Introducing crates library
- 16:37Discovering lightkube
- 17:39Decision to proceed with crates
- 18:22Launch and adoption
- 19:23Discarding work importance
- 20:04Q&A
related talks
29mKubernetes Reloaded AKA How to Avoid the Dev Plateau with CRDs
21mKeynote: In Search of the Kubernetes "Rails" Moment
22mGo Large!
22mBuilding a Platform Framework: Lessons Learned From Developing a Multi-Cluster Kubernetes Operator
32mTending the Kubernetes Dependency Tree: Bonsai or Bonfire?
17mReflections on a decade of k8s. How it has been and what the future is holding.
31mIntro to Kubernetes Sig-Architecture Subprojects
35mPerforming Infrastructure Migrations at Scale