kube-proxy refuses to accept any arguments

[sdoncho]

Environmental Info:
K3s Version:
k3s version v1.30.5+k3s1 (9b58670)
go version go1.22.6

Node(s) CPU architecture, OS, and Version:
Linux ks-web-eu-ld01 6.8.0-31-generic #31-Ubuntu SMP PREEMPT_DYNAMIC Sat Apr 20 00:40:06 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

Cluster Configuration:
3 servers, many agents.

When trying to set proxy-mode=ipvs on kube-proxy, the setting is overwritten, irrespective of how I try to pass it.

Currently trying to pass it via config: /etc/rancher/k3s/config.yaml:

node-label:
- "test=foo"
kube-proxy-arg:
- "proxy-mode=ipvs"

The config gets read and the nodes gets labeled. But the proxy-mode is nowhere to be seen. Here are the logs from the k3s-agent that show the proxy mode is still iptables on kube-proxy:
Sep 17 20:19:10 ks-00 k3s[13599]: time="2024-09-17T20:19:10Z" level=info msg="Running kube-proxy --cluster-cidr=10.42.0.0/16 --conntrack-max-per-core=0 --conntrack-tcp-timeout-close-wait=0s --conntrack-tcp-timeout-established=0s --healthz-bind-address=127.0.0.1 --hostname-override=ks-00 --kubeconfig=/var/lib/rancher/k3s/agent/kubeproxy.kubeconfig --proxy-mode=iptables"

[brandond]

Seems to work fine for me. I suspect you're doing something else wrong, or perhaps looking at old logs - Did you really try this most recently on September 17th?

root@systemd-node-1:~# k3s --version
k3s version v1.30.5+k3s1 (9b586704)
go version go1.22.6

root@systemd-node-1:~# cat /etc/rancher/k3s/config.yaml
node-label:
- "test=foo"
kube-proxy-arg:
- "proxy-mode=ipvs"

root@systemd-node-1:~# journalctl --since "2024-10-23" -u k3s | grep "Running kube-proxy"
Oct 23 17:40:59 systemd-node-1 k3s[248914]: time="2024-10-23T17:40:59Z" level=info msg="Running kube-proxy --cluster-cidr=10.42.0.0/16 --conntrack-max-per-core=0 --conntrack-tcp-timeout-close-wait=0s --conntrack-tcp-timeout-established=0s --healthz-bind-address=127.0.0.1 --hostname-override=systemd-node-1 --kubeconfig=/var/lib/rancher/k3s/agent/kubeproxy.kubeconfig --proxy-mode=ipvs"

[sdoncho]

@brandond you are right, I was looking at an old log. I can't believe I opened this issue 🙈. So sorry. I swear I spent 8 hours trying to figure this out first, knowing that in 9/10 times it is a user error.