microsoft / mindaro

Bridge to Kubernetes - for Visual Studio and Visual Studio Code
MIT License
307 stars 106 forks source link

Bridge to Kubernetes - failed to get routing manager deployment status #202

Open awarren-darwin opened 3 years ago

awarren-darwin commented 3 years ago

Describe the bug I've got a Minikube Kubernetes cluster running on my Macbook that contains 12 microservices, each running in its own pod. I'm trying to evaluate Bridge to Kubernetes in VSCode as a tool for allowing me to debug one of the Python microservices in VSCode. When I run the Bridge to Kubernetes wizard and attach to process Id, I get Error: Failed to get routing manager deployment status

To Reproduce

Expected behavior I'd expect the Bridge to Kubernetes extension setup to work in the manner described in the VSCode article on this extension - i.e. the VS Code Status bar to turn orange and the Kubernetes extension to show I am connected, with no error messages displayed.

*Logs

Executing task: bridge-to-kubernetes.resource <

Redirecting Kubernetes service filter-api to your machine... Target cluster: minikube Current cluster: minikube Target namespace: default Current namespace: default Target service name: filter-api Target service ports: 3000 Isolating service with routing header: user0-3138 Using kubernetes service environment variables: false

Retrieving the current context and credentials... Validating the credentials to access the cluster... Validating the requirements to replicate resources locally... Redirecting traffic from the cluster to your machine... Routing successfully enabled for service through pod 'user0-filter-api-bddd6f86d-lr5pb' in namespace 'default'. Waiting for 'user0-filter-api-bddd6f86d-lr5pb' in namespace 'default' to reach running state... Pod 'user0-filter-api-bddd6f86d-lr5pb' created in namespace 'default'. Remote agent deployed in container 'filter-api' in pod 'user0-filter-api-bddd6f86d-lr5pb'. Preparing to run Bridge To Kubernetes configured as pod default/user0-filter-api-bddd6f86d-lr5pb ... Connection established. Hosts file updated. Service 'xxx' is available on xxx.xxx.xxx.xxx. ... Container port 80 is available at localhost:3000. ##################### Environment started. ############################################################# Run /var/folders/jz/nwx5rk9d6xl220jzd73c3t8c0000gn/T/tmp-20877WMR5ydETZouj.env.cmd in your existing console to also get connected. Waiting for EndpointManager to come up ... EndpointManager came up successfully. Routing successfully enabled for service through pod 'user0-filter-api-7bf78b895f-pts6s' in namespace 'default'. Waiting for 'user0-filter-api-7bf78b895f-pts6s' in namespace 'default' to reach running state... Pod 'user0-filter-api-7bf78b895f-pts6s' created in namespace 'default'. Remote agent deployed in container 'filter-api' in pod 'user0-filter-api-7bf78b895f-pts6s'. Preparing to run Bridge To Kubernetes configured as pod default/user0-filter-api-7bf78b895f-pts6s ... Failed to get routing manager deployment status - ran out of time : 'Failed to get routing manager deployment status: 'Redirecting user service filter-api to its envoy pod for pod user0-filter-api-7bf78b895f-pts6s failed. 'Please include the following Correlation ID when contacting support: '8d637c8f-ea05-4068-9769-8e9bfcd7d8321626010508396:5f1fd1928cd6'. ' Stopping workload and cleaning up... Restore: Pod 'user0-filter-api-7bf78b895f-pts6s' deleted. Failed to establish a connection. Error: Failed to get routing manager deployment status - ran out of time : 'Failed to get routing manager deployment status: 'Redirecting user service filter-api to its envoy pod for pod user0-filter-api-7bf78b895f-pts6s failed. 'Please include the following Correlation ID when contacting support: '8d637c8f-ea05-4068-9769-8e9bfcd7d8321626010508396:5f1fd1928cd6'. '

Environment Details Client used: VS Code

Bridge to Kubernetes: v1.0.120210709 Client's version: Version: 1.57.1 (Universal) Commit: 507ce72a4466fbb27b715c3722558bb15afa9f48 Date: 2021-06-17T13:28:32.912Z (3 wks ago) Electron: 12.0.7 Chrome: 89.0.4389.128 Node.js: 14.16.0 V8: 8.9.255.25-electron.0 OS: Darwin x64 20.5.0 **Additional context** All microservices running in a Minikube cluster on my local dev MacBook.
daniv-msft commented 3 years ago

Thanks @awarren-darwin for logging this very complete issue, and sorry you encounter it.

We would need a bit more logs to investigate the routing manager issue you see but, before we go this way, there is something else I want to validate.

As you're working in a local Minikube cluster, I agree that you shouldn't need to run isolated and can answer "No" to this question. However from the logs, it seems that Bridge is still configured to run isolated (Isolating service with routing header: user0-3138). The routing manager is only used when running isolated, so you shouldn't even need it here.

Could you please validate in your .vscode/tasks.json file that there is no isolateAs field in the bridge-to-kubernetes.resource task? You can remove the whole field if it's present.

awarren-darwin commented 3 years ago

Thanks @daniv-msft for your response. I've repeated the process, this time selecting No to the isolation question. Now I don't get any error messages but the process seems to hang (the status bar doesn't turn orange); the last message printed is "Run /var/folders/jz/nwx5rk9d6xl220jzd73c3t8c0000gn/T/tmp-1127Wv3kM0NQQrd1.env.cmd in your existing console to also get connected."

Note that in the Problems tab, VSCode complains that "Property env is not allowed" in launch.json. I'm not sure if this is relevant to the issue. Here's the node:

        {
            "name": "Python: Attach using Process Id with Kubernetes",
            "type": "python",
            "request": "attach",
            "processId": "${command:pickProcess}",
            "preLaunchTask": "bridge-to-kubernetes.resource",
            "env": {
                "GRPC_DNS_RESOLVER": "native"
            }
        },
daniv-msft commented 3 years ago

@awarren-darwin Thanks for your reply. Could you please update your launch.json to remove this env object? Bridge injected this during the configuration, as we assumed that all debugger would support the env attribute to declare environment variables. It looks like it's not the case here, and that's what is causing the issue. We would need to have more granularity when we choose to add this environment variable.