You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Aug 20, 2022. It is now read-only.
I have a .Net Core 6 app which communicates with a kafka queue. I was able to start my app with B2K four weeks ago and everything would work as expected; I was able to use breakpoints, my service was able to communicate with kafka, etc. I am using minikube on Windows with Docker Desktop.
I came back to it this week: recreated my minikube cluster, re-installed kafka via helm, re-deployed my service and then ran Bridge To Kubernetes: now my services are unreachable from outside the cluster. I reproduced this on two machines.
I expect to be able to reach a service using the ip address and port bridge to kubernetes displays when starting it.
Logs
Attach logs from the following directory:
For Windows: %TEMP%/Bridge to Kubernetes
For OSX/Linux: $TMPDIR/Bridge to Kubernetes
If you are a Visual Studio user,
Set the environment variable MS_VS_AZUREDEVSPACES_TOOLS_LOGGING_ENABLED=true
Open Visual Studio and run your scenario
Provide logs from: %temp%\Microsoft.VisualStudio.Kubernetes.Debugging
Environment Details
Client used (VS Code/Visual Studio):
Client's version:
Operating System: Windows 11
Additional context
I believe the only difference between four weeks ago and now is I might have upgraded to wsl 2, not sure. Downgrading did not fix it though.
I have also installed a RMM software since then.
I noticed a log that said the local dns server was not running.
I am able to connect to a pod when port-forwarding.
The host file seems to be properly updated.
EDIT1:
I managed to reproduce by following the documentation. The only difference, I guess, is I am using the docker driver with wsl 2 instead of hyperv, but I read it was supported in another issue. Will try with hyperv.
EDIT2:
So it doesn't work using hyperv either, same problem.
The text was updated successfully, but these errors were encountered:
if you are using WSL2 and vscode for B2K, do you have the useKubernetesServiceEnvironmentVariables to true in tasks.json ? since WSL2 is considered remote debugging. more details would be appreciated.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Describe the bug
I have a .Net Core 6 app which communicates with a kafka queue. I was able to start my app with B2K four weeks ago and everything would work as expected; I was able to use breakpoints, my service was able to communicate with kafka, etc. I am using minikube on Windows with Docker Desktop.
I came back to it this week: recreated my minikube cluster, re-installed kafka via helm, re-deployed my service and then ran Bridge To Kubernetes: now my services are unreachable from outside the cluster. I reproduced this on two machines.
To Reproduce
I managed to do a kind-of-minimal repro:
kubectl create deployment hello-node --image=k8s.gcr.io/echoserver:1.4
2
kubectl expose deployment hello-node --type=LoadBalancer --port=8080
Expected behavior
I expect to be able to reach a service using the ip address and port bridge to kubernetes displays when starting it.
Logs
Attach logs from the following directory:
For Windows: %TEMP%/Bridge to Kubernetes
For OSX/Linux: $TMPDIR/Bridge to Kubernetes
If you are a Visual Studio user,
Environment Details
Client used (VS Code/Visual Studio):
Client's version:
Operating System: Windows 11
Additional context
I believe the only difference between four weeks ago and now is I might have upgraded to wsl 2, not sure. Downgrading did not fix it though.
I have also installed a RMM software since then.
I noticed a log that said the local dns server was not running.
I am able to connect to a pod when port-forwarding.
The host file seems to be properly updated.
EDIT1:
I managed to reproduce by following the documentation. The only difference, I guess, is I am using the docker driver with wsl 2 instead of hyperv, but I read it was supported in another issue. Will try with hyperv.
EDIT2:
So it doesn't work using hyperv either, same problem.
The text was updated successfully, but these errors were encountered: