The Architecture Wasn't Designed — It Emerged (k3d-manager, Part 2)

This is a follow-up to How I Keep a Kubernetes CLI Lean . You don't need to read that first, but it gives context for what k3d-manager is. The Part I Left Out In the first article I described k3d-manager as having a provider abstraction — where the same commands work whether you're running k3d on macOS or k3s on Linux. I made it sound like a design decision. It wasn't. It was a reaction. Here's what actually happened. How It Started: k3d on macOS I started building k3d-manager entirely on macOS, using k3d — Kubernetes in Docker. Fast feedback loop, no VM overhead, everything running locally. That's where the dispatcher pattern, the lazy-loading plugin system, and the _run_command wrapper all came together. At that point the code had no abstraction for cluster providers. There was one cluster type: k3d. It was baked in everywhere. That worked fine — until it didn't. The Wall: k3s Only Runs on Linux k3s is a production-grade Kubernetes distribution. It's lightweight, single-binary, great