1. Provisioning and managing Kubernetes clusters through their lifecycle is difficult and grows in complexity as you scale. Managing Kubernetes upgrades, with API version deprecations or other small behavioral changes causing outages or lost cycles (Take Reddit for example)
2. Maintaining a Kubernetes YAML codebase for application development is error-prone and frequently untestable.
3. Existing tooling is powerful, but lacks enterprise-grade features. Tools do not integrate well with each other and still require manual integration with the rest of the Kubernetes stack.
Unless your cloud provider does this for you. This is one of the first challenges. The problem of providing a tool that makes this simpler is that the biggest pain of k8s provisioning is choice explosion. A problem many others have already tried solving by creating distributions, which there now are so many of that you have a choice explosion of distributions instead, with no clear understanding of compatibility or what this black box does. What need to be done is remove choices from the core and streamline installation as one standard package, not adding even more abstractions and mystery on top.
2. Once you have a cluster running, there are less excuses. Any alternative IaC is equally untestable. In fact k8s is one of the more testable options since you can run a local cluster with Kind and the yamls don’t suffer from configuration drift.
Yaml and string templated Helm is hell, anyone who can come up with a more type safe language would get a gold medal. HCL for k8s would be fantastic. Staying away from Helm entirely also reduces a lot of accidental complexity, basic manifests get you very far.
3. Same applies to other tools.
I don’t know what it is, but so many is focused towards being infinitly scalable without thinking about the complexity that grows with it.