Kubernetes API server 跟 kube-apiserver 组件的关系是什么？
Kubernetes API server 和 kube-apiserver 组件是同一个东西，是 Kubernetes 控制平面的组件之一。kube-apiserver 是 Kubernetes API server 的二进制可执行文件，负责提供 Kubernetes API 的访问接口，同时也是 Kubernetes 的控制中心。
kube-apiserver 组件通过监听网络端口的方式提供 Kubernetes API 的访问接口，同时也会与 etcd 等组件进行通信，实现对 Kubernetes 资源对象的管理和控制。kube-apiserver 会根据 API 请求的内容，调用相应的控制器来实现对 Kubernetes 资源对象的增删改查等操作，同时也会将这些操作的结果返回给 API 的调用者。
Kubernetes API server 和 kube-apiserver 组件的关系可以类比为操作系统的内核和对应的可执行文件，kube-apiserver 可以看作是 Kubernetes API server 的实际运行进程，而 Kubernetes API server 是 kube-apiserver 的功能实现。因此，在 Kubernetes 中，我们通常使用 kube-apiserver 这个术语来指代 Kubernetes API server 这个组件。
在 k8s 中，kube-scheduler 和 kube-controller-manager 两个组件是有 leader 选举的，这个选举机制是 k8s 对于这两个组件的高可用保障，虽然 k8s 的存储使用了 etcd，但并没有使用 etcd 来实现选主，而是对 endpoint 这个资源做抢占，谁先抢到并将自己的信息写入 endpoint的 annotation 中，谁就获得了主。
k8s中Controller-Manager和Scheduler的选主逻辑：
k8s中的etcd是整个集群所有状态信息的存储，涉及数据的读写和多个etcd之间数据的同步，对数据的一致性要求严格，所以使用较复杂的 raft 算法来选择用于提交数据的主节点。
apiserver 作为集群入口，本身是无状态的web服务器，多个 apiserver 服务之间直接负载请求并不需要做选主
Controller-Manager 和 Scheduler 作为任务类型的组件，比如 controller-manager 内置的 k8s 各种资源对象的控制器实时的 watch apiserver 获取对象最新的变化事件做期望状态和实际状态调整，调度器watch未绑定节点的pod做节点选择，显然多个这些任务同时工作是完全没有必要的，所以 controller-manager 和 scheduler 也是需要选主的，但是选主逻辑和 etcd 不一样的，这里只需要保证从多个 controller-manager 和 scheduler 之间选出一个 leader 进入工作状态即可，而无需考虑它们之间的数据一致和同步。
所有节点上的组件请求各自apiserver，apiserver从etcd中抢占锁资源，抢到锁的节点组件会将自己标记成为锁的持有者。
leader 则可以通过更新RenewTime来确保持续保有该锁，同时其它节点上的组件也会请求各节点上的apiserver，来查询加锁对象的更新时间来判断自己是否成为新的leader。
当leader在配置的时间内未能成功更新锁资源的时间，立即会失去leader身份。
kubernetes 的master节点挂了对整个集群有什么影响？
首先master分以下几个组件：
etcd
apiserver
controller-manager/scheduler
etcd是Kubernetes当中唯一带状态的服务，所有实例将会以RAFT一致性算法组建集群。推荐的部署方案均是采用3个或者5个节点组成etcd集群。
apiserver使用负载均衡器。比如Nginx或者HAproxy+keepalived；也可以直接用公有云供应商提供的负载均衡器。
controller-manager/scheduler将使用租约机制 —— 每个集群中只有一个实例是可用的；这些实例会通过向apiserver中的Endpoint加锁的方式来进行leader election， 当目前拿到leader的实例无法正常工作时，别的实例会拿到锁，变为新的leader。
参考
字节跳动 kube-apiserver 高可用方案 KubeGateway
https://mp.weixin.qq.com/s/hBwffMxMlfJi0Fe9ci0ZOw
基于 etcd 实现分布式锁
http://www.xuyasong.com/?p=1789
K8S 中 scheduler 组件的选主逻辑
http://www.xuyasong.com/?p=2037
Kubernetes 实战-Leader 选举
https://zdyxry.github.io/2019/09/12/Kubernetes-%E5%AE%9E%E6%88%98-Leader-%E9%80%89%E4%B8%BE
Kubernetes高可用部署下组件选主的机制分析
https://www.jianshu.com/p/3c209e33bcc8
关于Kubernetes Master高可用的一些策略
https://www.kubernetes.org.cn/2931.html
Kubernetes 实战-高可用集群部署（无LB）
https://zdyxry.github.io/2019/12/19/Kubernetes-%E5%AE%9E%E6%88%98-%E9%AB%98%E5%8F%AF%E7%94%A8%E9%9B%86%E7%BE%A4%E9%83%A8%E7%BD%B2%E6%97%A0LB/
