用 kubeasz 构建生产级 Kubernetes 集群：从可用到高可用，从部署完成到工程闭环

用 kubeasz 构建生产级 Kubernetes 集群：从可用到高可用，从部署完成到工程闭环前言在很多团队里，Kubernetes 部署失败并不是因为“不懂 K8s”，而是因为把“能装起来”误当成了“能用于生产”。真正的生产级集群，关注点从来不只是kubectl get nodes是否全部Ready，而是以下几个更本质的问题：控制面是否具备高可用与故障隔离能力Etcd 是否满足一致性、低延迟与备份恢复要求镜像分发、网络插件、存储、日志、监控是否形成闭环扩容、升级、回滚、换节点是否标准化、可重复、可审计在高并发业务下，API Server、Kubelet、Containerd、CNI 是否经过容量规划与参数调优如果这些问题没有被解决，那么部署再快，也只是把风险更快地推进了生产环境。本文不再停留在“如何执行 kubeasz 命令”这一层，而是站在架构设计和工程落地的角度，系统讲清楚如何基于 kubeasz 构建一套可复制、可扩展、可运维、可升级的生产级 Kubernetes 集群方案。文章会重点覆盖四部分内容：kubeasz 的工作原理与架构边界面向高并发场景的生产级集群设计方法生产级配置、自动化脚本与业务部署示例升级、扩缩容、备份恢复、监控告警等工程实践第一章：为什么 kubeasz 适合生产环境，而不只是“安装更方便”1.1 kubeasz 的本质kubeasz 不是一个重新实现 Kubernetes 的平台，它本质上是：以 Ansible 为执行引擎以 Inventory 和变量文件为声明式输入以标准 Kubernetes 组件为部署对象以集群初始化、扩缩容、升级、清理为核心能力的自动化交付方案也就是说，kubeasz 并没有改变 Kubernetes 的运行机制，它改变的是集群交付和运维的工程化方式。它解决的核心问题不是“让你更容易装 K8s”，而是：把原本分散在 shell、手工操作、Wiki 页面里的步骤固化为自动化资产把节点拓扑、版本、网络、证书、运行时、插件参数统一收敛到配置中把集群初始化、扩容、替换节点、升级、重建变成可重复执行的标准动作1.2 相比 kubeadm，kubeasz 的工程价值在哪里kubeadm更像是 Kubernetes 官方提供的“初始化工具”，而 kubeasz 更像“面向企业场景的交付框架”。对比时，真正应该比较的是工程化能力，而不是命令数量：维度kubeadmkubeasz控制面初始化强强多节点批量交付需要额外编排原生支持Inventory 管理弱强扩容流程标准化需自行封装原生支持离线/内网部署适配中强与 Ansible 运维体系集成弱强交付一致性依赖人为约束依赖配置和剧本对于已经具备 Linux、Ansible、CMDB、CI/CD 基础的团队，kubeasz 的优势非常明显：它能与现有运维体系低摩擦整合，而不是引入一套完全不同的交付范式。1.3 适用场景与边界适合使用 kubeasz 的场景：需要在内网、专有云、IDC、国产化环境部署 Kubernetes节点规模从数台到数百台，且需要标准化扩缩容运维体系中已经广泛使用 SSH、Ansible、离线仓库、配置管理希望控制每个基础组件的版本和参数，而不是完全托管不适合的场景：希望使用完全托管型 Kubernetes 服务完全没有 Linux、网络、容器运行时基础，希望“点几下就完成”需要高度平台化的多租户控制台、计费、审批、租户隔离能力，但没有额外平台层建设计划第二章：生产级 Kubernetes 集群到底在设计什么2.1 生产级的判断标准判断一套 Kubernetes 是否达到了生产级，通常至少看五件事：控制面高可用API Server、Controller Manager、Scheduler 不能因单点故障整体不可用。数据面可扩展节点增加后，网络、调度、镜像、日志、监控、DNS 不应线性退化。状态数据可恢复Etcd 需要具备快照、校验、恢复、演练机制。变更过程可控扩容、换机、升级、证书续期、配置调整必须可审计、可回滚。运行状态可观测必须能从节点、容器、网络、存储、API Server、Etcd 多维度识别瓶颈和故障。2.2 集群架构的基本分层一个真正可运营的 Kubernetes 集群，至少需要从四层来理解：接入层 - SLB / F5 / Keepalived + HAProxy - Ingress / Gateway API / API Gateway 控制层 - kube-apiserver - kube-controller-manager - kube-scheduler - etcd 运行层 - kubelet - containerd - cni plugin - csi plugin 支撑层 - 镜像仓库 - 监控告警 - 日志系统 - 备份恢复 - GitOps / CI/CD很多部署文档只覆盖“控制层 + 运行层”，但在生产上，真正决定稳定性的往往是“接入层 + 支撑层”。2.3 高可用的关键不是 3 Master，而是避免错误的耦合很多文章会说“生产环境至少 3 Master”，这句话没有错，但并不完整。真正要避免的是以下三类错误耦合：控制面与高 IO 中间件混部：Etcd 与 Kafka、ES、MySQL 混部会导致磁盘争抢和尾延迟抖动控制面与大规模业务 Pod 混部：高峰期 kubelet、containerd、CNI 抢占 CPU，会放大控制面抖动单一负载均衡入口：只有一个 LB 或 VIP，等于把“高可用控制面”又变回了单点入口推荐的生产拓扑是：3 台独立控制面节点2 台 LB 节点或云厂商 SLBEtcd 与 Master 同机仅适用于中小规模场景中大型场景建议 Etcd 独立部署业务节点按资源池拆分为通用池、CPU 密集池、IO 密集池、系统组件池第三章：kubeasz 的工作原理与核心架构3.1 kubeasz 的执行模型kubeasz 的执行模型可以概括为：Inventory（节点清单） + Cluster Variables（集群参数） + Roles / Playbooks（标准动作） = 可重复的集群交付过程它的关键价值在于把“环境差异”约束在变量和清单层，而不是散落在人工步骤里。一个典型的 kubeasz 项目结构如下：kubeasz/ ├── ansible.cfg ├── clusters/ │ └── prod/ │ ├── hosts │ ├── config.yml │ └── group_vars/ ├── playbooks/ │ ├── 01.prepare.yml │ ├── 02.etcd.yml │ ├── 03.runtime.yml │ ├── 04.master.yml │ ├── 05.node.yml │ ├── 06.network.yml │ ├── 07.addons.yml │ ├── 21.scale.yml │ └── 31.upgrade.yml └── roles/ ├── prepare/ ├── etcd/ ├── containerd/ ├── kube-master/ ├── kube-node/ ├── cilium/ └── ...3.2 部署顺序为什么必须这样安排生产环境常见部署顺序：OS 基线初始化内核参数、时钟、主机名、依赖包统一Containerd 安装与镜像加速器配置Etcd 集群初始化API Server / Controller Manager / SchedulerKubelet / Kube Proxy / CNICoreDNS、Metrics Server、Ingress、CSI、监控、日志这个顺序不是随意安排的，而是由 Kubernetes 的依赖链决定：没有 Etcd，就没有控制面状态存储没有控制面，Kubelet 无法完成注册和 Pod 编排没有 CNI，Pod 无法获得稳定网络没有 DNS、存储、监控，业务虽然“能跑”，但不可运营3.3 kubeasz 对证书与信任链的处理逻辑生产环境里，TLS 不是“为了更规范”，而是控制面和节点之间可信通信的前提。主要信任关系包括：kube-apiserver 与 etcd 之间的双向认证kubelet 与 apiserver 之间的认证controller-manager、scheduler 访问 apiserver 的客户端证书集群内部 ServiceAccount 的签名密钥可以把它理解为两条主线：组件间的 mTLS 通信链Kubernetes API 的身份认证链如果证书 SAN、CN、主机名、VIP、节点 IP 不一致，最典型的问题就是：kubelet 注册失败apiserver 无法访问 etcd节点状态频繁 Unknown / NotReady聚合 API、Webhook、Admission Controller 调用失败第四章：生产级架构设计方案4.1 推荐拓扑以下是一个适用于中大型业务的通用生产拓扑：+------------------------+ | VIP / SLB / F5 | | 10.10.0.10:6443 | +-----------+------------+ | +-----------------+-----------------+ | | +-------+--------+ +-------+--------+ | LB01 HAProxy | | LB02 HAProxy | | Keepalived | | Keepalived | +-------+--------+ +-------+--------+ | | +-----------------+-----------------+ | +--------------------------+---------------------------+ | | | +----+----+ +----+----+ +----+----+ | Master1 | | Master2 | | Master3 | | APIServer| | APIServer| | APIServer| | CM/SCH | | CM/SCH | | CM/SCH | +----+----+ +----+----+ +----+----+ | | | +------------+-------------+-------------+-------------+ | | +----+----+ +----+----+ | Etcd01 | | Etcd02 |