<p>This is from <a href="https://kubernetes.io/docs/concepts/overview/components/#etcd" rel="nofollow noreferrer">Kubernetes documentation</a>:</p>
<blockquote>
<p><strong>Consistent</strong> and <strong>highly-available</strong> key value store used as Kubernetes'
backing store for all cluster data.</p>
</blockquote>
<p>Does Kubernetes have a separate mechanism internally to make ETCD more available? or does ETCD use, let's say, a modified version of Raft that allows this superpower?</p>

<p>When it comes to going into etcd details, it is best to use the <a href="https://etcd.io/" rel="noreferrer">official etcd documentation</a>:</p>
<blockquote>
<p><strong>etcd</strong> is a strongly consistent, distributed key-value store that provides a reliable way to store data that needs to be accessed by a distributed system or cluster of machines. It gracefully handles leader elections during network partitions and can tolerate machine failure, even in the leader node.</p>
</blockquote>
<p>There is no mention here that this is high-availability. As for the fault tolerance, you will find a very good paragraph on this topic <a href="https://etcd.io/docs/v3.5/faq/#what-is-failure-tolerance" rel="noreferrer">here</a>:</p>
<blockquote>
<p>An etcd cluster operates so long as a member quorum can be established. If quorum is lost through transient network failures (e.g., partitions), etcd automatically and safely resumes once the network recovers and restores quorum; Raft enforces cluster consistency. For power loss, etcd persists the Raft log to disk; etcd replays the log to the point of failure and resumes cluster participation. For permanent hardware failure, the node may be removed from the cluster through  <a href="https://etcd.io/docs/v3.5/op-guide/runtime-configuration/" rel="noreferrer">runtime reconfiguration</a>.</p>
<p>It is recommended to have an odd number of members in a cluster. An odd-size cluster tolerates the same number of failures as an even-size cluster but with fewer nodes.</p>
</blockquote>
<p>You can also find very good article about <a href="https://medium.com/@ahadrana/understanding-etcd3-8784c4f61755" rel="noreferrer">understanding etcd</a>:</p>
<blockquote>
<p>Etcd is a strongly consistent system. It provides <a href="http://jepsen.io/consistency/models/linearizable" rel="noreferrer">Linearizable</a> reads and writes, and <a href="http://jepsen.io/consistency/models/serializable" rel="noreferrer">Serializable</a> isolation for transactions. Expressed more specifically, in terms of the <a href="https://en.wikipedia.org/wiki/PACELC_theorem" rel="noreferrer">PACELC</a> theorem, an extension of the ideas expressed in the CAP theorem, it is a CP/EC system. <strong>It optimizes for consistency over latency in normal situations and consistency over availability in the case of a partition.</strong></p>
</blockquote>
<p>Look also at this picture:<img src="https://i.stack.imgur.com/MjdFG.jpg" alt="enter image description here" /></p>
