ContainsIPv4Loopback() claimed that "::/0" contains IPv4 loopback IPs
(on the theory that listening on "::/0" will listen on "0.0.0.0/0" as
well and thus include IPv4 loopback). But its sole caller (the
iptables proxier) doesn't use listen() to accept connections, so this
theory was completely mistaken; if you passed, eg,
`--nodeport-addresses 192.168.0.0/0,::/0`, then it would not create
any rule that accepted nodeport connections on 127.0.0.1, but it would
nonetheless end up setting route_localnet=1 because
ContainsIPv4Loopback() claimed it needed to. Fix this.
Add names to the tests and use t.Run() (rather than having them just
be numbered, with number 9 mistakenly being used twice thus throwing
off all the later numbers...)
Remove unnecessary FakeNetwork element from the testCases struct since
it's always the same. Remove the expectedErr value since a non-nil
error is expected if and only if the returned set is nil, and there's
no reason to test the exact text of the error message.
Fix weird IPv6 subnet sizes.
Change the dual-stack tests to (a) actually have dual-stack interface
addrs, and (b) use a routable IPv6 address, not just localhost (given
that we never actually want to use IPv6 localhost for nodeports).
The `find` tool has hard to comprehend syntax and does not consider
things excluded by .gitignore. I keep tripping over this in my own
repos, where I have __stuff which gets found.
This converts update-codegen to use `git ls-files` in a seemingly
equivalent way (`-cmo --exclude-standard`). I verified it finds the
same set of files as before.
This also drops some obsolete filtering.
Also hide grep errors for not-found files, which can happen if a file is
removed but git ls-files still knows it.
Re-running update-codegen shows no diffs.
This will make subsequent changes easier.
Don't just grep for DO NOT EDIT - anchor it in something that looks like
a comment and alone on a line.
Also ignore __* dirs
Prevent it from triggering on update-generated-swagger-docs (hack, but
better than before)
The env vars are needed until go workspaces lands, then it can get
simpler.
Downsides to this:
1) If you don't call kube::golang::setup_env, it might work but will
just splat results somewhere
2) The resultant binaries are not in _output/bin but instead in the
phony GOPATH/bin (which setup_env puts in PATH)
When trying to bring up a cluster via kubeadm with these feature gates enabled,
kube-proxy fails because it didn't know about them:
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
- role: control-plane
- role: worker
- role: worker
featureGates: {"DynamicResourceAllocation":true,"ContextualLogging":true}
runtimeConfig: {"resource.k8s.io/v1alpha1":"true"}
=>
2023-01-20T07:07:54.474966617Z stderr F E0120 07:07:54.474846 1 run.go:74] "command failed" err="failed complete: unrecognized feature gate: ContextualLogging"
The effect of the logging feature gates is minor for kube-proxy, supporting
them is mostly useful for the sake of consistency and to support kubeadm.
Since we need to gather kubelet metrics for CPU Manager and Topology
Manager, renaming this function to a more generic name.
Signed-off-by: Swati Sehgal <swsehgal@redhat.com>