The article and my comments are about personal side projects, not about running a business. For me this means cutting down on complexity: 80% of the features for 20% of the work.
Moreover, stopping a container does not mean killing it, it sends a SIGTERM that the application catches to terminate gracefully.
I would also argue that applications processing money must be able to tolerate unexpected failures. Because Kubernetes or not, servers go down, processes get killed, disks get corrupt.
You may have side projects which are for a small business or a non-profit, and yet requires being able to sustain multiple requests per second on a single machine. In such a setup, zero downtime deployments are necessary.
Some (most) application are being able to gracefully terminate, but it doesn't solve the issue. You still need some mechanism to start the new version, wait for it to be reader, switch the new traffic to the new version, and then gracefully shutdown the old version.
Those are fair points for side projects that have no visitors, but at least for me a side project can also have quite some traffic and then even a little timeout may not be an option. Plus you get a ton of goodies by relying on k8s (or similar) - ability to do an easy rollout, rollback, blue-green deployments, partial rollout, ability to replace multiple containers together if frontend and backend containers must be in sync (a pod) etc. Just my 2 cents.
Moreover, stopping a container does not mean killing it, it sends a SIGTERM that the application catches to terminate gracefully.
I would also argue that applications processing money must be able to tolerate unexpected failures. Because Kubernetes or not, servers go down, processes get killed, disks get corrupt.