Nope.

You can install all of those servers in different containers, and then combine them in the same pod. For all intents and purposes from the outside, it will be a singular VM. But from the inside, you will be able to separate all those servers/tasks to separate containers, running from inside the same virtual localhost machine. They can also use the same PVC, making running a stateful app much more easier. You dont even need to make it a stateful set.

You get a lot of benefits with this - you will be able to easily manage each different server in the containers inside the pod. Easily manage their resource constraints. Security. You can make the pod's containers not accept connection from anything that does not belong to the particular app that they belong to. K8 will manage resources in the cluster, its autoscaling up and down, everything. All of the stuff that you had to maintain scripts or ansible to make happen in non k8 setups will be automated.

K8 is basically abstraction of the non-business stuff a lot of infra approaches were doing. Its containers inside VMs without you needing to manage VMs.

> We've had a couple of devs try and convince us that we should be using Kubernetes and I counter with "it's overkill for what we need". Am I wrong?

You're not necessarily wrong, as long as Docker Compose isn't incompatible with what you're trying to do - e.g. if you'd need overlay networking across multiple nodes, or scheduling things across them in one go, then Docker Compose might not be the best fit and you might instead be better served by looking in the direction of Nomad or even Docker Swarm, though the future there is unclear - maintenance mode project, but very similar to Docker Compose and comes out of the box with any Docker install.

Either way, Kubernetes might indeed be overkill for simple setups, unless you're using just a subset of its functionality and are running lightweight clusters, like K3s or K0s. I guess some might be pushing it because it's basically become the industry standard, at least in some capacity, in some places, or maybe people just want to put it on their CVs.

Well, "it depends". This is similar to my first production k8s deployment, where we used k8s to host a lot of PHP, some node.js, some other stuff, and due to legacy code it meant a lot of apache2 containers with mod_php.

The reason we went for that setup is that it helped us cut cloud/hw costs significantly (at the start we pretty much had two workers and that was because we ran everything with replicas=2) - each individual site had small requirements, and with k8s we could guarantee enough resources while binpacking as many of them per server as possible.

The actual deployment story can possibly get simpler than docker-compose, but I'd say the real question is whether you'd get a financial win out of it, as it seems you have a pretty good steady state going.

Back in time, k8s was a glorified docker swarm and swarm was largely compose spread over multiple servers, so if you deploy everything on a single computer and don't have requirements to care about redundancy/failover and all that, then k8s is almost certainly overkill.

I would first do calculation of what it would cost to host it on vanilla cloud services. They are often cheaper than what people think, if you include work hours needed.

I'm not sure I understand the distinction you're making?

I would be hosting on vanilla cloud with or without Kubernetes.