Change:
fs.BoolVar(&c.EnableDebuggingHandlers, "enable-debugging-handlers", c.EnableDebuggingHandlers, "Enables server endpoints for log collection and local running of containers and commands") fs.BoolVar(&c.EnableContentionProfiling, "contention-profiling", c.EnableContentionProfiling, "Enable block profiling, if profiling is enabled") fs.Int32Var(&c.HealthzPort, "healthz-port", c.HealthzPort, "The port of the localhost healthz endpoint (set to 0 to disable)") <del> fs.Var(&utilflag.IPVar{Val: &c.HealthzBindAddress}, "healthz-bind-address", "The IP address for the healthz server 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.HealthzBindAddress}, "healthz-bind-address", "The IP address for the healthz server to serve on (set to '0.0.0.0' or '::' for listening on all interfaces and IP address families)") </ins> fs.Int32Var(&c.OOMScoreAdj, "oom-score-adj", c.OOMScoreAdj, "The oom-score-adj value for kubelet process. Values must be within the range [-1000, 1000]") fs.StringVar(&c.ClusterDomain, "cluster-domain", c.ClusterDomain, "Domain for this cluster.  If set, kubelet will configure all containers to search this domain in addition to the host's search domains")

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?