The way I've described this for years: Kubernetes makes managing 1000 servers as easy as managing 20 servers, and makes managing 3 servers as easy as managing 20 servers.
My way of thinking about it is this: you have your own hyper-flexible Heroku, but (monkey's paw curls) you can only interact with it by typing large amounts of YAML.
Oh, and all the documentation for that YAML assumes you've memorized as much vocabulary as a Foreign Language 101 class.
(And there is a mad god that says: if you try to use click-ops to get around this without knowing the vocabulary, you're going to have a bad time.)
But on the other hand: to put it in terms of the "3 servers" - the moment you think you'll have 3 servers, and any level of uptime expectations, you'll inevitably have to rebuild them, services and logging and all, from scratch often and quickly enough that you might as well have 20 servers with how stressful that rebuild will be.
k8s can be a saving grace there, and I recommend it to anyone with the time and interest in how cluster best practices work! But it's not a free option or a weekend skill-up.
And if you ever outgrow that it's going to be a huge pain. Or a hardware failure. If you start on Kubernetes early you'll be able to add more servers for capacity very easily. Not to mention out of the box you get failover and HA. And you can deploy managed services and have database deployments, or object stores, etc.
But 99% of the time you don't outgrow it and don't have SLA's requiring them to have failover or HA. This is why so many sites can get away with using PostgreSQL with it's complete lack of good/native HA.
HA and failover, to me-in these small deploys, is more about hardware maintenance rather than maintaining SLAs. Being able to shutdown the computer hosting your containers to scale vertically.
Single-site-2-absurdly-intense-days failover, yes. With weeks of cleanup afterwards.
What every company seems to want: multisite, multimaster immediate failover, no.
Also kubernetes buys you scaling. Compute. Disk. Database (with help). Etc.
Now I rail against companies for wanting that, and I think you're right. Your webshop does not need that. It has so many moving parts the redundancy will cause more outages than it solves. But you can do this, and so people will pay for it.
It is a technical accomplishment.
And with sufficiently good sysadmins, it can work well, and scale.
You could always run a VM / VPS against a managed DB. Many small cloud / VPS providers, like Digital Ocean or Vultr, also offer managed DB services that are cheaper than AWS RDS.
