ServiceLB back after auto-upgrade; k3s seems to ignore parameters from systemd unit after upgrade about k3s HOT 6 CLOSED

My k3s.service

[Unit]
Description=Lightweight Kubernetes
Documentation=https://k3s.io
Wants=network-online.target
After=network-online.target

[Install]
WantedBy=multi-user.target

[Service]
Type=notify
EnvironmentFile=-/etc/default/%N
EnvironmentFile=-/etc/sysconfig/%N
EnvironmentFile=-/etc/systemd/system/k3s.service.env
KillMode=process
Delegate=yes
# Having non-zero Limit*s causes performance problems due to accounting overhead
# in the kernel. We recommend using cgroups to do container-local accounting.
LimitNOFILE=1048576
LimitNPROC=infinity
LimitCORE=infinity
TasksMax=infinity
TimeoutStartSec=0
Restart=always
RestartSec=5s
ExecStartPre=/bin/sh -xc '! /usr/bin/systemctl is-enabled --quiet nm-cloud-setup.service'
ExecStartPre=-/sbin/modprobe br_netfilter
ExecStartPre=-/sbin/modprobe overlay
ExecStart=/usr/local/bin/k3s \
    server --cluster-init --node-ip=<node-ip> \
    --kube-proxy-arg=ipvs-strict-arp=true \
    --disable=servicelb

from k3s.

I'm not aware of any issues where k3s ignores CLI flags.

Are you sure you disabled it on all the servers?

What is the output of kubectl get node -o yaml | grep node-args ?

from k3s.

You were right. I apparently missed one server, and forgot to close this issue. It's a bit tedious and counterintuitive having to set this flag on every server individually for it to have any effect. But that's a different story...

from k3s.

Oh, one thing that I've stumbled across in multiple occasions. The correct way to add the parameter is

--disable=servicelb

is that correct? Because in several places I've seen

--disable servicelb

or

--disable=svclb

and other variants, some with, some without equal sign. Some even with a trailing \ with an empty row below...

from k3s.

It's a bit tedious and counterintuitive having to set this flag on every server individually for it to have any effect.

It's not ineffective - the controller doesn't run on the servers where its disabled. However If you leave it enabled on one, that server will run the controller which takes action on the cluster as a whole. I don't think it's a big ask to have servers configured consistently.

is that correct?

--disable=servicelb and --disable servicelb are treated identically. The golang flag parser treats values the same regardless of whether they're in the same arg separated by an =, or in a separate arg.
--disable=svclb does nothing.

from k3s.

It's not a big ask in and of itself, but it breaks with the single source of truth principle. Just my two cents... Either way, my problem is solved. Thanks nevertheless!

from k3s.