Remote cluster services are not available on local development machine

[vBitza]

I'm not sure what I'm doing wrong but I can't seem to get the remote services to be available for the app I'm trying to debug on the remote cluster.

This is my KubernetesLocalProcessConfig.yaml:

version: 0.1
volumeMounts:
  - name: ca.crt
    localPath: /var/run/secrets/kubernetes.io/serviceaccount
env:
  - name: umms
    value: $(services:useradminms-srv.production:80)

The app/pod/service (whatever you want to call it) that I'm trying to debug needs to connect to this useradminms-srv which is available and running on the remote cluster. The yaml config seems to be ok, the entry is added in the hosts file:

# Added by Bridge To Kubernetes
127.1.1.42 useradminms-srv.production.svc.cluster.local

I can even get the variable using process.env.umms from my application but the request doesn't seem to work. This is the error message from the Axios request: 'connect ETIMEDOUT 127.1.1.42:80'

I must be missing something out but I just can't figure it out.

[pragyamehta]

Hi @vBitza From the service you are debugging, how are you calling useradminms-srv in production namespace? Please share the code for the call.

Which namespace is the service that you are debugging deployed? Is it in production namespace or some other namespace?

[vBitza]

Hi! This is what I'm trying to use:

    const getPermissionsRequestOptions = {
        method: 'GET',
        url: `http://${process.env.umms}/api/v1/UserManagement/customerGroups/permissions/${groupName}`
    };

    let response = axios(getPermissionsRequestOptions).then((response) => {
        return _.filter(response.data, (item) => permissions.list.indexOf(item.name) !== -1);
    }).catch((error) => {
            console.log(error)
        })

Please note that I've tried multiple variants, including adding the port of the service. I've even tried to use the default env variables created by Kubernetes. (USERADMINMS_SRV_SERVICE_HOST, USERADMINMS_SRV_SERVICE_PORT). And yes, both services are inside the same namespace: production. I've read through the issues on Github and there supposedly should be a pod named routing (can't recall the full name) deployed on the remote stack aswell? I've checked the remote stack but I don't see such pod, could this be the root cause?

[pragyamehta]

@vBitza Are you using Bridge in isolated or non-isolated mode? If in isolated mode, then you should be seeing a routing manager deployed to your namespace. Can you please share the client logs on your machine? 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

[pragyamehta]

@vBitza Forgot to add - if both services are in the same namespace, you do not have to specify useradminms-srv in the KubernetesLocalProcesConfig.yaml file. We automatically make all services in the same namespace available to the code being debugged locally. Can you please try the scenario without the entry for useradminms-srv in the file? Thanks!

[vBitza]

Hi. I've tried removing the service from KubernetesLocalProcesConfig.yaml and nothing changed but when adding it back it looks like it can't even discover it anymore. I've tried looking at other services from the remote stack and it looks like they are succesfully being forwarded to my local machine. Tried connecting/disconnecting the Bridge multiple times and it looks like the same services are not being recognized reccurently (useradmin-ms being one of them).

I've looked over the services and it seems that only services that are of type ClusterIP are being forwarded while type NodePort services are not forwarded. Log files: https://drive.google.com/file/d/1wIV3iDFrDCazKopwjM4LU7dxUfGvgNIg/view?usp=sharing

[pragyamehta]

@vBitza You are correct, we do not make services of type NodePort available on the local machine when debugging with Bridge to Kubernetes. I have logged a bug on our side to support this. Thanks for reporting this issue!

[vBitza]

Ah I see. Well then I guess this can be closed. Thanks for the response! Have a nice day 😄