获课：xingkeit.top/16886/
K8s 高可用集群部署：基于某银行电子商城 K8s 部署案例实战
银行电子商城不是普通电商——日活峰值百万级、大促 QPS 破万、下单与支付链路直接挂钩核心账务，任何一秒控制平面不可用都可能演变成监管事件。某国有大行电子商城容器化迁移项目中，团队放弃单 Master 实验架构，采用 3 可用区（AZ）+ 3 Master + 独立/堆叠 etcd + 5 Worker 起步、可扩至数十节点 的金融级拓扑，用 kubeadm + HAProxy + Keepalived 把"控制面不中断、数据面秒级调度、大促可弹性"三项指标全部钉死。
一、为什么银行商城必须上 K8s HA
传统 VM 部署下，商城各子系统独占物理机，利用率不足 40%，扩容以天计，单台宿主机故障业务中断按小时算。上 K8s 高可用后：
控制平面 3 节点对等，apiserver 无状态横向扩展，controller-manager/scheduler 走 leader election，任一 Master 宕机业务无感；
etcd 奇数节点 Raft 多数派存活，强一致不丢状态；
数据面 Worker 跨 AZ 打散，Pod 用反亲和调度，单机房断电剩余 AZ 接管；
大促前 30 分钟 HPA + Cluster Autoscaler 把订单服务从 10 副本弹到 80 副本，峰值过后回收。
二、生产级拓扑与节点规划
以该商城同城双活+异地灾备雏形为例，最小生产集为单地域 3AZ：
角色 | 数量 | 配置 | 说明 |
|---|
Master（控制面） | 3 | 8C16G / 100G SSD | 跨 3 个 AZ 各放 1 台，跑 apiserver+controller-manager+scheduler，etcd 堆叠或独立 |
etcd（独立可选） | 3 | 4C8G / 200G NVMe | 50 节点以上强建议拆出 Master，本案例初期堆叠、二期独立 |
LB 节点 | 2 | 2C4G | 跑 HAProxy+Keepalived，VIP 漂移；也可把 HA 组件放 Master 上省机器 |
Worker | 5 起步（可扩 20+） | 16C64G / 1.6T SSD | 分 AZ 打标签，商城订单/库存/支付各自亲和到不同 AZ |
VIP | 1 | 192.168.1.100:6443 | Keepalived VRRP 管理，kubectl/CI/Kubelet 统一填这个地址 |
CNI 选 Calico（NetworkPolicy 细粒度隔离满足等保），容器运行时 containerd，K8s 版本锁定 1.28/1.29 小版本，禁止跨 minor 升。
三、接入层：HAProxy + Keepalived 托住 6443
apiserver 是 HTTPS/mTLS 流量，七层解析没必要，HAProxy 走 mode tcp 四层转发：
frontend k8s-api
bind *:6443
mode tcp
default_backend k8s-api-backend
backend k8s-api-backend
mode tcp
balance roundrobin
option tcp-check
server master-01 192.168.1.11:6443 check fall 3 rise 2
server master-02 192.168.1.12:6443 check fall 3 rise 2
server master-03 192.168.1.13:6443 check fall 3 rise 2
Keepalived 用 VRRP 管 VIP，健康检查不是 ping 网关，而是 killall -0 haproxy 或 curl https://localhost:6443/healthz，HAProxy 死了 VIP 漂走，避免"VIP 在但 apiserver 全断"的假活。
关键点：kubeadm init 的 --control-plane-endpoint 必须填 VIP:6443，否则证书 SAN 不含 VIP，kubelet 和 join 节点 TLS 握手直接失败。
四、控制面初始化与多 Master 加入
首节点播种（堆叠 etcd 模式）：
kubeadm init \
--control-plane-endpoint "192.168.1.100:6443" \
--upload-certs \
--pod-network-cidr=10.244.0.0/16 \
--service-cidr=10.96.0.0/12
--upload-certs 把控制面证书加密存进 kubeadm-certs Secret，后续 Master 用一条 kubeadm join ... --control-plane --certificate-key ... 免拷证书加入。Worker 用普通 join 命令填 VIP 入群。
三个 Master 起来后验证：
kubectl get endpoints kube-controller-manager -n kube-system 看 leader 选举正常；
etcdctl endpoint status 看 3 成员健康、leader 存在；
故意 systemctl stop kube-apiserver 干掉主节点，kubectl 经 VIP 仍可读资源，证明接入层生效。
五、银行场景下的三个不能省动作
1. etcd 必须备份
每天 etcdctl snapshot save 落盘，异地拷贝到对象存储，大促前额外全量备一次。商城商品目录、ConfigMap、ServiceAccount 令牌全在 etcd，没备份不敢动集群升级。
2. Pod 反亲和 + AZ 拓扑标签
订单服务 Deployment 里写 topologyKey: topology.kubernetes.io/zone + podAntiAffinity，强制副本跨 AZ 分散；再配合 PDB（PodDisruptionBudget）限制自愿驱逐比例，节点维护时至少 2/3 副本在线。
3. 商城敏感业务隔离
支付、账务类 Namespace 开 PSA（Pod Security Admission）restricted 级别，禁 hostNetwork/特权容器；Calico GlobalNetworkPolicy 只允许网关命名空间访问订单服务 8080，其余拒绝。
六、从"能跑"到"金融级"的收尾
集群 Ready 只是开始。该商城项目上线前还补齐了：CoreDNS 多副本反亲和、kube-proxy IPVS 模式、Prometheus+Grafana 盯 apiserver 请求延迟与 etcd fsync 耗时、cert-manager 管 Ingress 证书、Velero 做命名空间级备份、GitOps（Argo CD）接管 800+ YAML 的发布。
最终交付：控制面 SLA 99.99%，大促 QPS 8 万时 Pod 调度 P99 < 120ms，单次 Master 节点断电演练业务零中断——这正是银行电子商城愿意把核心链路交给 K8s 的理由。
如果你手头是裸机/VMware 环境、想照着搭一套最小可用 HA 练习集群，我可以给你一份精确到每条系统调优命令的 8 节点执行清单（含 sysctl、modules-load、containerd 配置、kubeadm ConfigMap 化 init 模板），直接复制就能跑。
本站不存储任何实质资源，该帖为网盘用户发布的网盘链接介绍帖,本文内所有链接指向的云盘网盘资源，其版权归版权方所有！其实际管理权为帖子发布者所有，本站无法操作相关资源。如您认为本站任何介绍帖侵犯了您的合法版权，请发送邮件
[email protected] 进行投诉，我们将在确认本文链接指向的资源存在侵权后，立即删除相关介绍帖子！
暂无评论