I must say, I'm presently migrating a client from Dokku to Kubernetes and finding K8s tooling to be severely lacking. I've plenty of experience with Docker and

I must say, I'm presently migrating a client from Dokku to Kubernetes and finding K8s tooling to be severely lacking. I've plenty of experience with Docker and Docker Compose; both for development, and also running on cloud infrastructure (although admittedly not Docker Swarm). I also have some limited experience with Amazon CloudFormation and ECS. I'm no stranger to performing Docker migrations, having previously been responsible for heading up migrations to Docker cloud deployments from "old school" customised on-site rack deployments, VPS LAMPP deployments, and "install everything on this one machine, what's reproducibility?" setups. However, I'm finding that migrating to Kubernetes is by far the worst experience I've had when compared to the alternatives that I've tried. I know cluster deployment/management tends to be a common complaint, however I actually found that to be not too difficult. Thanks in large part to kops. Instead my biggest gripes are: 1. Supposed Immutability Kubernetes treats certain "Dockerisms" (e.g. image tags) as immutable, when they're clearly not. This leads to many subtle "gotchas" and associated work-arounds that are non-intuitive. 2. Templating/substitution (or lack there-of) The argument from the K8s core team seems to be that templating result in non-reproducible deployments. However, I find the opposite to be true. I don't want to maintain slightly different resources for all my different environments and have to manually keep them in sync. That's just asking for trouble. I want a single source of truth. I know Helm (Charts) can be used for templating. However, I find Helm to be over-kill, particularly the Tiller runtime requirement. Helm v3 sounds very promising though, and I have every intention of using Helm more extensively once released. 3. Tooling immaturity / Lack of standardisation I seem to be writing a lot of (simple) bash scripts to solve trivial problems, no doubt others are doing similar things and I'm reinventing the wheel. With CloudFormation/ECS or Docker Compose deployments I don't seem require any scripts at all. Problems can be solved trivially in a declarative way, or by running a single command - of course this approach is supplemented by project-specific documentation. I suppose this largely comes down to K8s flexibility; there's so many different ways to achieve something. I'm not necessarily suggesting stripping away that flexibility, as it's part of what makes K8s great. However, there's a lot that could be simplified for 90% of use-cases, particularly if there were more standardisation and widely agreed upon "best practices". I hope this will come in time. 4. Debugging This isn't at all a fault of K8s itself, just platform immaturity. However, despite the fact K8s seems to be emerging as the winner of the container orchestration war, most alternatives seem to offer significantly better tooling e.g. Docker Compose has proper integration into Jetbrains IDEs, including "remote" debugging of apps running in containers. Jetbrains K8s plugin is currently limited to interpretation of YAML/JSON resource semantics. Don't get me wrong I'm using K8s because I think it's hugely powerful/reliable, and I'm betting on it long-term. Presently, it's truly fantastic from an ops perspective, just significantly less so from a development perspective.