API server（API服务器）的选举机制是指在这些系统中，如何选择一个或多个API服务器来处理客户端请求的过程。这种选举机制通常用于确保高可用性、负载均衡和故障转移。
以下是API server选举机制的一些关键点：
在一些分布式系统中，如Kubernetes，可能会使用领导选举机制来确定哪个API服务器作为主服务器来处理请求。这通常涉及到一个选举算法，例如Raft或Paxos，用于在多个API服务器之间决定一个领导者。
API服务器通常会定期进行健康检查，以确定它们是否能够正常处理请求。如果一个API服务器变得不可用，系统应该能够检测到这一点，并触发一个自我修复过程，可能是通过重新选举一个领导者或启动一个备用服务器。
在多个API服务器的情况下，负载均衡器会根据某些策略（如轮询、最少连接、IP哈希等）来分配客户端请求到不同的服务器。这种机制确保了资源的有效利用和请求的高效处理。
如果当前的API服务器出现故障，系统应该能够自动将领导权转移到另一个健康的服务器上。这通常涉及到一个预先定义好的故障转移流程。
特别是在分布式数据库和存储系统中，API服务器的选举机制还需要确保数据的一致性和复制。这可能涉及到跨多个服务器的数据同步和一致性协议，如Multi-Master Replication。
在微服务架构中，API服务器的选举可能与服务发现机制相结合。服务发现是指系统能够找到并连接到其他服务的能力。API服务器在选举过程中需要能够被其他服务发现，以便进行通信和请求处理。
在实现API服务器的选举机制时，开发者需要考虑系统的具体需求和上下文，选择合适的选举算法和策略，以确保系统的稳定性、可靠性和性能。
在Kubernetes中，三个Master节点的配置通常是为了实现高可用性（HA）。在这种配置中，并没有明确的主备之分，而是通过一种称为Pod亲和性的机制来确保关键组件的冗余和故障转移能力。
在默认情况下，Kubernetes的控制平面组件（如apiserver、controller-manager和scheduler）会在所有Master节点上以Pod的形式运行。这些Pod会被配置为不偏好运行在特定的节点上，但是会确保至少有一个副本在每个Master节点上运行，从而实现控制平面的冗余。
如果一个Master节点发生故障，Kubernetes的controller-manager会自动将控制平面组件的Pod重新调度到其他健康的Master节点上，以确保集群的控制平面始终可用。这种机制使得三个Master节点的配置不仅仅是为了冗余，而是为了在任何节点发生故障时都能够保持集群的正常运行。
为什么要设置成3节点：
选举机制：在三个节点的配置中，如果一个Master节点发生故障，剩余的两个节点可以通过选举机制选出一个主节点。这种奇数个节点的配置避免了 Split Brain 现象，即多个节点同时尝试成为主节点的情况。
故障转移：在3节点配置中，即使一个Master节点发生故障，另外两个节点仍然可以继续提供服务，同时可以启动一个新的Master节点进行故障转移。
负载均衡：3个节点可以提供更好的负载均衡，尤其是在进行集群管理任务时，如更新和维护。
符合Kubernetes设计原则：Kubernetes的设计原则之一是确保集群的关键组件（如Master节点）具有高可用性。3节点配置是实现这一目标的一种简单有效方式。
易于理解和维护：对于大多数用户来说，3节点配置相对于更多节点的配置更为简单，更容易理解和维护。
需要注意的是，虽然三个Master节点的配置可以提供高可用性，但是在某些情况下，可能还需要额外的机制来处理例如证书过期、组件更新等问题。此外，对于那些对可用性有更高要求的集群，可能会选择使用更复杂的配置，例如使用 etcd 集群作为集群状态存储，以及使用多个控制平面组件的副本来进一步增加冗余。