> "I just have one server that uses Docker for packaging, and now want to throw in another, for resiliency" Yes, when you only have a couple of servers, that

> "I just have one server that uses Docker for packaging, and now want to throw in another, for resiliency" Yes, when you only have a couple of servers, that is not the sweet spot for K8s. But few people stop at 2 servers. A few months in, someone asks for a staging environment, and/or QA environment. Someone eventually realizes that they need to regularly test their fail-over and backups. Someone hires a contractor, and wants to give them a copy of the setup that won't block anyone else. Someone realizes we can centralize the logs from all these environments... And so it goes. Even with one server, sometimes you go to do an upgrade, and find your "one server" is actually a tightly coupled bunch of services. (Made-up example: I want to upgrade Varnish, but it requires a newer library that is incompatible with my WordPress version.) That one server could be a server for the Database, one to run the cron jobs, a few for the cache layer, etc. If you break up those into different boxes, you can scale them better -- Instead of one big beefy server, you can have each layer at it's own scale (one or more wimpy boxes, dynamically adjusted). You don't do this to save money directly. But by simplifying things, you make it easier to maintain. That saves labor, plus prevents problems (and makes it easier to hire and train ops.) When you have just a few servers, it looks manageable. As you grow, it gets a lot harder to manage. K8s helps.