Open sguidos opened 3 years ago
Hi @sguidos, thanks for contacting us. We currently only support debugging services, but we will be working on supporting statefulsets in the next sprint and also have pods and deployments on our backlog. I will add CronJob support to our backlog as well and share any updates to this thread.
Any update on this?
@sguidos Thanks for your message. Could you please let us know if you're using Visual Studio, or VS Code?
We don't support Cron Job, but we've added more debugging targets in VS Code (statefulsets, but also directly debugging pods that might help you here). Is giving a try to this in VS Code a possibility for you?
My environment of choice is Visual Studio 2019. I have Visual Studio Code, and other team members use that, so knowing more would be helpful. Does the Visual Studio Code "Bridge to Kubernetes" extension currently support statefulsets and direct pod debugging, or is this an upcoming release? I do not see any reference to statefulsets in the online documentation. Is there documentation I am not aware of?
Also, I remain surprised that Visual Studio Code seems to continue to be in the lead when it comes to Kubernetes - the very handy Kubernetes Tools extension is still not available for Visual Studio 2019, correct? I would have thought that your paid products would at least be on parity with your open source tools, what is the roadmap here?
Thanks @sguidos for your reply. Yes, the currently released VS Code extension supports services backed by statefulsets, as well as direct pod debugging. Please note though that isolation isn't supported in these scenarios.
To debug directly a pod:
To debug services backed by statefulsets, you can just configure the connection as for any service: https://docs.microsoft.com/visualstudio/bridge/bridge-to-kubernetes-vs-code (same link as above)
Regarding the difference in features between VS Code and Visual Studio, while I can't talk for all Microsoft teams, I know that in some cases the users are not the same on these two products and that some tools make more sense on one or the other. In the specific case you mention, I agree that having a Kubernetes explorer on Visual Studio would make sense. I brought this up to a partner working on some of Visual Studio's tooling for consideration.
When I select "Bridge to Kubernetes" and get the "Create profile" dialog box, I am required to select a Service from the dropdown. But my project is a console app Cron Job that I want to debug from within a Kubernetes cluster, using its environment variables and internal services. Also, I have a Statefulset that hosts an MQTT listener and process but exposes no Services, and I would like to debug that within my Kubernetes cluster as well.
How do I debug processes that do not expose Kubernetes Services?