CODEWITHSUNDEEP
dockerkubernetesdocker-compose
w0051977
w0051977

Reputation: 15807

Why is it a lot more complex to debug local Kubernetes containers yet local Docker containers are very simple to debug?

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?

Upvotes: 0

Views: 424

Answers (3)

Natan Yellin
Natan Yellin

Reputation: 6387

You're right it is more complicated then it needs to be. I wrote an open source framework called Robusta to solve this.

I do some tricks with code-injection to inject debuggers into already running pods. This lets you bypass the typically complex work of setting up a debug-friendly environment in advance.

You can debug any python pod in the cluster like this:

robusta playbooks trigger python_debugger name=myapp namespace=default

This will setup the debugger. All that remains to do is run kubectl port-forward into the cluster and connect Visual Studio code.

I don't know what language you're using, but if it isn't Python it should still be easy to setup. (Feel free to comment and I'll help you.)

Upvotes: 0

David Maze
David Maze

Reputation: 158977

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.

Upvotes: 1

Arghya Sadhu
Arghya Sadhu

Reputation: 44579

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.

https://www.telepresence.io/tutorials/kubernetes

Upvotes: 0

Related Questions