Skip to content
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

misleading comments in container.Ports #108255

Closed
j4m3s-s opened this issue Feb 21, 2022 · 7 comments · Fixed by #110564
Closed

misleading comments in container.Ports #108255

j4m3s-s opened this issue Feb 21, 2022 · 7 comments · Fixed by #110564
Labels
kind/bug Categorizes issue or PR as related to a bug. sig/network Categorizes an issue or PR as relevant to SIG Network. triage/accepted Indicates an issue or PR is ready to be actively worked on.

Comments

@j4m3s-s
Copy link
Contributor

j4m3s-s commented Feb 21, 2022

What happened?

The comments in

// List of ports to expose from the container. Exposing a port here gives
says that :

Exposing a port here gives
the system additional information about the network connections a
container uses, but is primarily informational.

However there are several cases where this is false :

  • When using a Service with a targetPort that references a name in the ports arrays of the pod.
  • Some software (ab)uses this API to get which ports are used (See Patching ports in PodSpec leads to empty diff #108131 Although unfixable, my goal is to fix the documentation so other people don't have the same problem). The Azure Load Balancer implementation does this for instance.
  • Some other network/security software might use this information.

Also, is it possible to document/reference the above issue in the comment ?

What did you expect to happen?

Since it is described as informational I expected for the network to work without this information. But it's definitely not the case.

How can we reproduce it (as minimally and precisely as possible)?

Not needed since it's mostly a doc issue.

Anything else we need to know?

I'm interested in contributing this patch but would like some feedbacks before doing it. :)

Kubernetes version

$ kubectl version
# paste output here

Cloud provider

OS version

# On Linux:
$ cat /etc/os-release
# paste output here
$ uname -a
# paste output here

# On Windows:
C:\> wmic os get Caption, Version, BuildNumber, OSArchitecture
# paste output here

Install tools

Container runtime (CRI) and and version (if applicable)

Related plugins (CNI, CSI, ...) and versions (if applicable)

@j4m3s-s j4m3s-s added the kind/bug Categorizes issue or PR as related to a bug. label Feb 21, 2022
@k8s-ci-robot k8s-ci-robot added needs-sig Indicates an issue or PR lacks a `sig/foo` label and requires one. needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. labels Feb 21, 2022
@j4m3s-s
Copy link
Contributor Author

j4m3s-s commented Feb 21, 2022

/sig network

@k8s-ci-robot k8s-ci-robot added sig/network Categorizes an issue or PR as relevant to SIG Network. and removed needs-sig Indicates an issue or PR lacks a `sig/foo` label and requires one. labels Feb 21, 2022
@khenidak
Copy link
Contributor

khenidak commented Mar 1, 2022

/triage accepted

@thockin -- thoughts? I believe the doc are due for a refresh.

@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 Mar 1, 2022
@cyclinder
Copy link
Contributor

I'd take this one.
/assign

@cyclinder
Copy link
Contributor

I didn't see that you wanted to do this patch, I am very sorry and now I unassign it.
/unassign

@j4m3s-s
Copy link
Contributor Author

j4m3s-s commented Mar 22, 2022

No worries @cyclinder. But I'm still not sure where / what to add. Should I only fix the part saying it is only informational ? Is there anything else ? (cc @khenidak @thockin)

@k8s-triage-robot
Copy link

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

This bot triages issues and PRs 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 or PR as fresh with /remove-lifecycle stale
  • Mark this issue or PR as rotten with /lifecycle rotten
  • Close this issue or PR with /close
  • Offer to help out with Issue Triage

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

/lifecycle stale

@k8s-ci-robot k8s-ci-robot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Jun 20, 2022
@j4m3s-s
Copy link
Contributor Author

j4m3s-s commented Jun 20, 2022

/remove-lifecycle stale

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug Categorizes issue or PR as related to a bug. sig/network Categorizes an issue or PR as relevant to SIG Network. 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.

5 participants