Change:
fs.DurationVar(&c.HTTPCheckFrequency.Duration, "http-check-frequency", c.HTTPCheckFrequency.Duration, "Duration between checking http for new data") fs.StringVar(&c.StaticPodURL, "manifest-url", c.StaticPodURL, "URL for accessing additional Pod specifications to run") fs.Var(cliflag.NewColonSeparatedMultimapStringString(&c.StaticPodURLHeader), "manifest-url-header", "Comma-separated list of HTTP headers to use when accessing the url provided to --manifest-url. Multiple headers with the same name will be added in the same order provided. This flag can be repeatedly invoked. For example: --manifest-url-header 'a:hello,b:again,c:world' --manifest-url-header 'b:beautiful'") <del> fs.Var(&utilflag.IPVar{Val: &c.Address}, "address", "The IP address for the Kubelet to serve on (set to '0.0.0.0' or '::' for listening in all interfaces and IP families)") </del> <ins> fs.Var(&utilflag.IPVar{Val: &c.Address}, "address", "The IP address for the Kubelet to serve on (set to '0.0.0.0' or '::' for listening on all interfaces and IP address families)") </ins> fs.Int32Var(&c.Port, "port", c.Port, "The port for the Kubelet to serve on.") fs.Int32Var(&c.ReadOnlyPort, "read-only-port", c.ReadOnlyPort, "The read-only port for the Kubelet to serve on with no authentication/authorization (set to 0 to disable)")

Discussion:
The docs are ambiguous on whether a socket will be limited to either the IPv4 or IPv6 address familiy. E.g., contains This wording in bold suggests that when is 0.0.0.0, the API server will listen on IPv6 addresses too, potentially. That would be incorrect and prevent limiting the address family from the config (to enforce single-stack). According to a report to me, indeed this incorrect behavior is the case. In any case, the wording is ambiguous. Moreover, the source code base contains quite a few literals that aren't accompanied by , suggesting that IPv4 is assumed in some paths. Unless ... Kubernetes has this special algorithm that equates either {0.0.0.0} or {::} with {0.0.0.0, ::}.
See:
/sig docs
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /sig doc Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig docs
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, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue as fresh with Close this issue with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale
that code is used to discover the advertised address if that is not provided, the family of the IP is used for the discovery. The bind address is passed as is to the listener and in golang, 0.0.0.0 and :: behaves the same, it opens a socket in all the addresses in the host The doc is correct
The docs are ambiguous since the behavior rather than being logical, relies on a Go-based implementation detail.
I can't understand why do you consider it ambiguous if that defines exactly what is going to happen. yeah, sometimes this happens unfortunately, but we can't do much about it without breaking compatibility, can we?

All interfaces could mean all interfaces for the specified address family, or all interfaces across address families. The latter is bizarre (non-standard and unproductive), but the actual behavior. What Go does and that Kubernetes exposes this behavior to the user without modification should be documented.
How do you word it then?
Can you explain where the difficulty is in reading and interpreting my comments? For me, it can't be any clearer.
lol, sorry, now I got it, I was confused because I remembered to change some of them to clarify exactly this and I was not realizing this flag was not correct. It is my fault , I honestly don't know why omitted the IP families but you are right, my apologies again , it was some kind of frequency illusion or bias. This is a good first issue for someone that wants to do a contribution to the project, just update this line I think is easy to understand and is coherent with the other flags /help /triage accepted
This request has been marked as needing help from a contributor. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : Can you explain where the difficulty is in reading and interpreting my comments? For me, it can't be any clearer. and I was not realizing this flag was not correct. /triage accepted Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
I suggest then:
/assign
Hi, I see that there are another instances where "for listening in all interfaces and IP families" appear, like in: I am thinking to include them along with the change on "" file when submitting a PR WDYT?