Human readable service identification for loadbalancer frontend IPs

[tdihp]

What would you like to be added:

Add a indicator on which frontend IP address is for which service of which namespace, either as a part of LB comment (if that come to exist), or as a part of service status.

Why is this needed:

This will be more direct for users to see which service is relevant for which frontend IP object for troubleshooting, eliminate the need to crosscheck joining loadbalancer setting with the service yamls.

[nilo19]

Frontend IP configuration is not a network subresource so we cannot tag it. One possible solution is to tag the load balancer, but that would be messy if the number of frontend ip configs is big.

[tdihp]

Possible to just put a configmap in kube-system for the mapping?

[nilo19]

Possible to just put a configmap in kube-system for the mapping?

We need to consider if it's worth it creating a new resource just for clarification. The cost of checking this config map and checking the service uid would be pretty much the same.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten