3 ms·

One thing that is actually nicer is that podman can run kubernetes pods from the kubernetes yaml file description (mostly) directly. This avoids having to use

One thing that is actually nicer is that podman can run kubernetes pods from the kubernetes yaml file description (mostly) directly. This avoids having to use kubernetes in production, and something different (like docker-compose) in local. Being able to search in multiple container registries is very nice, and docker doesn't allow you to do that (to the best of my knowledge). It's very useful if you have a company container registry for example.

mindwok 5y ago
Yeah, I do agree about the pods. IMO pods are a better primitive than a single container, so its cool Podman supports them.
benatkin 5y ago
Why not just use Minikube or microk8s in a VM with multipass?
- metadat 5y ago
  > Why not just ... Podman comes with the ability to directly run Kubernetes YAML files, so the aforementioned non-standard addon things become unnecessary. Ever tried getting a team of 100+ engineers to agree between minikube vs docker-compose? It's not fun and produces nothing interesting. Thankfullyy, with Podman such discussions are no longer needed. Docker should've implemented this about 4-5 years ago, if they wanted to make their product The Best. Instead they became hostile to cool new product ideas, stopped on the ease of use front, and went all-in with Docker Desktop, which is just another non-standard kludge.
  - adra 5y ago
    To be fair they were fighting for docker swarm which ended up losing, so it's not surprising that they're on the back foot.
    - KronisLV 5y ago
      Currently still using Docker Swarm, i wish it was more popular, because it's oftentimes the logical next step when moving from running Docker containers manually or Docker Compose locally. It is pretty simple to use (especially with Portainer), not as resource intensive as most Kubernetes distros and the Compose format now matches what you'd run locally (with extra options, e.g. on which host to run things) vs the spammy format of Kubernetes manifests or even Helm charts. I actually wrote more about it on my blog: https://blog.kronis.dev/articles/docker-swarm-over-kubernetes https://blog.kronis.dev/articles/docker-swarm-over-kubernete... Though it's essentially inevitable that Swarm will be abandoned some day, so being able to migrate over to either Hashicorp Nomad or some Kubernetes distro is probably paramount, which is when tools like Kompose come in, when that's finally necessary. The problem of what cluster to run on still remains for all of the folks who are stuck with on-prem deployments, since most orgs can't pay for a team to manage a cluster or for bunches of hardware resources to run the full Kubernetes. In that regard, the best option that i've found so far is either K3s with Portainer, or K3s with Rancher (RKE and probably RKE2 will still be somewhat heavyweight).
      - AitchEmArsey 5y ago
        Agreed. I never really got hooked on Docker itself, but Swarm is well-scoped and easy to use without sacrificing too much; I'd argue the vast majority of k8s users would be better off with something simpler, and Swarm fits the bill nicely. Maybe Nomad does too, but IMO Hashicorp do a really bad job of documenting the progression from a localhost test to a production setup; the docs for each of their tools can be summarised as "draw the rest of the fucking owl".

mindwok 5y ago

Yeah, I do agree about the pods. IMO pods are a better primitive than a single container, so its cool Podman supports them.

benatkin 5y ago

Why not just use Minikube or microk8s in a VM with multipass?

metadat 5y ago
> Why not just ... Podman comes with the ability to directly run Kubernetes YAML files, so the aforementioned non-standard addon things become unnecessary. Ever tried getting a team of 100+ engineers to agree between minikube vs docker-compose? It's not fun and produces nothing interesting. Thankfullyy, with Podman such discussions are no longer needed. Docker should've implemented this about 4-5 years ago, if they wanted to make their product The Best. Instead they became hostile to cool new product ideas, stopped on the ease of use front, and went all-in with Docker Desktop, which is just another non-standard kludge.
- adra 5y ago
  To be fair they were fighting for docker swarm which ended up losing, so it's not surprising that they're on the back foot.
  - KronisLV 5y ago
    Currently still using Docker Swarm, i wish it was more popular, because it's oftentimes the logical next step when moving from running Docker containers manually or Docker Compose locally. It is pretty simple to use (especially with Portainer), not as resource intensive as most Kubernetes distros and the Compose format now matches what you'd run locally (with extra options, e.g. on which host to run things) vs the spammy format of Kubernetes manifests or even Helm charts. I actually wrote more about it on my blog: https://blog.kronis.dev/articles/docker-swarm-over-kubernetes https://blog.kronis.dev/articles/docker-swarm-over-kubernete... Though it's essentially inevitable that Swarm will be abandoned some day, so being able to migrate over to either Hashicorp Nomad or some Kubernetes distro is probably paramount, which is when tools like Kompose come in, when that's finally necessary. The problem of what cluster to run on still remains for all of the folks who are stuck with on-prem deployments, since most orgs can't pay for a team to manage a cluster or for bunches of hardware resources to run the full Kubernetes. In that regard, the best option that i've found so far is either K3s with Portainer, or K3s with Rancher (RKE and probably RKE2 will still be somewhat heavyweight).
    - AitchEmArsey 5y ago
      Agreed. I never really got hooked on Docker itself, but Swarm is well-scoped and easy to use without sacrificing too much; I'd argue the vast majority of k8s users would be better off with something simpler, and Swarm fits the bill nicely. Maybe Nomad does too, but IMO Hashicorp do a really bad job of documenting the progression from a localhost test to a production setup; the docs for each of their tools can be summarised as "draw the rest of the fucking owl".