k8s ecosystem tools are fast changing and native package repos are woefully out of date. Minikube in particular has a habit of just straight up breaking and requires a lot of reading long github issues only to realize there's a fix in a version just pushed 24 hours ago.
> k8s ecosystem tools are fast changing and native package repos are woefully out of date. Minikube in particular has a habit of just straight up breaking and requires a lot of reading long github issues only to realize there's a fix in a version just pushed 24 hours ago.
I don't understand what point you tried to make. If what you want is a stable install to avoid breaking changes pushed in unstable releases, why not stick with a working install just like what you get with brew?
I don't see how using exotic non-standard package managers make releases more stable.
Brew doesn't give you a stable or repeatable install. You can't pin tools to specific versions, they'll get updated whenever you update brew. This is by design and kinda the core ethos of brew. The k8s tooling is generally all meant to have you using the bleeding edge stuff--every tool readme usually says get the latest build from a github release package, brew just effectively does that automatically.
Huh. I guess that makes sense? But can't the tools just host their own rpm and deb repos? I guess that's too much operational overhead? Seems like an operational nightmare to run this in prod without the os-level package managers. Are production environments rolling their own RPMs?
At this point it seems to be that making Kubernetes nearly impossible to self-host is a whole point. You either pay money to dedicated experts or pay money to clouds.
