Debugging Docker containers is very easy on my local PC. Say I have this scenario:
1) A web application project
2) A Docker-Compose project
I set the Docker-Compose project as the startup project and then debug the project. Any breakpoints I add to my web application project work i.e. the code stops.
I have now enabled Kubernetes in Docker for Desktop and I have created a very simple app and deployed it. However, it seems to be very complex to setup a debugging environment - for example as described here: https://medium.com/@pavel.agarkov/debugging-asp-net-core-app-running-in-kubernetes-minikube-from-visual-studio-2017-on-windows-6671ddc23d93, which is making me think that I am doing something wrong. Is there a simple way to debug Kubernetes when it is installed locally like it is when debugging local Docker containers?
I was hoping that I would be able to just launch Visual Studio and it would start debugging Kubernetes containers - like with Docker. Is this possible?
Telepresence is an useful tool to debug pods in kubernetes.Telepresence works by running your code locally, as a normal local process, and then forwarding requests to/from the Kubernetes cluster.This means development is fast: you only have to change your code and restart your process. Many web frameworks also do automatic code reload, in which case you won't even need to restart.
Kubernetes is a tool designed to run multiple copies of a packaged application Somewhere Else. It is not designed as a live-development tool.
Imagine that you built a desktop application, packaged it up somehow, and sent it off to me. I'm running it on my desktop (Somewhere Else) and have a problem with it. I can report that problem to you, but you're not going to be able to attach your IDE to my desktop system. Instead, you need to reproduce my issue on your own development system, write a test case for it, and fix it; once you've done that you can release an update that I can run again.
Kubernetes is much more focused on this "run released software" model than a live-development environment. You can easily roll a Deployment object back to the previous version of the software that has been released, for example, assuming you have a scheme to tag distinct releases. You need to do a lot of hacking to try to get a local development tree to run inside a container, though.
The other important corollary to this is that, when you "attach your IDE to a Docker container", you are not running the code in your image! A typical setup for this starts a Docker container from an image but then overwrites all of the application code (via a bind mount) with whatever content you have on your local system. Aside from perhaps encapsulating some hard-to-install dependencies, this approach one the one hand gets the inconveniences of using Docker at all (must have root-equivalent permissions, can't locally run support tools, ...) and on the other this hides the code in the image (so you'll need to repeat whatever tests when you want to deploy to production).
I'd recommend using a local development environment for local development, and not trying to simulate it using other tools. Kubernetes isn't well-suited to live development at all, and I wouldn't try to incorporate it into your day-to-day workflow other than for pre-deployment testing once other tests have passed.