I have a love/hate relation with K8S, I have several customer project that I work on deployed on GKE. For the most part it has been a rock solid set-and-forget

I have a love/hate relation with K8S, I have several customer project that I work on deployed on GKE. For the most part it has been a rock solid set-and-forget experience, but... The problem for me is that these project are not under full time development. Most of them see maybe one or two deployments per year. It seems like every time I do a deployment, some part of the YAML config structure has been deprecated, with no clear path on how to migrate. In the end I have to spend a day figuring out how to rewrite the YAML configs to do _exactly the same_ as before. This is really hard to explain to a customer. But it's not just K8S itself that suffers from this, third party components do this too. Stuff like ingress control is a nightmare, I've seen the nginx ingress controller (not to be confused with the 'other' nginx ingress controller) grow from a 50 LOC base config to multiple KLOC of YAML config you are supposed to pipe to your production environment. The ACME/LE extension (cert-manager) is even worse, the default config is 26KLOC long! [0]. And you are supposed to pipe this config straight into your environment. The amount of new and amazingly complex components that are added with each new release is staggering. If you are an average Joe developer and you want to use containers in production, just stick with a machine with docker-compose on it. It's a lot easier to maintain and has far fewer surprises down the road. It is also much easier to make a quote on maintaining a VPS box that having to get a crystal ball to predict when Google will deprecate parts of your setup. [0] https://github.com/jetstack/cert-manager/releases/download/v1.2.0/cert-manager.yaml https://github.com/jetstack/cert-manager/releases/download/v...