> For example, a common set up is to only allow your developers to access to create/edit objects in one namespace. Not best-practice. Best practice is to lock

> For example, a common set up is to only allow your developers to access to create/edit objects in one namespace. Not best-practice. Best practice is to lock down access to production to grant read-only permissions to developers and force deployments to occur through a controlled pipeline. This controlled pipeline can ensure that changes first go through a staging environment that is essentially identical to production, verify that the changes work there, and only afterwards deploy to production. > Testing things like NetworkPolicies is also fraught. Test, staging, pre-production environments. Particularly since the developer won't typically have the entire environment set up on their developer machine, and permissive network access is a working default, usually more restrictive network policies are setup by whoever has responsibility for the larger environment and breaks are caught in later stages of the pipeline. > ...test ingress changes, but even then changes can take 30 minutes to take effect and can result in inscrutable error messages. Not Kubernetes's fault. Even then it's only partially the cloud provider's fault (because of the inscrutability of said error messages) - infrastructure doesn't provision itself in a split-second and that reality stands at odds with kubectl's desire to return asynchronously, ironically enough, for a better developer experience compared to staring at a console waiting for the cloud provider to respond within a timeout. > Maybe in the future, SSH will be as anachronistic as the floppy disk icon, but for now, I want to log in to a container, poke around, see what the state is Oh man. Please don't. Just don't. Improve your logging and metrics first, then we'll talk. > It’s reasonable that this image doesn’t have strace, and kind of reasonable that it doesn’t have bash, but it highlights one of the Kubernetes best practices that makes local development hard: keep your images as small as possible. That's not a Kubernetes issue, that's a containerization issue. And a large part of the philosophy behind why it's OK in containerland is, there are only three things you need to effectively observe containerized stateless applications, and they are logs (including request tracing), exported metrics, and network traffic statistics (which really are a kind of exported metric, just not one exported by the service). > Even if you can avoid going out to the internet when pushing an image, just building an image can take forever. Especially if you aren’t using multi stage builds, and especially if you are using special development images with extra dependencies. So... use multi-stage image builds? > What I want to do is just sync a file up to my pod... if your container is restarted for any reason, like if your process crashes or the pod gets evicted, you lose all of your changes. By design. Your changes aren't going to propagate to staging, let alone production. > In dev, I want to tail the relevant logs so I can see what I’m doing. Kubernetes doesn’t make that easy. https://github.com/wercker/stern https://github.com/wercker/stern > If we want to empower developers to create end-to-end full stack microservices architectures we need to provide some way to get their hands dirty with networking. Until then that last push to production will always reveal hidden networking issues. If you need to alter multiple microservices to deliver a single feature, your architecture is probably screwed up, or your development process isn't sufficiently structured to build up individual backend services incrementally and in a serial, rollback-able fashion. You can't fix a poor architecture or SDLC by throwing tooling at the problem.