search

hazelcast / hazelcast-csharp-client

Hazelcast .NET Client
https://hazelcast.com/clients/dotnet/
Apache License 2.0
102 stars 49 forks source link

Support for kubernetes (API) discovery #439

Closed drieseng closed 3 years ago

drieseng commented 3 years ago

Is support for discovery using the kubernetes API - similar to hazelcast-kubernetes - scheduled for the .NET client? If yes, when can we expect this to be available?

drieseng commented 3 years ago

To clarify a little more: We have a Hazelcast cluster running on OpenShift (which uses K8s), and a multi-node .NET application that runs on Windows.

Right now, the .NET application is configured to access Hazelcast as unisocket client. This is clearly documented here to result in low performance.

Is work underway to support smart client in combination with K8s where the client is not running in K8s? As far as I'm aware, this would require use of Kubernetes API to discover the cluster members. However, the Conclusion section of the blog post - linked to above - mentions that other solutions are being worked on.

zpqrtbnk commented 3 years ago

Oh - never realized noone ever replied to this issue, while we were actually working on it! The Kubernetes discovery API which allows you to configure the Hazelcast client in Smart Routing mode (vs unisocket) is going to be supported in the upcoming v5 release of the client. No exact release date but we are talking weeks, not months.

drieseng commented 2 years ago

@zpqrtbnk Can you explain how we should configure the client to use the Kubernetes discovery API? In Java, you can specify the kubernete namespace and service name:

config.getNetworkConfig().getJoin().getKubernetesConfig().setEnabled(true)
      .setProperty("namespace", "MY-KUBERNETES-NAMESPACE")
      .setProperty("service-name", "MY-SERVICE-NAME");

What's the corresponding .NET code?

zpqrtbnk commented 2 years ago

I am suddenly afraid there has been some confusion with this issue. All our tests, and all the work that has been done, ensure that one can connect to a Kubernetes cluster using the method described in the tutorials, i.e. connect to 1 entry point (can be a load-balanced pod) and then handle the members list received from the cluster. Our tests with running the client within the k8 environment worked the same. Sounded good at that time.

Now, from what I have learned about discovery since, plus reading docs... I realize the .NET client still does not implement the "Kubernetes API discovery" just as it does not implement AWS etc. Feeling silly now.

Guess we need to put it back onto our backlog?