mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-05 21:46:22 +01:00
26 lines
1.4 KiB
Plaintext
26 lines
1.4 KiB
Plaintext
// Module included in the following assemblies:
|
|
//
|
|
// * etcd/etcd-performance.adoc
|
|
|
|
:_mod-docs-content-type: CONCEPT
|
|
[id="etcd-timer-tunables_{context}"]
|
|
= {product-title} timer tunables for etcd
|
|
|
|
{product-title} maintains etcd timers that are optimized for each platform. {product-title} has prescribed validated values that are optimized for each platform provider. The default etcd timers with `platform=none` or `platform=metal` are as follows:
|
|
|
|
[source,terminal]
|
|
----
|
|
- name: ETCD_ELECTION_TIMEOUT
|
|
value: "1000"
|
|
...
|
|
- name: ETCD_HEARTBEAT_INTERVAL
|
|
value: "100"
|
|
----
|
|
|
|
From an etcd perspective, the two key values are election timeout and heartbeat interval:
|
|
|
|
Heartbeat interval:: The frequency with which the leader notifies followers that it is still the leader.
|
|
Election timeout:: This timeout is how long a follower node will go without hearing a heartbeat before it attempts to become leader itself.
|
|
|
|
These values do not provide the whole story for the control plane or even etcd. An etcd cluster is sensitive to disk latencies. Because etcd must persist proposals to its log, disk activity from other processes might cause long fsync latencies. The consequence is that etcd might miss heartbeats, causing request timeouts and temporary leader loss. During a leader loss and reelection, the Kubernetes API cannot process any request that causes a service-affecting event and instability of the cluster.
|