We just use intermediate machines/jump-hosts :-) It depends on the customer and the project. Most want git-ops, but often they also want kubectl. The overhead

We just use intermediate machines/jump-hosts :-) It depends on the customer and the project. Most want git-ops, but often they also want kubectl. The overhead of having to build, instrument and manage the infrastructure to run software on a Kubernetes cluster is often a pretty big surprise for many of our customers. So in order to debug, developers still resort to kubectl to get a shell in a pod or viewing logs. This is also why I'm against Kubernetes for most projects. It require a high level of maturity in the development team to do right. When you see some one who knows what they're doing, Kubernetes is amazing. For most people however, picking something more "classic" is going to make their life much easier. This is especially in the light of what most want is just some easy way to saying: "Run this container image on those two hosts". So far the best solution I've been able to come up with is Ansible and AWX. Developers can then bump a version number in an group_vars file and click "launch" in AWX.