<p>To build a highly available <code>k8s</code> cluster, you need to build an <code>etcd</code> cluster, which I see in the official <code>k8s</code> documentation.</p>
<p><a href="https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/ha-topology" rel="nofollow noreferrer">Each control plane node creates a local etcd member and this etcd member communicates only with the kube-apiserver of this node. The same applies to the local kube-controller-manager and kube-scheduler instances.</a></p>
<p>That is, <code>kube-apiservice</code> only communicates with <code>etcd</code> of its own node, can we understand that reads and writes happen on <code>etcd</code> of the same node,</p>
<p>But when I was studying <code>etcd</code>, I was told that the clients in the <code>etcd</code> cluster read data through <code>Follower</code> and write data through <code>Leader</code>.</p>
<pre class="lang-bash prettyprint-override"><code>┌──[root@vms100.liruilongs.github.io]-[~/ansible/kubescape]
└─$ETCDCTL_API=3 etcdctl  --endpoints https://127.0.0.1:2379  --cert=&quot;/etc/kubernetes/pki/etcd/server.crt&quot;  --key=&quot;/etc/kubernetes/pki/etcd/server.key&quot;  --cacert=&quot;/etc/kubernetes/pki/etcd/ca.crt&quot; endpoint status --cluster  -w table
+-----------------------------+------------------+---------+---------+-----------+-----------+------------+
|          ENDPOINT           |        ID        | VERSION | DB SIZE | IS LEADER | RAFT TERM | RAFT INDEX |
+-----------------------------+------------------+---------+---------+-----------+-----------+------------+
| https://192.168.26.100:2379 |  ee392e5273e89e2 |   3.5.4 |   37 MB |     false |       100 |    3152364 |
| https://192.168.26.102:2379 | 11486647d7f3a17b |   3.5.4 |   36 MB |     false |       100 |    3152364 |
| https://192.168.26.101:2379 | e00e3877df8f76f4 |   3.5.4 |   36 MB |      true |       100 |    3152364 |
+-----------------------------+------------------+---------+---------+-----------+-----------+------------+
┌──[root@vms100.liruilongs.github.io]-[~/ansible/kubescape]
└─$
</code></pre>
<p>In fact, there is only one <code>Leader</code> in the cluster. Does this read/write separation of <code>etcd</code> clusters apply to <code>k8s</code>?</p>
<p>I understand that this is contradictory to what is said above. I would like to know how <code>etcd</code> reads and writes in a <code>k8s</code> cluster.</p>
<hr />
<p>I know very little about <code>etcd</code>, thanks for clearing up my confusion!</p>

山河以无恙
<blockquote>
<p>In fact, there is only one Leader in the cluster. Does this read/write separation of etcd clusters apply to Kubernetes?</p>
</blockquote>
<p>Yes. In an etc cluster, there is only one leader that does the writes. But etcd internally forwards all requests that needs <em>consensus</em> (e.g. writes) to the <em>leader</em>, so the client application (Kubernetes in our case) does not need to know what etcd node is the leader.</p>
<p>From <a href="https://etcd.io/docs/v3.5/faq/" rel="nofollow noreferrer">etcd FAQ</a>:</p>
<blockquote>
<p><strong>Do clients have to send requests to the etcd leader?</strong></p>
</blockquote>
<blockquote>
<p>Raft is leader-based; the leader handles all client requests which need cluster consensus. However, the client does not need to know which node is the leader. Any request that requires consensus sent to a follower is automatically forwarded to the leader. Requests that do not require consensus (e.g., serialized reads) can be processed by any cluster member.</p>
</blockquote>
