Skip to content

Add TrafficDistribution field to describe service output #1736

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
08volt opened this issue Apr 16, 2025 · 5 comments · Fixed by kubernetes/kubernetes#131491
Closed

Add TrafficDistribution field to describe service output #1736

08volt opened this issue Apr 16, 2025 · 5 comments · Fixed by kubernetes/kubernetes#131491
Assignees
Labels
kind/feature Categorizes issue or PR as related to a new feature. triage/accepted Indicates an issue or PR is ready to be actively worked on.

Comments

@08volt
Copy link

08volt commented Apr 16, 2025

Motivation:

Kubernetes 1.31 introduced the TrafficDistribution field within the Service specification (spec.trafficDistribution). This field allows users to specify preferences for how traffic should be distributed among endpoints, such as the PreferClose option.

The official documentation describing this feature is here:
https://kubernetes.io/docs/reference/networking/virtual-ips/#traffic-distribution

Currently, kubectl describe service <service-name> does not display this field, even if it is set on the Service object.

Problem:

Users who configure spec.trafficDistribution on their Services lack a straightforward way to view or verify the applied setting using the standard kubectl describe command. They must resort to fetching the full YAML/JSON (kubectl get svc <service-name> -o yaml) and manually inspecting the spec.

Proposed Solution:

Modify the output of kubectl describe service to include the TrafficDistribution field when it is present and non-empty in the Service spec.

The output could look similar to how other optional spec fields like ExternalTrafficPolicy or InternalTrafficPolicy are displayed, for example:

...
Session Affinity: None
External Traffic Policy: Cluster
Internal Traffic Policy: Cluster
Traffic Distribution: PreferClose # <-- Add this line when field is set
HealthCheck NodePort:
Events:
...

Benefits:

  • Increased Visibility: Provides users with a complete view of the Service configuration directly within the commonly used describe output.
  • Easier Debugging: Helps users quickly verify the traffic distribution settings when diagnosing service routing behavior.
  • Improved User Experience: Aligns kubectl describe with the API capabilities introduced in recent Kubernetes versions.
@08volt 08volt added the kind/feature Categorizes issue or PR as related to a new feature. label Apr 16, 2025
@k8s-ci-robot k8s-ci-robot added the needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. label Apr 16, 2025
@mpuckett159
Copy link
Contributor

/triage accept
We would accept a PR for this. The describe command output is rather straight forward as it just uses basic line printing.

@k8s-ci-robot
Copy link
Contributor

@mpuckett159: The label(s) triage/accept cannot be applied, because the repository doesn't have them.

In response to this:

/triage accept
We would accept a PR for this. The describe command output is rather straight forward as it just uses basic line printing.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

@mpuckett159
Copy link
Contributor

/triage accepted

@k8s-ci-robot k8s-ci-robot added triage/accepted Indicates an issue or PR is ready to be actively worked on. and removed needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. labels Apr 23, 2025
@tchap
Copy link
Contributor

tchap commented Apr 26, 2025

If you don't mind,

/assign

@08volt
Copy link
Author

08volt commented May 7, 2025

Thanks @tchap

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature Categorizes issue or PR as related to a new feature. triage/accepted Indicates an issue or PR is ready to be actively worked on.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants