If users don't pass any --nodeport-addresses, suggest they should pass
`--nodeport-addresses primary`, to avoid accepting NodePort
connections on all interfaces.
If users pass a single-stack --nodeport-addresses in what looks like a
dual-stack cluster, warn them that they probably ought to be passing a
dual-stack --nodeport-addresses.
The behavior when you specify no --nodeport-addresses value in a
dual-stack cluster is terrible and we can't fix it, for
backward-compatibility reasons. Actually, the behavior when you
specify no --nodeport-addresses value in a single-stack cluster isn't
exactly awesome either...
Allow specifying `--nodeport-addresses primary` to get the
previously-nftables-backend-specific behavior of listening on only the
node's primary IP or IPs.
The winkernel code was originally based on the iptables code but never
made use of some parts of it. (e.g., it logs a warning if you didn't
set `--cluster-cidr`, even though it doesn't actually use
`--cluster-cidr` if you do set it.)
Currently, there are some unit tests that are failing on
Windows due to various reasons:
- Different "File not found" error messages on Windows.
- Files need to be closed on Windows before removing them.
- The default RootHnsEndpointName (root-hnsendpoint-name) flag value is 'cbr0'
- On Windows, Unix Domain sockets are not checked in the same way in golang, which is why
hostutils_windows.go checks for it differently. GetFileType will return an error in this
case. We need to check for it, and see if it's actually a Unix Domain Socket.
NFTables proxy will now drop traffic directed towards unallocated
ClusterIPs and reject traffic directed towards invalid ports of
Cluster IPs.
Signed-off-by: Daman Arora <aroradaman@gmail.com>
This replaces the klog formatting and message routing with a simpler
implementation that uses less code. The main difference is that we skip the
entire unused message routing.
Instead, the same split output streams as for JSON gets implemented in the
io.Writer implementation that gets passed to the textlogger.
* cmd/kube-proxy support contextual logging
Signed-off-by: Ziqi Zhao <zhaoziqi9146@gmail.com>
* use ktesting.NewTestContext(t) in unit test
Signed-off-by: Ziqi Zhao <zhaoziqi9146@gmail.com>
* use ktesting.NewTestContext(t) in unit test
Signed-off-by: Ziqi Zhao <zhaoziqi9146@gmail.com>
* remove unnecessary blank line & add cmd/kube-proxy to contextual section in logcheck.conf
Signed-off-by: Ziqi Zhao <zhaoziqi9146@gmail.com>
* add more contextual logging
Signed-off-by: Ziqi Zhao <zhaoziqi9146@gmail.com>
* new lint yaml
Signed-off-by: Ziqi Zhao <zhaoziqi9146@gmail.com>
---------
Signed-off-by: Ziqi Zhao <zhaoziqi9146@gmail.com>
And update most of the comments to refer to "nftables" rather than
"iptables" (even though it doesn't actually do any nftables updating
at this point).
For now the proxy also internally creates a
utiliptablestesting.FakeIPTables to keep the existing sync code
compiling.
A new --init-only flag is added tha makes kube-proxy perform
configuration that requires privileged mode and exit. It is
intended to be executed in a privileged initContainer, while
the main container may run with a stricter securityContext
When parsing a config file, all settings derived from command line flags are
discarded because only the config settings are used. That has been the
traditional behavior for non-logging flags.
But `--config ... -v=4` used to work until
71ef0dafa7 added logging to the configuration.
To restore the original behavior, kube-proxy now:
- parses flags
- reads the config file
- applies logging settings from the flags to the config loaded from file
- uses that merged config