Closed nshores closed 1 year ago
You seem to be confusing/conflating multiple things. The core Kubernetes components have leader election timeouts that relate to how often leases are renewed for leader-elected controllers. Etcd also has leader-election and heartbeat timeouts that have to do with the raft consensus algorithm itself.
The kubernetes options can be configured via --kube-controller-manager-arg
, --kube-scheduler-arg
and so on. The etcd options can be configured via --etcd-arg
.
Note that we don't document in this project the possible values for those flags; you should refer to the upstream Kubernetes and etcd docs for valid CLI flags.
This is a blip in a lower-quality SSD resulting in the below errors. This type of minor disk latency should be tolerated.
Nov 27 11:44:05 k3s-master-5 k3s[252355]: Trace[784261243]: [9.8224918s] [9.8224918s] END
I think that your monitoring data is obscuring the true severity of your IO stall. It shows a 456ms average latency over that period, but the max was clearly much longer, as the log shows that some operations took over 10 seconds to complete - which is definitely longer than Kubernetes is willing to wait for a lease renewal operation to complete.
Is your feature request related to a problem? Please describe.
Often times K3s is running on systems that are at times, resource constrained. There appears to be a process running in the K3S binary that watches for LeaderElection failures in both
etcd
andk3s-cloud-controller-manager
. After a short period (<500ms) of a leader election failure of either loop, the main k3s process exits with error code 1.Based on the documentation, the values/parameters for
kube-controller-manager
can be modified via inserting them into the config, but not etcd parameters. I believe we need to be able to tweak these values (To allow for slow disk hiccups), and more clearly document them. Both of these subsystems have very tight defaults, and should be able to tolerate more latency - especially in small deployments.This appears to be a known issue based on comments like this
Background:
https://kubernetes.io/docs/concepts/architecture/leases/#leader-election https://etcd.io/docs/v3.4/tuning/#time-parameters
The default for etcd is as follows:
The default for
kube-controller-manager
is as follows (I am not sure these are the right values):Describe the solution you'd like
The ability to tweak etcd default values and clear documentation on tuning
kube-controller-manager
values for slow disks. Ideally, I would like K3s to simply ignore these events and have a high ceiling for tolerance of leader election failures (>60s)Additional context
This is a blip in a lower-quality SSD resulting in the below errors. This type of minor disk latency should be tolerated.
Logs during the event:
Related issues: https://github.com/k3s-io/k3s/issues/2615 https://github.com/k3s-io/k3s/issues/5587 https://github.com/k3s-io/k3s/issues/5587#issuecomment-1134375622