You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We want to deploy beyla to our environments, however for us the current service discovery mechanism is not working.
In Kubernetes a common way to select services is via labels. This is how usually other operator or controllers select applicable workloads.
Would it be possible to add a label selector to the Kubernetes service discovery mechanism?
I would also be willing to contribute a PR.
Using the current structure would only allow a hack of adding a single regexp matcher on the entire labels of a pod, as the processAttrs.metadata only allows a map[string]string{}.
So we probably would have to add a new config structure to accommodate a label selector.
Another question would be if it should be an actual label selector (meaning we will use this also for filtering out pods directly from the Kube api server), or if it will be a simple regexp match on the pod labels, same as we already do with the other Kubernetes metadata attributes.
What are your thoughts on this?
The text was updated successfully, but these errors were encountered:
Hello and thanks for this awesome project!
We want to deploy beyla to our environments, however for us the current service discovery mechanism is not working.
In Kubernetes a common way to select services is via labels. This is how usually other operator or controllers select applicable workloads.
Would it be possible to add a label selector to the Kubernetes service discovery mechanism?
I would also be willing to contribute a PR.
Using the current structure would only allow a hack of adding a single regexp matcher on the entire labels of a pod, as the
processAttrs.metadata
only allows amap[string]string{}
.So we probably would have to add a new config structure to accommodate a label selector.
Another question would be if it should be an actual label selector (meaning we will use this also for filtering out pods directly from the Kube api server), or if it will be a simple regexp match on the pod labels, same as we already do with the other Kubernetes metadata attributes.
What are your thoughts on this?
The text was updated successfully, but these errors were encountered: