automatic upgrade, not tolerating my default and still on deprectaded k3s version

[migs35323]

https://docs.k3s.io/upgrades/automated

I wanted to suggest adding the well known toleration for control plane by default node-role.kubernetes.io/control-plane https://kubernetes.io/docs/reference/labels-annotations-taints/#node-role-kubernetes-io-control-plane-taint and update the examples to provide a more recent kubernetes version..

i can make a PR if this decision was not on purpose, i mean, i guess by default k3s doesn't have this toleration but having it so causes no harm?

[brandond]

As the docs note, that is a kubeadm taint.

Taint that kubeadm applies on control plane nodes to restrict placing Pods and allow only specific pods to schedule on them.

We suggest the following taint for server nodes: https://docs.k3s.io/datastore/ha#2-launch-server-nodes

By default, server nodes will be schedulable and thus your workloads can get launched on them. If you wish to have a dedicated control plane where no user workloads will run, you can use taints. The node-taint parameter will allow you to configure nodes with taints, for example --node-taint CriticalAddonsOnly=true:NoExecute.

[migs35323]

@brandond thank you for the explanation. i see, with the note-taint CriticalAddonsOnly i guess it won't allow by default cluster related components like rancher or longhorn and i need to manually add the toleration in theese components, am i right? why is it recommended over the well known "default" one? i mean, does it make it easier for the packaged manifests?

[brandond]

For the system upgrade controller specifically, you can find the default tolerations here: https://github.com/rancher/system-upgrade-controller/blob/v0.13.2/manifests/system-upgrade-controller.yaml#L65-L79

You can check the SUC deployment and plan in your specific environment to see what you're using.