data-plane self registration

[ndr-brt]

Currently, when a new data-plane is added to a cluster, it needs to be manually registered on the control-plane through the selector api.

Could be a good feature to have the data-plane being able to configure itself to the control-plane if configured to do so?

Thoughts and feedback appreciated.

[ghost]

Since this discussion is related to #2188, I would be happy to see such a feature!

[jimmarino]

In a production environment, this can pose a security risk if a data plane can register itself with the control plane without safeguards.

I think there are two aspects to this. First, the control plane must be explicitly configured with the data planes it trusts. The second aspect is discovery: how does a trusted data plane advertise its endpoint address to the control plane when it is not known ahead of time or may dynamically change?

To solve both issues, why not just add configuration to the control plane to have one or more data plane entries with DNS names and rely on K8S or some other system that provides DNS services to handle the resolution?

[jimmarino]

We have already discussed this. Please keep any questions here so others can follow.

[mhellmeier]

Is it possible to provide us with some more information, @jimmarino? As suggested in your reply:

Happy to discuss via Discord.

We started a discussion on Discord without any answers. Since you wrote:

We have already discussed this. Please keep any questions here so others can follow.

It would be great if you could update us with the latest information, a possible status of the development, or where we can find the results of the discussion.

[paullatzelsperger]

Self-registration sounds like a nice solution on the surface, but the problems begin to pile up when thinking about replicated dataplanes in a cluster:

The registration operation would have to be idempotent: when the pod crashes, and restarts it would have to re-register, and the selector would have to overwrite the old instance, effectively resulting in a re-registration. Same thing when multiple replica are involved. It sounds a bit weird, but it could be done easily in an extension.

Instance counters could be a more elaborate solution, but the next problem then surfaces when thinking about de-registration: how is a pod going to self-deregister? You cannot assume it reliably deregisters, especially after crashing, so it won't necessarily decrement the counter, so you'll have to start sending heartbeats, at which point you could also consider the following solution:

write a Kubernetes operator that hooks into deployment an undeployment of replica sets, and execute the REST requests against the selector API. Not sure how you would get authentication tokens into the operator, but assuming that's handled, it could be a way to go.

TL;DR: either of those two solutions could be viable solutions, but due to their specific nature are not fit for general use, thus I don't think they should go in upstream EDC.

[ghost]

Instance counters could be a more elaborate solution, but the next problem then surfaces when thinking about de-registration: how is a pod going to self-deregister? You cannot assume it reliably deregisters, especially after crashing, so it won't necessarily decrement the counter, so you'll have to start sending heartbeats, at which point you could also consider the following solution:

Isn't de-registration a general problem independent of self-registration? Regardless of the deployment type and scaling, there is no de-registration if the DP crashes, right? How is this solved so far?

I'm still new to the EDC world, but isn't the DP stateless? Then I would assume that the CP communicates with the DP via k8s Service/Ingress endpoints and does not have to worry about the replicas?

[paullatzelsperger]

So far, registration and deregistration are handled out-of-band through API calls.

registration should happen when the DP gets deployed, and similarly, deregistration should happen when the dataplane gets undeployed. There are several ways to achieve this, a K8S operator could be one, infra tools like ansible or terraform or even plain bash scripts are others.

Other "intrinsic" approaches, such as self-registration, suffer from drawbacks. However, in certain scenarios it might still be a workable, if imperfect, solution. Thinking about smaller, less complex deployments, or in lab/test environments.

All in all though, solutions are either very deployment-specific (ansible, terraform, scripts...) or are not really clean (self-registration). Naturally, everyone can extend EDC to their heart's content, and craft whatever solution fits their needs.

Don't know if we'd ever consider writing a K8S operator, but I would not hold my breath.

you are correct, the DP Selector does not care about DP replicas.