[thomasbacklund]

I have really enjoyed using Podman and will keep using it. I have found it be to stable (running on CentOS) for our production stuff.

Shameless plug: We built Simplenetes[1] around Podman (a simpler alternative to Kubernetes, but written in 100% shell script :)

1: https://simplenetes.io/

[hda111]

On CentOS and similar distros I agree. But on Debian like distros podman has too many rough edges and the packaging isn’t something you can contribute to easily on GitHub. I find this sad since podman is really good but there isn’t much effort in improving UX on Debian distros.

[sgt]

That actually looks pretty interesting.

How do you handle load balancing of inbound traffic.. do you use a pod running Traefik or similar? How do the pods communicate when they are deploying, unavailable or busy and so on?

I guess I could get this from your site but there's a LOT of information on the first pages there and possibly not what I am looking for.

[thomasbacklund]

Thanks,

We use haproxy pods for inbound traffic, they perform TLS termination and simply pass the traffic over to a local proxy pod.

The haproxy pod (and all other pods) communicate with each other over this local proxy service which is running on each host.

We have a very simplified and robust overall architecture, were each pod allocates a specific virtual port and the proxy will try each host for that pod (and remember status), meaning we don't need to keep track of global routing tables and update each host's ip tables (shivering) when pods come and go. We don't use iptables.

If some instance of a pod is unavailable the proxy will seamlessly try another instance of the pod.

Initially we tried to config haproxy to do all this proxying for us, but it was asking too much.

Good to know is that Simplenetes is still in beta.

[sgt]

Ok thanks. Interesting approach. I guess it would be interesting to see how easy something is to troubleshoot, should something actually go wrong.

[thomasbacklund]

Indeed, the goal has to keep the number of moving parts down as much as possible so it can be easy to understand the full cluster and how to troubleshoot it. But of course, it still requires knowledge about the architecture to do so.

[cutemonster]

How was your experience writing that much Bash code?

I wonder what tools there are, currently (I noticed it's in beta), to get an overview of the state of the cluster, maybe what is talking to what, how much bandwidth they use etc (I don't know what one would need to know)

[thomasbacklund]

Thanks for asking :) Writing this much Bash is quite straining because there is a lot of typing, but it is also liberating in the sense of coding very close to the OS (utils).

Also, most of it is not written in Bash, it's written in Posix standard, which is even more spartanic, but is then compatible with Dash and Ash (BusyBox) also, which is good because Bash is not always available.

To make Simplenetes we used another tool we also created which is meant for writing shell script apps and to perform agent-less automation, it is called Space.sh [1]

About tools for getting an overview of the cluster, there is only the command line tooling as for now, which does parts of the job, but tools for analyzing traffic and such is not created yet.

1: https://space.sh/