31–33 of 33 posts
Earlier quoted context omitted.
Podman supports just the pod spec also used by kubernetes. How much orchestration do you need on a local machine?
docker != docker compose. docker compose is just as heavy. there's not a significant difference between k3s and docker compose.
I'm not quite sure what level of testing this facilitates. If you're testing as close to production as possible, you probably want templated k8s config that scales down to a k8s in CI (e.g. Helm with variables applied that make it minimal). If you just want a local stack to test components and not the k8s config, why not just use docker compose itself?
docker compose is beautiful because it uses a simple elegant compose yml file - this is now an open standard. https://www.compose-spec.io/ the standard does not make it mandatory that underlying system should be docker compose (the reference server). it can be anything. IMHO - kappal is the first project that takes your compose yml file and transparently/drop-in runs it on kubernetes. there is nothing extra you need.…
Earlier quoted context omitted.
Great if you’re you, but try getting AverageSWE a local kube setup and see how quickly they ramp up on it In my ideal world everyone would use kubernetes, it is the hammer and everything is a nail, but we must recognize that it is difficult for a lot of people to pick up. That being said, if you’re deploying on kube in production, use kube locally. But if you’re not, dont
Using kube in production but really, even if I wasn't, I would still use the podman play kube approach. It isn't hard (at all) and isn't kubernetes, just kubernetes yaml. I actually find docker / compose a bit harder sometimes with the daemon running in the background.