比起君子讷于言而敏于行，我更喜欢君子善于言且敏于行。
目录
前言
原以为高可用是一个很简单好做的东西，实际上捋下来思路，还是重新认识到了很多东西。里面涉及到的不只是理论，实操上也会有很多配置和k8s集群证书的问题。慢慢来吧。想填理论内容，清晰明了之后动手操作。所以，这篇也会是不断更新的一篇啦~
一、vip统一入口
VIP 的真正意义：不是负载均衡 而是："入口稳定"
总所周知，一台master是不稳定的。所以大家都会做奇数倍的master。
node节点通过/etc/kubernetes/kubelet.conf 可以修改kubelet连接地址。这个配置文件很重要，它负责：节点注册、Pod状态上报、拉镜像、启动容器，这个配置文件有问题的话，node节点直接 NotReady。
冷知识，不同的node节点实际上可以配置不同的master ip。比如说node1配置访问master1，node2访问master1，node3、4、5访问master3。Kubernetes 本来就是这么设计的。Kubernetes control-plane 本身就是共享状态的。真正的数据在：etcd而不是某个 master。这个为连接 API Server 的入口
但是呢，实际在工作中，如果真的配置了不同node访问不同master，那么一旦有一台master坏掉，就需要批量的调整node配置文件，重启服务，比较麻烦。可是，如果配置不同node访问通一台master，又没办法真正的实现多台master访问，分散压力的效果。所以就出现了vip+HAproxy的方式。vip负责统一入口，方便运维。让所有的node节点统一写成一样的访问ip。这样配合多台master之间的keepalived漂移的作用，即使一台master挂，也不需要批量修改node节点的配置文件，更能做到让用户无感。
VIP 的目的从来不是"让 node 分散访问不同 master"而是：
"给 node 一个稳定入口"这是 Kubernetes HA 最核心的一点。
二、HAproxy分流
真正高级 HA：不是 Keepalived 漂移。而是："请求分发"
HAProxy / SLB / Nginx / F5
VIP -> HAProxy
├── master1
├── master2
└── master3node 连着 VIP。可是请求会：
- 轮询
- 健康检查
- 自动切换
这才是真正意义上的：多 master 分流
真正决定请求去哪台 master 的，是 LB
🎬 Kubernetes 集群故事版
想象 Kubernetes 是一个公司办公室：
- Master 节点 → 公司总部
- 总部做决策、管控全公司，决定谁做什么任务。
- 里面有三个部门：
- kube-apiserver → 前台接待员
- 任何人（Node 或管理员）要办事，都先找前台。
- 前台检查你的证件（证书），确认身份。
- kube-controller-manager → 管理部门
- 确保大家按计划做事情，比如每个部门有足够的人手。
- kube-scheduler → 排班部门
- 决定哪个员工（Node）做哪件事（Pod）。
- kube-apiserver → 前台接待员
- etcd → 总部档案室
- 记录公司所有信息：谁在做什么、库存多少、合同状态等。
- 总部部门只读/写档案室。
- 档案室是安全的（TLS），每个总部都有钥匙，大家保持一致（quorum）。
- Node 节点 → 各部门办公室
- 员工（kubelet）执行任务（启动容器）
- 员工会向总部前台报到（kube-apiserver），获取工作任务
- 员工使用自己的员工卡（kubelet 证书）验证身份
- VIP（虚拟 IP） → 总机电话
- 员工打电话到总部，不用记总部每个办公室号码，只拨总机。
- 如果某个办公室关门，总机会自动把电话转到另一个办公室（Keepalived 漂移）。
- 注意：VIP 只是电话总机，不决定具体哪个办公室接电话，它只保证有人接。
- HAProxy / SLB / Nginx → 总机话务员
- 总机有很多电话打进来，话务员决定哪个办公室接电话。
- 这样不会所有电话都打到同一个办公室（负载均衡）。
- 证书 → 身份证 / 员工卡 / 办公证件
- 前台只允许持证件的人来办事
- 档案室也只允许有钥匙的人进入
- 如果你换了办公室或换了总机，你的证件必须被认可（SAN 包含 IP/VIP）
总结
重点是要分清楚vip入口和api server入口的区别