I would never voluntarily deploy anything using k8s or similar cloud stacks and services. But in practice the bulk of the complexity isn't in pushing and running the actual software, it's in provisioning attached resources (disks, databases), sharing certificates and keys, routing and load balancing, etc.
Way too complex for my tastes, but if you're convinced you need a highly automated control plane for those things then pushing .deb or .rpm packages doesn't even come close to solving that problem.
As usual it comes down to how you define the problem. You can't dissuade people from using k8s by comparing and contrasting k8s to alternatives; you've already ceded the debate over how to define the problem at that point. W'ever its relative merits, k8s is a reasonable approach to the problem of automating the control plane for "scaleable" services.
Debs move state (and computation) and provide a way to resolve dependencies. Done right they also provide rollback. Debs can moved a whole lot more than just the software.
Not saying it is the answer to everything, but it can do a whole lot more than software. Most of our problems are self made we can unmake them by changing the rules we operate under.
> As usual it comes down to how you define the problem.
Totally.
Redefine the problem until the solution is tractable and simple. K8s is the problem to a solution.
