Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Podman Desktop 1.2 Released: Compose and Kubernetes Support

podman-desktop.io

Post reply on HN
Print view View original

121–130 of 132 posts

Re: Podman Desktop 1.2 Released: Compose and Kubernetes Support

#121

Post by ducharmdev »

kbenson wrote: post #103
ducharmdev wrote: post #101

At work I was initially using podman on an M1 MacBook, but switched to Rancher Desktop + dockerd a couple months ago after having too many issues with podman. Many in my org are also moving away from podman for similar reasons. I could never get bind mounts working consistently, relying instead on volumes, which are more awkward/less explicit when persisting local DBs used when testing. I've had zero problems with Ra…

> I could never get bind mounts working consistently What type of problems were you seeing? Was it with podman or through podman desktop, and possibly some issue with what it was attempting? bind mounts are a pretty standard kernel feature, so I'm wondering how podman/podman desktop could have been screwing it up, unless it was some user level permissions thing.

I wish I remembered the exact error; it was just with podman though. Podman desktop being newer, I hadn't really tried it out much.

FWIW, it could simply be chalked up to M1 weirdness. We have an ongoing list of various workarounds for the M1, whereas those using Intel MacBooks seem to be mostly fine.

Re: Podman Desktop 1.2 Released: Compose and Kubernetes Support

#122

Post by jadbox »

cholindo wrote: post #78
justin_oaks wrote: post #72

Earlier quoted context omitted.

> Simple setups will be as simple with Kubernetes. That is true if you already have Kubernetes. If you don't, then you still need to run and configure the Kubernetes' control plane (e.g. kube-apiserver, etcd, scheduler, etc). Doing that alone may exceed the complexity of a simple setup. I say this as someone who has looked at Kubernetes a lot and wanted to use it, but could never justify it. I have concluded multiple…

k3s is a super easy way of deploying kubernetes in a linux machine.

I haven't used k3s, but I will check it out.

Re: Podman Desktop 1.2 Released: Compose and Kubernetes Support

#123

Post by JeremyNT »

vbezhenar wrote: post #63
preya2k wrote: post #45

Earlier quoted context omitted.

For me, I really enjoy how basic it is. I’ve never missed any of these things for my simple single-host scenarios.

Simple setups will be as simple with Kubernetes. However with Kubernetes your infrastructure will be ready to scale. You need to expose both front-end and back-end services under the same host? No need to tinker with nginx configs, you just create two ingresses and do it in a standardized way. You need to run your service with two replicas and rolling zero-downtime update? Kubernetes has it out of the box. Good luck…

> Simple setups will be as simple with Kubernetes.

"Simple setups" in Kubernetes will have massive amounts of complexity and overhead, they're just buried in a different abstraction layer.

If you have "free" k8s and don't need to touch it operationally? Sure, do everything with it!

But somebody is going to have to run that k8s environment. If it's you, and you're not a k8s expert, then you'd better buckle up, because all that hidden complexity is now your problem.

In the world where you need to deploy "an app" to "a VM", the simplicity of docker-compose is a sweet spot that any developer can grok without needing an encyclopedic knowledge of how to manage it.

Re: Podman Desktop 1.2 Released: Compose and Kubernetes Support

#124

Post by thiht »

nightowl_games wrote: post #91

To all the people pointing out that docker compose doesn't scale, I use docker compose locally in a vs code dev container and then k8s on production. Running k8s locally seems too complex, maybe it's not so bad but I'm happy with using docker compose dev container for development

I have no idea why anyone would want to run K8s locally. The concept makes absolutely no sense to me.

If you want to run a container, just run the container? K8s is here for scaling, not for running stuff in local.

Re: Podman Desktop 1.2 Released: Compose and Kubernetes Support

#125

Post by gtirloni »

johaugum wrote: post #118
gtirloni wrote: post #97

Earlier quoted context omitted.

I almost spilled my coffee, seriously. I hope you're not putting something like that in production.

Statements like these offer zero value, maybe you could qualify it with some reasoning?

kubeadm alone is maybe 40% of what a production Kubernetes platform is. Just running init and deploying your app is good for a toy project or really small scale cluster.

Every time you hear yourself saying Kubernetes, "only", and "just" on the same sentence, please pause for a moment.

Re: Podman Desktop 1.2 Released: Compose and Kubernetes Support

#126

Post by e12e »

ndsipa_pomu wrote: post #75
e12e wrote: post #36

Earlier quoted context omitted.

Swarm works, but has poor support for volumes - which means it's tricky to run legacy applications on swarm (which eg uploads files to local disk, not s3 - or keeps state/cache on disk, not a database). Ingress is also more complicated/bespoke - the best I've found is traefik with labels for routing/config. My advice today would be to scale Docker compose vertically (eg: on a dedicated server) - then move to Kubernet…

> Swarm works, but has poor support for volumes - which means it's tricky to run legacy applications on swarm (which eg uploads files to local disk, not s3 - or keeps state/cache on disk, not a database). One way round that is to use an NFS volume. However, I've hit problems with too many client NFS connections on a docker swarm and so found it better to mount the NFS volume on each host and use a bind mount instead.

My general feeling about adding an NFS depency to multinode swarm is that it's effectively adding a single point of failure to a system which is otherwise somewhat robust against single node failure...

Re: Podman Desktop 1.2 Released: Compose and Kubernetes Support

#127

Post by vbezhenar »

gtirloni wrote: post #97
vbezhenar wrote: post #81

Earlier quoted context omitted.

kubeadm init is all you need to run and configure everything. It's installed via dep/rpm.

I almost spilled my coffee, seriously. I hope you're not putting something like that in production.

I'm running kubeadm-powered cluster in production for a year and couldn't be happier about it. Absolutely zero issues.

Re: Podman Desktop 1.2 Released: Compose and Kubernetes Support

#128

Post by vbezhenar »

MuffinFlavored wrote: post #112
llama052 wrote: post #108

Earlier quoted context omitted.

If you can grasp the layers of abstraction it's a really really fast way to ship operational solutions. Yaml aside it's great for smaller teams and empowers them to do a lot more than they could traditionally do.

What are some of the most common use cases you can think of, like the most popular ones? I'm drawing a blank on how I'd use this.

I'm running postgres database with two replicas and continous S3 backup. It works flawlessly and with zero effort. If I would need to implement this setup without operator, I'd spent few weeks or more. Operator makes it effortless.

Re: Podman Desktop 1.2 Released: Compose and Kubernetes Support

#129

Post by vbezhenar »

geerlingguy wrote: post #65
erulabs wrote: post #26

Earlier quoted context omitted.

Surprised to hear you think debugging in kubernetes is maddening. It’s absolutely very different , but if I had to debug a system I knew nothing about, I’d rather debug a kubernetes based system rather than any other. Standards and all that. Anyways - for a single container or two obviously you’re right - I’m just not sure that’s so common outside of a side project anymore.

Compared to Compose on a single server, Kubernetes deployments can have multiple layers (control plane, containers, usually some sidecars) where little quirks occur. It almost necessitates deeper monitoring and/or extra tools to give a dashboard/'single pane of glass', whereas I can run Compose and just log into the individual server and jump around logs.

Kubernetes control plane is the same as docker daemon.

Sidecars do not exist in kubernetes, unless you install something that adds them.

Containers are... containers? The same containers you'd see in docker.

Kubernetes does not need deeper monitoring compared to docker. You can jump around kubernetes logs just like you do with docker. Except you don't even need to log into individual server.

I don't use any kind of dashboard for my kubernetes cluster. I installed kubernetes-dashboard, so developers and managers can enjoy their dashboards but I've found no value with it. kubectl is more than enough.

Re: Podman Desktop 1.2 Released: Compose and Kubernetes Support

#130

Post by vbezhenar »

thiht wrote: post #124
nightowl_games wrote: post #91

To all the people pointing out that docker compose doesn't scale, I use docker compose locally in a vs code dev container and then k8s on production. Running k8s locally seems too complex, maybe it's not so bad but I'm happy with using docker compose dev container for development

I have no idea why anyone would want to run K8s locally. The concept makes absolutely no sense to me. If you want to run a container, just run the container? K8s is here for scaling, not for running stuff in local.

What if you need to run 20 services simultaneously? You would either need to maintain two sets of configuration for kubernetes and compose or use just one kubernetes configuration both for production/staging and local development.
Post reply on HN