Kubernetes

Kubernetes 集群完整高可用落地方案

·15 分钟阅读·5925 字
K8s实操高阶场景题
📋 目录

Kubernetes 集群完整高可用落地方案

核心概念 K8s 集群高可用落地方案，涵盖 etcd 集群、Master 多副本、LB 负载均衡、工作节点高可用等完整设计。

K8s 高可用分为五大层级：控制平面（集群大脑）、Worker工作节点、业务Pod负载、集群网络、持久存储；同时配套备份、监控、故障容灾体系，逐层消除单点故障。

1. 顶层架构核心原则（生产强制规范）

  1. 奇数冗余，跨故障域部署Master、etcd 必须 3/5台奇数，分散在不同机柜/可用区/AZ，避免单机房断电整体瘫痪；偶数节点容易出现脑裂、无法达成多数派投票。
  2. 分层解耦
    控制平面（管理集群）与工作节点（跑业务）完全分离；etcd 可堆叠Master或独立部署（大规模集群推荐独立etcd）。
  3. 全组件无单点
    kube-apiserver多实例负载均衡；controller-manager/scheduler领导者选举；etcd分布式集群；Worker多节点冗余。
  4. 自愈闭环
    控制器自动调谐、节点驱逐、Pod重建、自动扩缩容，故障无需人工介入。
  5. 数据不丢失
    etcd定时快照备份、持久化存储多副本、有状态应用主从复制。

2. 第一层：控制平面高可用（集群最核心，先保证大脑不宕机）

标准生产架构：3台Master + 负载均衡层（VIP/LB） + etcd集群

2.1. 1 两种etcd部署拓扑（官方标准）

2.1.1. 方案1：堆叠式Stacked（中小集群，30节点以内）

每台Master同时运行etcd实例，3台Master组成3节点etcd集群，机器数量少、成本低；
缺点：Master宕机同时损失1个etcd投票节点，大规模稳定性偏弱。

2.1.2. 方案2：独立外部etcd（50+节点/核心生产必选）

单独3/5台机器只跑etcd，Master仅跑apiserver/controller/scheduler；etcd故障不影响控制平面进程，隔离风险、性能更好。

2.2. 2 四层控制平面组件HA实现

2.2.1. 1）etcd 分布式数据库（集群唯一数据源，重中之重）

etcd基于Raft一致性协议，超过半数节点存活集群可用（3节点允许挂1台，5节点允许挂2台）
高可用配置要点：

  1. 节点数：3/5奇数，跨AZ部署；
  2. 磁盘：高速SSD，禁止机械盘，开启wal预写日志；
  3. 安全：全部TLS证书加密认证；
  4. 定时备份：每小时快照，保留7天备份，故障可回滚整个集群；
  5. 调优：heartbeat-interval=500ms、election-timeout=2500ms，避免网络抖动脑裂；
  6. 禁止单节点etcd（一旦宕机整个集群完全不可用）。

2.2.2. 2）kube-apiserver（无状态API入口）

  • 多实例部署：3台Master各起1个apiserver，完全无状态，可无限扩容；
  • 前端必须加负载均衡层，对外统一单一访问地址（controlPlaneEndpoint）；
  • 两种负载均衡方案：
  1. 自建IDC裸金属：Keepalived(VIP) + HAProxy/Nginx TCP四层转发，健康检查/readyz；
  2. 公有云(AWS/阿里云/腾讯云)：厂商四层NLB，多可用区后端；
  • 健康检查：只转发/readyz返回ok的节点，故障实例自动剔除；
  • 所有kubectl、kubelet、controller、kube-proxy统一通过LB VIP访问apiserver。

2.2.3. 3）kube-controller-manager 控制器管理器

多实例同时运行（3台Master全部启动），依靠领导者选举leader-election抢etcd锁：

  • 同一时间仅1个主实例执行调谐逻辑；
  • 主节点宕机/网络断连，锁自动释放，30s内其余从节点重新选主接管；
  • 配置开启：--leader-elect=true（默认开启）。

2.2.4. 4）kube-scheduler 调度器

机制同controller-manager，多实例部署+领导者选举，单主工作，故障自动切换新调度主。

2.3. 3 控制平面负载均衡两种落地实现

  1. 自建机房传统方案：Keepalived+HAProxy
  • Keepalived：VRRP协议提供统一VIP，实现LB网关漂移，消除负载均衡单点；
  • HAProxy：四层TCP转发6443端口，后端挂载3台apiserver，自带健康检查；
  1. 公有云方案：厂商四层NLB
    无需维护VIP，负载均衡多可用区冗余，后端绑定所有Master 6443端口，天然高可用。

3. 第二层：Worker工作节点高可用（业务运行层）

3.1. 1 节点冗余规划

  1. Worker节点数量≥3，跨机柜/AZ分散；
  2. 按业务拆分节点池：通用业务节点、高内存节点、GPU节点、存储节点，隔离负载；
  3. 禁止单节点承载全部核心业务。

3.2. 2 节点故障自动自愈机制

  1. 节点状态监控
    kubelet每10s向apiserver上报节点心跳；超过node-monitor-grace-period=40s标记节点Unreachable；
  2. Pod驱逐机制（污点Taint）
    节点失联5分钟（pod-eviction-timeout），控制器自动给节点加node.kubernetes.io/unreachable污点；
  3. 调度器将该节点上所有Pod调度至其他健康Worker重建；
  4. 生产优化：核心业务配置Pod反亲和，同一应用副本强制分散不同节点，单机故障不会全量下线。

3.3. 3 节点组件高可用保障

  1. kubelet：每个节点常驻systemd自启，容器运行时(containerd)崩溃自动重启；
  2. kube-proxy：DaemonSet全局部署，每节点一个实例；推荐ipvs/eBPF模式，大规模集群性能优于iptables；
  3. CNI网络插件（Calico/Cilium）：DaemonSet部署，节点网络中断自动重建网络栈；
  4. CSI存储插件：DaemonSet，保障节点挂载PV能力。

3.4. 4 节点资源隔离防雪崩

所有Pod强制配置requests/limits：

  • requests：调度资源基准，保证Pod基础资源；
  • limits：限制CPU/内存上限，防止单个Pod耗尽整机资源导致节点宕机；
    内核关闭swap，避免内存OOM连锁故障。

4. 第三层：业务Pod负载高可用（应用自愈分层方案）

区分无状态、有状态、守护进程、任务四类负载，分别配套高可用策略。

4.1. 1 无状态应用 Deployment（微服务/网关/Nginx）

  1. 副本数replicas≥2，配置Pod反亲和podAntiAffinity打散多节点；
  2. 滚动更新策略maxUnavailable=0，发布零业务中断；
  3. 三色探针：
  • livenessProbe：容器卡死自动重启；
  • readinessProbe：未就绪不接入流量；
  • startupProbe：慢启动应用容错；
  1. HPA自动弹性扩缩容，流量高峰自动加副本；
  2. 配置restartPolicy=Always，容器崩溃立刻重建。

4.2. 2 有状态应用 StatefulSet（MySQL/Redis/Kafka/ES）

  1. 稳定网络标识：固定Pod域名 pod-name.svc.ns.svc.cluster.local；
  2. 独立PVC：每个实例独占存储卷，缩容不删除数据盘；
  3. 有序启停：扩容0→1→2，缩容2→1→0；
  4. 配套中间件自身主从/哨兵集群，底层存储多副本；
  5. 禁止单实例生产运行，至少一主一从。

4.3. 3 全局守护进程 DaemonSet（日志、监控、网络插件）

每节点自动部署一个Pod，节点新增自动创建、节点销毁自动清理，全局全覆盖。

4.4. 4 一次性任务 Job/CronJob

  • Job：并行多副本，失败自动重试；
  • CronJob：定时任务配置并发策略、失败重试、历史保留限制，避免任务堆积。

5. 第四层：集群网络高可用（流量入口与内部通信）

5.1. 1 内部服务发现 Service 四层高可用

  1. Service内置负载均衡，自动匹配后端健康就绪Pod；
  2. 三种代理模式：
  • ipvs：中大规模集群推荐，哈希查找、多调度算法、性能稳定；
  • eBPF(Cilium)：超大规模集群，彻底摆脱iptables/conntrack瓶颈；
  1. Service默认ClusterIP集群内部访问；业务对外暴露两种方案：
  • NodePort：端口暴露，配合节点LB；
  • LoadBalancer：云厂商/MetalLB BGP/L2 VIP，统一流量入口。

5.2. 2 七层网关 Ingress 高可用

  1. Ingress控制器（Nginx Ingress/Cilium）部署为Deployment，多副本+反亲和；
  2. 前端搭配四层NLB/Keepalived VIP，避免Ingress单点；
  3. 开启Ingress健康检查，故障后端Pod自动摘除。

5.3. 3 CNI集群底层网络高可用

  1. Calico/Cilium DaemonSet全局部署，节点网络故障自动修复；
  2. 大规模集群优先Cilium eBPF模式，消除iptables线性规则性能瓶颈；
  3. 网络策略NetworkPolicy隔离异常流量，防止故障扩散。

5.4. 4 自建裸金属VIP方案 MetalLB

  • Layer2 ARP模式：单节点持有VIP，适合小规模；
  • BGP三层模式：多节点同时通告路由，ECMP多活负载均衡，秒级故障切换，高并发生产首选。

6. 第五层：持久化存储高可用（数据不丢失核心）

容器数据生命周期与Pod解绑，依靠PV/PVC+CSI实现存储冗余。

6.1. 1 存储分层方案

  1. 云厂商托管存储（阿里云云盘/AWS EBS）
    多副本分布式底层，自动快照、跨AZ迁移；生产首选；
  2. 自建分布式存储（Ceph/MinIO/OpenEBS）
    三副本数据冗余，单磁盘/单节点损坏数据不丢失；
  3. 本地SSD LocalPV
    高性能数据库使用，配套节点备份策略，节点宕机数据盘迁移。

6.2. 2 存储高可用规范

  1. 全部使用StorageClass动态创建PV，禁止静态绑定宿主机目录bind mount；
  2. 核心数据库开启存储多副本、定时快照备份；
  3. CSI插件支持存储扩容、快照、克隆，故障可快速恢复数据；
  4. 有状态应用StatefulSet自动绑定独立PVC，缩容保留存储不删除。

7. 配套高可用保障体系（备份、监控、容灾、故障演练）

7.1. 1 集群数据备份（etcd+业务存储双备份）

  1. etcd：每小时快照，异地留存备份，集群整体崩溃可完整恢复；
  2. 业务数据库：定时全量备份+binlog增量日志，跨机房存储备份文件；
  3. 配置资源：全部YAML纳入Git仓库（GitOps），集群销毁可一键重建所有业务。

7.2. 2 全链路监控告警（提前发现故障）

必须监控的HA核心指标：

  1. 控制平面：etcd健康节点数、leader切换记录、apiserver延迟；
  2. 节点：节点在线状态、CPU/内存/磁盘使用率、swap占用；
  3. 负载：副本数缺失、Pod重启次数、探针失败、HPA伸缩事件；
  4. 存储：PV挂载失败、磁盘IO打满、快照备份失败；
  5. 网络：Service后端就绪数、Ingress 5xx错误、软中断si；
    告警通道：短信/企业微信/钉钉，核心故障分级告警。

7.3. 3 故障容灾与演练

  1. 单可用区容灾：所有Master/Worker/etcd跨AZ部署，单AZ断电集群不瘫痪；
  2. 异地多活（大型业务）：两套独立K8s集群，流量切分、数据双向同步；
  3. 定期故障演练：手动下线Master、关机Worker、删除Pod，验证自愈流程有效性。

7.4. 4 发布变更高可用规范

  1. 禁止直接删除Pod，统一使用Deployment滚动更新；
  2. 变更前预留回滚方案，kubectl rollout undo一键回退；
  3. 核心业务分灰度分批发布，先少量副本验证再全量更新；
  4. 变更避开业务高峰时段。

8. 极简生产高可用架构汇总（标准3Master架构）

[客户端]
    ↓
[四层LB（NLB/Keepalived+HAProxy VIP）]
    ↓
3台Master节点（跨不同机柜/AZ）
├─ kube-apiserver（多实例负载均衡）
├─ kube-controller-manager（leader选举）
├─ kube-scheduler（leader选举）
└─ etcd 3节点集群（堆叠/独立部署，Raft三副本）
    ↓
多Worker节点池（通用/高内存/GPU，跨AZ，Pod反亲和）
├─ kubelet + containerd
├─ kube-proxy(ipvs/eBPF)
├─ CNI(Cilium/Calico DaemonSet)
└─ CSI存储插件
    ↓
业务负载：Deployment/StatefulSet/DaemonSet + Service/Ingress + 分布式存储PV

9. 面试速记核心总结

  1. 控制平面HA核心：3奇数Master+负载均衡层；etcd三副本Raft协议；apiserver无状态多实例；controller/scheduler领导者选举；
  2. 节点自愈：节点失联5分钟驱逐Pod，调度器重新调度至健康节点，Pod反亲和打散避免单点故障；
  3. 业务分层HA：无状态Deployment多副本滚动更新+HPA；有状态StatefulSet稳定身份+独立PVC；
  4. 网络HA：Service ipvs/eBPF代理；Ingress多副本+四层LB；MetalLB BGP多活VIP；
  5. 存储HA：CSI分布式多副本PV，etcd定时快照+GitOps配置备份；
  6. 整体保障：跨故障域部署、资源limits防雪崩、全链路监控、定期故障演练、灰度发布回滚机制。

关联文档

返回首页订阅更新