K8s高可用集群部署：基于某银行电子商城k8s部署案例实战课

如果你已经能在单节点 kubeadm 集群上跑通 Pod、Service、Ingress，但一被问到「三台 master 挂了只剩一台，etcd 还能不能选主」「apiserver 的 VIP 谁在管」「Calico 和 CoreDNS 起不来到底先查哪一层」，就开始含糊——这门课就是补这块的。

它不讲 K8s 的基本概念，也不带你从零理解什么是 Pod。它选了一个很具体的场景：某银行电子商城的 K8s 高可用集群部署。金融场景对可用性和故障可追溯性的要求，决定了这套部署里没有太多「能跑就行」的妥协，而这恰恰是多数人自学时最容易跳过的地方。

它真正补的是「多控制节点」这一课

平时我们用 kubeadm 起集群，默认就一个控制节点，etcd 单实例，apiserver 前面没什么负载均衡。这种集群能验证功能，但验证不了高可用——因为高可用的核心矛盾全在多节点协作上：多个 apiserver 怎么被统一访问、etcd 三节点怎么做仲裁、节点之间的证书和 kubeconfig 怎么分发、新加的控制节点怎么加入 etcd 集群而不是变成孤岛。

课程的推进顺序基本就是沿着这条线走的：先把第一个控制节点装起来，再扩容成三个控制节点。别看「扩容」两个字轻描淡写，中间涉及 etcd 成员增删、证书签发、负载均衡器指向调整，任何一步顺序错了，集群就可能进入半死不活的状态。这正是很多人卡住、又不好意思问别人的地方。

命令行工具与组件验证，是排查的地基

课程里专门有一段讲安装 K8s 命令行工具。别急着跳过，真正排障时，kubectl、etcdctl、crictl 这几个工具用不用得顺，直接决定你是三分钟定位还是三小时打转。etcdctl 要指定证书和 endpoint 才能连上，crictl 要看的是容器运行时而不是 K8s 抽象层——这些细节，文档里散落各处，实际动手时缺一个参数就报错。

之后有单独环节测试 Calico 和 CoreDNS 是否正常。这两个组件是集群的「血管」和「电话簿」：Calico 不通，Pod 之间互相看不见；CoreDNS 不解析，服务名全变成一串 IP。把它们的验证单独拎出来做，说明课程在意的是「装完之后怎么确认真的可用」，而不是等业务报错了再回头查。

看完你应该能回答的问题

• 三个控制节点的集群里，etcd 的成员列表应该长什么样？怎么判断某个节点是健康成员还是已经脱队？
• apiserver 前面那层负载均衡，为什么不能用普通的四层转发随便糊弄？健康检查该探哪个端口？
• 扩容控制节点时，证书和 kubeconfig 是怎么同步过去的？漏了哪一步会导致新节点加入失败？
• Calico 和 CoreDNS 异常时，你按什么顺序排查——从 Pod 状态、到 CNI 配置、到网络策略，还是反过来？
• 如果业务 Pod 突然大面积不可用，你怎么快速区分是网络插件的问题、DNS 的问题，还是 etcd 本身在抖？

这些问题不是背概念能答的，得真在集群里折腾过一遍。课程以银行电子商城为案例，好处是它会带着这些真实约束走完全流程，而不是停在「演示环境能起来就行」。

适合谁，不适合谁

如果你还没独立用 kubeadm 装过一个可用集群，或者连 kubectl 的基本操作都生疏，这门课会让你有点跟不上——它默认你已经跨过了那道坎，直接进入多节点和高可用的深水区。反过来，如果你正处在「单机能跑、多节点不敢动」的阶段，或者面试里被高可用问题问住过，那它补的正是你缺的那一块。

建议的学法：不要只跟着敲命令。每做完一步，停下来问自己「这一步如果失败，现象是什么、先看哪里」。课程里的故障处理和优化部分，价值不在命令本身，而在那种「出问题了从哪下手」的判断顺序。把顺序记下来，比记住某条命令有用得多。