I have not used quadlets in a "real" production environment but deploying systemd services is very easy to automate with something like Ansible.
But I don't see this as a replacement for k8s as a platform for generic applications, more for deploying a specific set of containers to a fleet of servers with less overhead and complexity.
I have never denied helm is a mistake that people refuse to stop using. I quite think of Helm as the same as Ansible. Helm is only nice when you consume packages written by others.
Ansible is a procedural mess. It's like helm had a baby with a very bad procedural language. It works, but it's such a mess to work with. Half of the time it breaks because you haven't thought about some if statement that covers a single node or some bs.
Comparing that to docker swarm and/or k8s manifests (I guess even Helm if you're not the one developing charts), Ansible is a complete mess. You're better off managing things with Puppet or Salt, as that gives you an actual declarative mechanism (i.e. desired state like K8s manifests).
> Ansible is a complete mess. You're better off managing things with Puppet or Salt, as that gives you an actual declarative mechanism
We thought this, too, when choosing Salt over Ansible, but that was a complete disaster.
Ansible is definitely designed to operate at a lower abstraction level, but modules that behave like desired state declarations actually work very well. And creating your own modules turned out to be at least an order of magnitude easier than in Salt.
We do use Ansible to manage containers via podman-systemd, but slightly hampered by Ubuntu not shipping with podman 5. It's... fine?
Our mixed Windows, Linux VM and Linux bare metal deployment scenario is likely fairly niche, but Ansible is really the only tenable solution.
But I don't see this as a replacement for k8s as a platform for generic applications, more for deploying a specific set of containers to a fleet of servers with less overhead and complexity.