This is the concern I have with k8s. All this complexity introduces operational and security concerns, while adding more work to do before you can just deploy business value (compared to launching on standard auto-scaling cloud instances)
This is the concern I have with k8s. All this complexity introduces operational and security concerns, while adding more work to do before you can just deploy business value (compared to launching on standard auto-scaling cloud instances)
If you want to go all out you can also grab an operator to manage rolling out databases for you (postgres [2], mongo, etc).
A lot of the complexity people bump into with kube is really poorly planned out tools like Istio that have way too many features, a very overly complex mode of operation (out of the box it breaks CronJobs!!!), and very sub-standard community documentation. If you avoid Istio, or anything that injects sidecars and initcontainers, you'll find the experience enjoyable.
[0] - https://clouddocs.f5.com/containers/v2/kubernetes/
It's kind of like an API gateway with traditional microservice instances. If you have DNS and load balancers pushing requests directly to your services, you might wonder why you would ever need such a thing. Until you do.
How much Kubernetes-adjacent code you actually need to adopt (and therefore, how much risk you take on) depends from project to project and organization to organization.