cilium: disable bind-protection in kube-proxy free probe mode #14182
Conversation
The probe mode is expected to only run alongside kube-proxy as hybrid. There was confusion that the kube-proxy log was throwing (harmless) warnings to its log that it could not bind sockets to service ports in the hostns. This is due to Cilium performing bind protection right out of the bind(2) syscall with eBPF. To avoid this confusion, defer to kube-proxy to bind sockets instead. This is less efficient and consuming more resources, but if users want to avoid the overhead, they would run kube-proxy free in strict mode anyway where Cilium does the bind protection by default anyway. Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
maintainer-s-little-helper
bot
added
the
dont-merge/needs-release-note-label
borkmann
added
the
release-note/misc
maintainer-s-little-helper
bot
removed
the
dont-merge/needs-release-note-label
borkmann
added
area/daemon
| // We let kube-proxy do the less efficient bind-protection in | ||
| // this case to avoid the latter throwing (harmless) warnings | ||
| // to its log that bind request is rejected. | ||
| option.Config.NodePortBindProtection = false |
There was a problem hiding this comment.
Do we want to log something (e.g., info message) when we overwrite this setting?
There was a problem hiding this comment.
I was thinking about it, definitely not a warn, but won't people just ignore and never read the info messages? How effective is it? Dunno.. either way from user side it should be transparent. One thing we could do which I think makes sense either way is to extend cilium status --verbose with the full kpr settings so all is visible at once.
There was a problem hiding this comment.
I was thinking that anyone who notices the option is not taking effect (because it was overwritten) will likely check the logs. Apart from the documentation (static & verbose), the logs are pretty much the only opportunity we have of explaining what's happening (at runtime) to users. I agree it shouldn't be a warning.
👍 on cilium status --verbose
There was a problem hiding this comment.
Ok, I'll extend status in general on kpr a bit, but as separate PR then. (and can also add the info msg)
|
test-me-please |
maintainer-s-little-helper
bot
moved this from Needs backport from master
to Backport pending to v1.8
in 1.8.6
maintainer-s-little-helper
bot
moved this from Needs backport from master
to Backport pending to v1.9
in 1.9.1
maintainer-s-little-helper
bot
moved this from Backport pending to v1.9
to Backport done to v1.9
in 1.9.1
maintainer-s-little-helper
bot
moved this from Backport pending to v1.9
to Backport done to v1.9
in 1.9.1
maintainer-s-little-helper
bot
moved this from Backport pending to v1.8
to Backport done to v1.8
in 1.8.6
The probe mode is expected to only run alongside kube-proxy as hybrid.
There was confusion that the kube-proxy log was throwing (harmless) warnings
to its log that it could not bind sockets to service ports in the hostns.
This is due to Cilium performing bind protection right out of the bind(2)
syscall with eBPF. To avoid this confusion, defer to kube-proxy to bind
sockets instead. This is less efficient and consuming more resources, but
if users want to avoid the overhead, they would run kube-proxy free in strict
mode anyway where Cilium does the bind protection by default anyway.
Signed-off-by: Daniel Borkmann daniel@iogearbox.net