Change:
stipulates, that IPVS is better than IPTABLES. This is reiterated at $ kube-proxy --help … There is a contradiction: the best-available proxy currently is iptables, while IPVS has advantages over iptables.
/sig network
I am not sure what is needed by this issue. Are you looking for clarification? /triage needs-information
Is iptables the best available proxy, or is ipvs better than iptables?
iptables had performance problems that the netfilter community have fixed during the last years, also it is the default mode and the most widely used. ipvs addressed those performance issues at the beginning and still has some heavy users, but since the changes in IPVS has to be implemented in the kernel has a slower evolution is not something that you can really compare as one is better than the other, just use the one that fits you best, if no preference use the default:
Since is something subjective, the output of shall not print It shall print instead . What does the above mean? Does IPVS rely on user-space, since its kernel implementation is incomplete. Do the “changes” exist somewhere?
The best available proxy for general use is , what is subjective is the use anybody want to give to the cluster :sweat_smile: I didn't say anything about incomplete, IPVS is implemented in the kernel , the kernel doesn't backport features, if you want feature X that is implemented in 5.6 kernel and you are in kernel 3.11, you have to upgrade your kernel and reboot the node, also the kernel is a huge project, development is slower than if you have your own userspace project
Is my reading correct, that in the 5.14 kernel there is no difference between IPVS and iptables? Do the arguments from still apply:
talks about “IPVS proxier”. Is the IPVS proxier the same as running or is it a separate software?
says: The latter stipulates, that ipvs is better than iptables, while states, that iptables is the best available proxy. As far as there is ordering between iptables and ipvs modes, the documentation contains contradictions about the order.
is better in , there are more dimensions to the comparison. Agree that the docs and comments are misleading, but I'm trying to figure out if we can help you in something or if you just want the docs to be more accurate. Is this because you are trying to get a full comparison of the proxies or do you need to choose between one or the other for something in particular?
I want the docs to be more accurate. I want to choose between iptables and ipvs . E.g. the documentation states, that iptables is the best, but it does not say how is it better than ipvs. In fact, it mentions how ipvs is better than iptables. If the comparison is subjective, then no general comparison between the the modes shall be made.
Agree, this realy makes misleading. i will try to fix it. /assign
/triage accepted There's a PR to fix the docs linked above, thanks
Agree that the documentation is confusing - "the best" is subjective. I believe to be the more stable and widely-used proxy at this point in time, which is likely where that wording came from. We should make it clear that the choice is highly dependent on the end-user's needs, but it's probably also important to make it clear that for many if not most users, "iptables" is going to be the correct option for them because it performs well enough for normal-scale clusters, and has the longest track-record. did you end up making a docs PR for this? /triage accepted
Oh man, beat me by a matter of seconds! I shouldn't have spent so long typing up that preamble :rofl:
type faster!
I already made a PR for this. PTAL

Discussion:
fs.Var(&utilflag.IPPortVar{Val: &o.config.MetricsBindAddress}, "metrics-bind-address", "The IP address with port for the metrics server to serve on (set to '0.0.0.0:10249' for all IPv4 interfaces and '[::]:10249' for all IPv6 interfaces). Set empty to disable. This parameter is ignored if a config file is specified by --config.") fs.BoolVar(&o.config.BindAddressHardFail, "bind-address-hard-fail", o.config.BindAddressHardFail, "If true kube-proxy will treat failure to bind to a port as fatal and exit") fs.Var(utilflag.PortRangeVar{Val: &o.config.PortRange}, "proxy-port-range", "Range of host ports (beginPort-endPort, single port or beginPort+offset, inclusive) that may be consumed in order to proxy service traffic. If (unspecified, 0, or 0-0) then ports will be randomly chosen.") <del> fs.Var(&o.config.Mode, "proxy-mode", "Which proxy mode to use: 'userspace' (older) or 'iptables' (faster) or 'ipvs' or 'kernelspace' (windows). If blank, use the best-available proxy (currently iptables). If the iptables proxy is selected, regardless of how, but the system's kernel or iptables versions are insufficient, this always falls back to the userspace proxy."+ </del> <ins> fs.Var(&o.config.Mode, "proxy-mode", "Which proxy mode to use: 'iptables' (Linux-only), 'ipvs' (Linux-only), 'kernelspace' (Windows-only), or 'userspace' (Linux/Windows, deprecated). The default value is 'iptables' on Linux and 'userspace' on Windows."+ </ins> "This parameter is ignored if a config file is specified by --config.") fs.Var(cliflag.NewMapStringBool(&o.config.FeatureGates), "feature-gates", "A set of key=value pairs that describe feature gates for alpha/experimental features. "+ "Options are:n"+strings.Join(utilfeature.DefaultFeatureGate.KnownFeatures(), "n")+