25. HA Kubernetes cluster的高可用不是LB

最近在给k8e引擎引入高可用方案，看了一些资料，也和同事交流，发现这里稍微不注意就会把HA高可用和LB 负载均衡搞一起了。加上这里面都有VIP的概念，就更让人稍不留意就混淆概念了。

以下分解内容假设你对K8S有一定的了解，如果看不懂，那就别看了，这篇对你有点水，出门右转看看AI Chat也挺好的。

K8S集群中 HA 高可用一般指什么

当然集群的高可用，聚焦还是在 etcd 和 api server。etcd集群本身采用了 raft 协议，数据一致性得到了保证，高可用特性自然有了一说。但是从用户的角度来讲，我们直面的是 6443 端口的 api server，如果这个服务不可用，我们就认为它不是高可用。所以我们的高可用方案大多就是解决如果给 api server提供一个 VIP，实现高可用。因为每个 master节点都安装了api server，那么流量是不是就会被 VIP 负载均衡了呢？错误，没有，因为 api server是选主的，流量都跑到一台上跑，所以每次 VIP 都是绑定一台主机的服务，当这台主宕机了，自动切换到下一台主机并宣告 VIP<->Mac, 实现VIP 地址绑定。

还有一个细节，kubectl get node，列出来的节点其实都是开启了 kubelet 进程，可以来调度容器的节点才会被叫做 node，如果你在这个节点上只配置了 api server，那么 kubectl get node是看不到的。 我说这个干啥呢，主要是告诉你，api server 是可以单独部署的，它的作用是让 每个node节点的 kubelet进程来做容器调度的状态同步用的。 没有 api server， kubelet 按照设计也会自己维护当前主