search

microsoft / mindaro

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

Endpoint manager does not work when Dapr sidecar in the pod #260

Closed pandagodyyy closed 2 years ago

pandagodyyy commented 2 years ago

Hello everyone,

I found a situation that when pod has Dapr sidecar, the endpoint manager does not work, the local hosts file is not modified as well. so that it block the communication from local workload to service in the cluster.

I saw there is Dapr compatibility backlog in your roadmap. Is it related to my issue? If so, is there some solution from you side to support it? If not related, I will provide steps to reproduce issue

Regards, George

lolodi commented 2 years ago

Hi George, Dapr is currently supported (without isolation). I just tried with the sample "hello-kubernetes" app (from the Dapr repo) and it works fine debugging the node service. Do you have isolation on in your configuration? What errors do you get? Could you share your logs? On Windows you can find them under %TEMP%/Bridge To Kubernetes/ If you prefer you can share your logs via email at: bridgetok8s-talk@microsoft.com

Thanks, Lorenzo

pandagodyyy commented 2 years ago

@lolodi , the email was sent

lolodi commented 2 years ago

@pandagodyyy, I double checked and the expected behavior, with a Dapr workload, is to not start the EndpointManager. The assumption is that the workload is using Dapr to talk to the other services so they do not need to be mapped locally, only the remote Dapr sidecar needs to be made available. If, in your case, you still need to have some of the other services accessible directly, you can add them manually using the KubernetesLocalProcessConfig.yaml. Let me know if this works for you.

pandagodyyy commented 2 years ago

Actually I have Istio sidecar as well in the pod. So for the service mesh I prefer use Istio instead of Dapr. After the services added into KubernetesLocalProcessConfig.yaml, my local workload is able to call other services in the cluster. thanks for your walkaround soultion. @lolodi However there is some limitation for the Dapr api. the http port of dapr is 3500, and it is mapped to 55051 by the bridge. So if developer use hardcode like "localhost:3500" in the code, then the local workload cannot talk with dapr in the cluster. But I found if I use Java SDK of Dapr , it is smart to detect the new mapped port. Anyway, I'm happy to see the bridge can work with dapr :)

lolodi commented 2 years ago

@pandagodyyy , glad the config file worked for you. Your code should consume the DAPR ports using the environment variables DAPR_HTTP_PORT and DAPR_GRPC_PORT as documented here https://docs.dapr.io/reference/environment/ . I believe the JAVA SDK is smart by using the environment variables instead of hardcoded values.