生产级K8S集群自动化：从搭建到运维的系统化实践

1. 为什么非要把K8S搭建“系统化”，不手动搭行不行

1.1 生产环境多集群手动维护的痛点

先说个场景。一次新业务上线，需要临时扩容一套K8S集群。我打开shell，按照老流程开始敲命令：初始化系统参数、装容器运行时、kubeadm init、配置网络插件，一路敲下去，大概花了两个小时。集群起来了，看起来一切正常。但到了第三天，某个节点出现报错，排查半天发现是初始化时系统参数漏配了一项，导致流量转发异常。

这不是偶发现象。手动搭建K8S的真正问题不在于步骤本身有多难，而在于每一步都依赖人对环境的即时判断。生产环境不是一张白纸：底层的操作系统版本可能不完全一致，内核参数有些节点被改过，网卡命名规则不同，甚至某些机器的时区都没对齐。同一个脚本在这台机器上跑得顺畅，换一台机器就会冒出各种小问题。人不可能把所有差异都记在脑子里，一旦集群数量超过三套，维护成本就开始失控。

我在接手这套生产环境的时候，手上同时在维护的K8S集群共有四套：两套业务集群、一套中间件集群、一套CI/CD集群。它们的版本不完全相同，插件配置也有些差别。每次做什么改动，我都要先回忆这套集群的历史状态，再决定命令要怎么写。这种工作方式风险极高，因为人的记忆是会出错的。于是在某次事故之后，我决定把搭建和管理这套集群的流程全部沉淀成代码和配置，形成一套自动化的控制系统，也就是后来被我们内部称为K8S Control System的东西。

1.2 为什么我选择自研控制系统而不是现成工具

当时我也调研过一些开源的集群管理平台，比如某UI管理工具、某些可视化面板。它们确实能降低操作门槛，但用下来有几个痛点始终绕不开。

第一，这类工具一般面向“单集群管理”场景，多集群切换要么支持很弱，要么需要额外部署一套中心化组件。而我这里需要的恰恰是多集群的统一编排能力。第二，大多数工具只覆盖了K8S自身的生命周期管理，对于底层节点初始化、系统参数配置、容器运行时安装这些“地基”工作基本不管。但这些环节恰恰是生产环境故障率最高的地方。第三，也是最关键的，工具本身引入的复杂度会掩盖问题。一旦集群出故障，你得先搞清楚是K8S的问题还是管理工具的问题，排障链路变长。

我想要的是一套能覆盖“从裸机到集群就绪再到日常运维”全过程的方案，而且必须满足三个原则：

• 可重复：同一套配置在任何一批新机器上跑出来的结果一致。
• 可审计：任何一次变更都留痕，知道谁改过、改了哪台机器、改了什么东西。
• 可回滚：操作出问题的时候，能快速回到上一个稳定状态。

当时我决定自己写，核心是沉淀一套脚本集和配置模板，用代码管理集群状态。后来这套东西慢慢从一个临时脚本演变成了一个结构化的控制系统，名字就叫K8S Control System。它不依赖任何外部平台，核心只有一个控制节点加一批约定好的配置文件，纯命令行即可驱动。这个思路在后面成了我们运维工作的主心骨。

2. K8S Control System的整体架构：三个平面各管什么

2.1 管理平面：集群清单是唯一事实来源

整套系统第一个要解决的问题是：怎么描述一个集群的“期望状态”。我采用的方式是用一组声明式的配置文件来定义集群，放在一个独立的Git仓库里。每个集群一个目录，里面放着该集群专属的配置：节点列表、角色划分、版本号、网络插件参数、标签和污点、系统参数覆盖项等。

这些配置是整个控制系统的唯一事实来源。任何时候你想知道某个集群应该是什么样，不需要去连服务器执行命令，打开对应的配置文件就能看懂全局。这种做法跟我以前维护服务器的方式完全不同。以前是服务器上有什么就是什么，状态靠人去记；现在是清单里怎么写，服务器最终就必须变成什么样。不一致的部分，就是控制系统需要去修复的部分。

# 某集群的节点清单示例（简化） cluster_name: production-biz k8s_version: "1.28.7" cni: calico control_plane_endpoint: "10.10.0.100:6443" nodes: - hostname: k8s-master-01 role: control-plane ip: 10.10.0.11 etcd: true - hostname: k8s-master-02 role: control-plane ip: 10.10.0.12 etcd: true - hostname: k8s-master-03 role: control-plane ip: 10.10.0.13 etcd: true - hostname: k8s-node-01 role: worker ip: 10.10.1.11 labels: "node-type": "app" taints: []

这里有个很容易踩的坑：配置文件的语法一定要简单，不要在上面做二次编程。我曾经尝试过用模板引擎把节点列表和配置生成逻辑全部抽象出来，结果调试配置本身的时间比手动搭建还长。后来我学乖了，配置就是YAML，逻辑就是Shell脚本，两者分开。控制脚本负责“怎么执行”，配置文件负责“目标是什么”，互不干扰。

2.2 执行平面：可重入脚本与控制节点

执行平面是实际干活的模块。我没有选择把整套系统做成一个常驻服务，而是用一组可重复执行的脚本组成。控制节点只需要一台普通的Linux机器，具备到所有目标节点的SSH访问权限即可。每次操作由人工触发，脚本读配置、连机器、执行命令、收集结果。

为什么不用常驻Agent的模式？因为多一个常驻组件，生产环境就多一个故障点。控制节点本身如果挂了，不应该影响任何现有集群的运行——它只负责变更，不负责承载流量。这种“变更时才在线”的模式，让控制系统的自身故障对我的业务集群零影响。脚本的可重入性是这套系统能落地的关键。所谓可重入，简单说就是同一份脚本跑多少遍，结果都是一样的，不会因为上次执行一半就导致下次执行出错。

举个例子，初始化节点的脚本里有一段配置内核参数的逻辑。它不会简单地把参数追加到sysctl.conf，而是先检查目标参数是否已经存在，存在就替换，不存在才追加。之后再执行sysctl -p重新加载。这样哪怕上一次脚本在写入一半时崩溃，第二次执行也能基于当前状态继续，而不是报错或覆盖。

另外一个经验是：每个脚本都应该有“幂等验证点”。也就是执行完关键步骤之后，立刻检查这一步的结果是否符合预期。比如配置完容器运行时后，马上执行一条命令验证是否能正常调用；kubeadm init结束后，立刻检查进程和端口。这种机制保证脚本不会在错误状态上继续往下走。

2.3 状态平面：收集事实与对账

有了期望状态和执行能力，还需要一个东西把它们连接起来：当前状态。状态平面的工作就是收集每台目标节点的真实情况，然后和期望状态做对比，这个动作我们内部叫“对账”。

对账机制做得很朴素：在控制节点上运行一组只读的采集脚本，把每台机器的系统参数、软件版本、运行状态汇总到一个JSON文件里，再和集群清单做比对。比对结果分三种：已对齐、待变更、异常。自动化流程只负责处理“待变更”的部分，“异常”的则进入告警通道人工介入。

这套机制的价值在运维场景下会越来越明显。比如新买了一批机器要扩容，我先执行对账脚本，它会告诉我这批机器的内核参数缺什么、容器运行时没装、时间同步未配置。然后我不需要去关心这些细节，直接执行集群扩容流程，脚本会按顺序补齐所有前置条件，最后把节点加入集群。

等对账机制跑了一段时间之后，我又给它加了一个功能：把所有关键操作写入操作日志。每一次脚本执行、每一个目标节点的变更记录，都追加在一个结构化的日志文件里。出了问题只需要查日志，就能定位到操作时间和具体变更内容。这个东西在排障时给了我极大的帮助，后面排障部分会详细说。

3. 自动搭建一条生产集群的完整流程

3.1 第一步：基础设施准备与节点初始化

自动搭建流程的第一步，是从一批裸机开始准备基础设施。这个阶段的目标是让每台机器达到运行K8S的最低标准。

首先是操作系统层面的初始化。这里有一套固定的参数必须提前配好，否则后面网络插件和kubelet会出各种诡异的问题。关键的几项包括：

• 关闭swap：K8S要求kubelet所在节点必须关闭swap，不然kubelet无法启动或会报错。
• 加载内核模块：主要是overlay和br_netfilter，这两个模块分别负责容器镜像层存储和网络流量转发。
• 配置内核参数：包括net.bridge.bridge-nf-call-iptables、net.ipv4.ip_forward等。其中ip_forward如果不开启，Pod之间的跨节点通信会直接失败。
• 时间同步配置：集群内所有节点时间偏差超过一定阈值，会导致证书校验失败。我们统一装好chrony，并指向内部NTP服务器。
• hosts文件追加：如果内网有DNS，这步可以跳过；但我们这套环境的DNS在一些机器上配置得不全，所以我选择把集群内所有节点的IP和主机名写入hosts，避免各种组件之间解析不到对方。

然后是容器运行时的安装。目前生产环境主流还是containerd，我这边用的也是它。安装完成后，有一个配置必须改，就是SystemdCgroup参数要设成true。否则kubelet和容器运行时对待cgroup的管理方式不一致，会出现资源统计错乱问题。这一步如果没配好，后面Pod运行就会出现间歇性内存统计异常，非常难排查。

# 节点初始化脚本片段（简化） swapoff -a sed -i '/swap/s/^/#/' /etc/fstab cat > /etc/modules-load.d/k8s.conf <<EOF overlay br_netfilter EOF modprobe overlay modprobe br_netfilter cat > /etc/sysctl.d/k8s.conf <<EOF net.bridge.bridge-nf-call-iptables = 1 net.bridge.bridge-nf-call-ip6tables = 1 net.ipv4.ip_forward = 1 EOF sysctl --system

3.2 第二步：控制面高可用初始化

基础设施准备好之后，就开始初始化控制面。生产集群的控制面必须高可用，不能只在一个节点上跑API Server。我这里用的是三台控制平面节点加一个VIP的方案：外部流量统一访问VIP，VIP背后是三个API Server实例，etcd数据也由这三个节点共同承载。

控制面初始化我选择了kubeadm这个工具。它最大的好处是把K8S控制面组件的安装过程标准化了，证书生成、组件静态Pod配置、引导token这些细节都帮你搞定。但这不代表什么都交给它就行，初始化之前必须明确指定控制平面端点。

# 控制面初始化命令 kubeadm init \ --control-plane-endpoint=10.10.0.100:6443 \ --kubernetes-version=v1.28.7 \ --pod-network-cidr=172.16.0.0/16 \ --service-cidr=10.96.0.0/12 \ --apiserver-advertise-address=10.10.0.11 \ --cri-socket=unix:///run/containerd/containerd.sock \ --upload-certs

这里有几个参数我要重点解释一下。--control-plane-endpoint是整个高可用架构的核心。kubeadm会把API Server的证书SAN、每个组件要访问的地址全部都指向这个端点。如果后面要更换VIP或者域名，不仅仅要改负载均衡配置，所有证书都要重新换一遍。--upload-certs参数也很关键，它的作用是把控制面证书上传到集群中加密保存，这样另外两台控制面节点加入时能自动拿证书，不需要手工拷贝。生产环境第一次初始化时，如果漏了这个参数，后面加入控制面节点会非常痛苦，要手动同步一堆敏感文件。

初始化完成后，第二、第三台控制面节点执行同样的加入命令，只是IP地址换成对应的节点地址。这个顺序不能乱：一定是第一台init成功之后，后面两台才能join。等三台控制面节点就绪后，才进入下一个阶段。

3.3 第三步：负载均衡与证书的分发逻辑

VIP的实现方式，不同环境有不同选择。有条件的会在交换机层面配VIP，没有条件的就在集群里跑keepalived。我这里用的是keepalived，每台控制面节点上装一个，通过VRRP协议选举出当前持有VIP的节点。如果持有VIP的节点挂了，另外两台节点会自动接替，API Server的访问不会中断。

这里有一个细节我吃亏过，必须提醒一下。光有VIP还不够，API Server和kubelet的流量默认走6443端口，keepalived不会自动转发流量。好在kubeadm生成的控制面组件本身就是监听在所有网卡上的，VIP只要落在某一台机器上，这台机器的API Server就能直接响应。所以keepalived的配置文件里只需要定义虚拟IP，不需要额外的端口转发规则。

证书分发逻辑方面，kubeadm采用了一套比较完整的证书体系。API Server对外通信使用apiserver.crt；各组件之间通信使用各自的证书；etcd有自己独立的CA。我个人不再对kubeadm生成的证书体系做额外改动，只需确保一件事：集群内部组件访问API Server一律走内网域名或VIP，不要直连某一台节点的IP。这样即使节点故障，访问也不会中断。

# keepalived配置简要（虚拟IP部分） vrrp_instance VI_k8s { state BACKUP interface ens192 virtual_router_id 51 priority 100 advert_int 1 authentication { auth_type PASS auth_pass 123456 } virtual_ipaddress { 10.10.0.100 } }

这里提一个很多新手会踩的坑：keepalived的state和priority配置不一致时，脑裂问题很难查。我建议所有节点都用BACKUP状态，靠priority大小来选举主节点，而不是把一台配成MASTER。这样即使主节点重启完再回来，也不会因为状态抢占把流量带乱。

3.4 第四步：节点加入与工作负载就绪

控制面就绪后，接下来就是把worker节点加入集群。这一步在控制系统的编排下非常简单：脚本自动从集群生成加入token，然后对每台worker节点执行kubeadm join。加入成功后，脚本会等待Node状态变为Ready，再根据集群清单给节点打上标签和污点。

# 生成加入token kubeadm token create --print-join-command # worker节点加入（示例） kubeadm join 10.10.0.100:6443 \ --token xxxxx.yyyyy \ --discovery-token-ca-cert-hash sha256:xxxxxxxxxx

这里token有一个天然的问题：默认有效期是24小时。自动化流程如果隔了很久才加入新节点，token早就过期了。所以我在控制系统里做了一个优化：每次执行节点扩容前，先检查token是否存在且有效，如果无效就立即重新生成。这个逻辑写进脚本之后，再也没在扩容时卡过token过期的问题。

节点加入完成之后，还要安装网络插件。我选择的是Calico，它的最大优势是支持BGP模式直接路由，性能损耗低。安装过程同样走声明式：把Calico的YAML模板保存到配置仓库里，按集群实际Pod网段渲染之后apply。这一步在一个多集群场景里特别容易犯错——如果记错Pod网段，Calico初始化会失败，整个集群的Pod网络都起不来。控制系统把网段参数和集群配置绑定在一起，渲染时自动替换，基本堵死了这个坑。

最后一步是验证工作负载就绪。控制系统会创建一个临时测试Pod，检查它能否正常调度和访问网络，确认没问题后把它删掉。到这里，一条生产集群的自动搭建流程就算走完了。

4. 管理不止是“搭得起来”，日常运维也要自动化

4.1 健康巡检：把零散的检查变成固定指标

集群搭建完成只是开始，真正的考验在日常运维。K8S集群最大的特点就是内部组件多、关联复杂。API Server、etcd、kubelet、网络插件、DNS，任何一个环节出问题，表现出来都是业务Pod异常。而人不可能时刻盯着Dashboard看，所以我把巡检做成了定时任务，定期在控制节点上执行。

巡检脚本的输出是一个固定的指标集合。我最关心的指标包括这些：

• 节点状态：Ready节点数、NotReady节点数、各节点负载情况。
• Pod状态：异常Pod数、CrashLoopBackOff数量、Pending数量。
• 证书有效期：所有关键证书剩余天数，低于30天的直接告警。
• etcd健康状态：通过etcdctl检查集群健康，以及磁盘碎片率和DB大小。
• 镜像仓库连通性：确保节点能正常拉取镜像，这在离线环境或镜像仓库故障时尤其重要。

# etcd健康检查示例 ETCDCTL_API=3 etcdctl health \ --cacert=/etc/kubernetes/pki/etcd/ca.crt \ --cert=/etc/kubernetes/pki/etcd/server.crt \ --key=/etc/kubernetes/pki/etcd/server.key \ --endpoints=10.10.0.11:2379,10.10.0.12:2379,10.10.0.13:2379

巡检结果我不建议只做“正常/异常”的二元判断。更合理的做法是输出数值，然后让告警规则去判断阈值。比如节点内存使用率，我关心的不是它是否超过90%，而是趋势是不是在持续上升。把这个数值保存下来，配合时间维度去看，能提前好几周发现潜在风险。

还有一个经验：巡检时一定要关注Pod的分布情况。如果一台节点同时承载了大量同一个服务的Pod，这台节点出故障时影响范围会被放大。控制系统里加了调度分布检查，发现某台节点上同一Deployment的副本数超过设定值时，就会提示人工介入调整。

4.2 证书轮换的自动化处理

K8S集群的证书问题，基本上每个维护超过一年的人都遇到过。默认证书有效期一年，到期后各个组件之间认证失败，表现形态各异：API Server拒绝请求、kubelet报x509证书过期、甚至工作负载正常但kubectl完全没反应。

控制系统对证书的管理做了一个固定流程：每个月巡检时自动检查所有证书的剩余时间，发现剩余时间小于45天就触发轮换流程。轮换本身用kubeadm完成，命令其实很简单：

# 检查证书过期时间 kubeadm certs check-expiration # 更新所有证书 kubeadm certs renew all # 重启控制面组件 kubeadm certs renew all --config=/etc/kubernetes/kubeadm-config.yaml

renew all之后，控制面的静态Pod会自动重启加载新证书。但注意，worker节点上的kubelet证书也需要一并处理，否则控制面再次连接worker时还是会过期。我们的流程是控制面更新完毕之后，再批量对所有worker节点执行kubelet证书更新及重启。这个顺序一定要固定：先控制面后节点，不然会出现一边有新证书一边还是旧证书的中间状态。

证书这东西最大的风险是你不知道什么时候会出问题。所以哪怕你有自动轮换机制，也一定要保留一张“最后防线”的告警：证书剩余天数低于7天时，不光在日志里记录，还要直接发告警到值班群。我见过太多因为阈值时间设置太久而让人放松警惕、最后证书真的过期的事故。

4.3 集群升级编排与回滚策略

K8S社区版本迭代很快，生产集群不可能一直停在旧版本上。但升级操作对生产环境来说风险极高，尤其跨小版本升级，各种配置兼容性问题都可能冒出来。控制系统的升级流程遵循一个严格顺序：先升级控制面，再升级worker节点；控制面内部先升级主节点，再逐台升级其他控制面节点。

控制面的升级主要用kubeadm完成。流程是：先更新kubeadm到目标版本，再执行kubeadm upgrade plan看影响，确认无误后执行kubeadm upgrade apply。这一步会更新API Server、Controller Manager、Scheduler的镜像以及相关证书。

# 查看升级计划 kubeadm upgrade plan # 执行控制面升级 kubeadm upgrade apply v1.29.3

worker节点升级则相对简单：先驱逐这台节点上的Pod，然后升级kubelet和kubeadm，最后重启kubelet并取消驱逐。这里有个小细节：驱逐Pod时必须加--ignore-daemonsets参数，因为DaemonSet的Pod被驱逐后马上会在同节点上重建，一直等待会卡死流程。

# 驱逐节点上的工作负载 kubectl drain node-01 \ --ignore-daemonsets \ --delete-emptydir-data \ --force # 升级kubelet相关软件包 apt install -y kubeadm=1.29.3-00 kubelet=1.29.3-00 # 重启kubelet systemctl restart kubelet # 恢复节点调度 kubectl uncordon node-01

升级前后各做一次完整巡检，比对指标差异。一旦发现升级后某个核心指标异常，控制系统的回滚策略是：控制面可以直接用kubeadm upgrade apply回到上一版本，但worker节点只能通过重新安装旧版本软件包再重启kubelet来回滚。所以我的建议是：升级前一定要记录每台节点当前的软件包版本和配置内容，不只是记在脚本日志里，还要拍照留档。真到回滚的时候，这些记录能救你一把。

4.4 节点上下线与流量调度控制

生产环境的日常运维里，节点下线是高频操作。机器要维修、硬件要扩容、机房要断电，都需要把某台节点的业务先迁走。控制系统把整个下线流程做成了脚本：先标记不可调度，再驱逐全部工作负载，最后等待节点进入Ready状态但不可调用，才算完成。

驱逐的顺序很有讲究。如果一个节点上同时运行着有状态服务和普通Deployment，一定要先对有状态服务做特殊处理。比如类似数据库或消息队列这种角色，直接驱逐可能导致数据丢失。我在流程里加了“预留节点”机制：对标签为stateful的Pod不做强制驱逐，只做可维护性通知，由应用负责人确认后再手动操作。自动化不能一刀切，这是我在生产环境学到的很重要的一课。

节点上线正好相反：先确保节点通过前置检查，然后取消不可调度标记，观察Pod调度情况，确认新调度上来的Pod运行正常再结束流程。上线和下线两项操作，建议都安排在业务低峰期执行，并且每条流程的执行人必须收到完整的操作回执，不能脚本跑完就当作结束了。

5. 生产环境排障实录：那些自动化和人共同踩过的坑

5.1 问题背景与排查方法分离，先讲查到的方法再讲坑

自动化系统解决的是“可重复操作”的问题，但现场排障永远是运维工作里最考验经验的环节。这里记录几个我在这套控制系统运行过程中真实遇到过的问题。虽然具体环境可能跟你的不一样，但排查思路和坑点有很高的通用性。

5.2 常见问题速查表

5.3 最值得记住的几种场景复盘

第一个让我印象深刻的坑是证书新老交替过程中的“间歇性访问失败”。当时控制面证书轮换完成，控制面组件没问题，但部分worker节点还在用旧证书连接API Server。现象就是kubectl能连上、业务Pod正常，但某些节点上报的状态时而正常时而过期。这种半新半旧的中间状态是定时炸弹，唯一的解决办法就是流程固定：先更新完所有控制面，接着立即更新全部worker节点，中间不要隔太久。

第二个坑是keepalived的VIP切换造成API Server短暂不可用。现象是VIP从第一台控制面节点切到第二台时，应用侧出现两到三次连接报错。原因在于VIP切换后，新的API Server实例要重新建立所有客户端的连接，而客户端没有做重连重试机制。这个问题的根因不在K8S，而在访问API Server的客户端配置。后来我们在所有调用方那里加了连接池重试逻辑，问题才彻底消失。这个教训再次印证了：高可用不仅仅靠集群本身，客户端也得能适应故障切换。

第三个坑是磁盘空间告警。某天发现etcd的DB文件增长异常快，但集群负载并没有明显变化。查了一圈发现是有个服务在疯狂创建又删除Pod，产生了大量历史数据。这个问题的本质是etcd存储了所有事件记录，如果某个业务狂刷事件，磁盘就会被缓慢写满。我调整了etcd自动压缩周期，同时对高频Pod变更的命名空间加了事件数量告警。现在这套机制帮我至少避免了两三次类似的磁盘告警。

另一个很多人容易忽略的坑是K8S版本升级时CNI插件的兼容性。我升级某个集群从1.28到1.29之后，Calico的Pod一直CrashLoopBackOff。排查发现是Calico版本太旧，不支持新版本K8S的API。升级集群版本的同时必须同步升级CNI插件。控制系统在升级编排里加了版本兼容性检查：升级前对比集群版本和CNI插件支持范围，不满足的话直接中止流程并提示人工处理。从此之后再没遇到过CNI插件被升级搞挂的问题。

6. 这套控制系统用了两年之后，我的一点感受

K8S Control System这个名字听起来有点唬人，但拆开看其实就是一份配置仓库加一堆可重入脚本加一个巡检计划。它帮我解决的最大问题不是节省时间，而是让整个集群的状态变得可预期、可描述、可修复。以前我维护集群靠的是脑内状态图和一条条手敲的命令；现在靠的是配置清单和自动对账。心态完全不一样了。

这两年我踩过不少坑，也积累了一些心得。如果你想在自己的环境里做类似的自动化控制链路，我的建议是四条：第一，配置文件和逻辑必须分离，配置文件里只写目标状态，不要混入执行逻辑；第二，所有脚本必须做到可重入，不然自动化流程执行到一半失败时会陷入更复杂的修复流程；第三，巡检一定要输出数值而不是简单的是或否，趋势判断能帮你提前发现潜在问题；第四，自动化能解决80%的固定操作问题，但剩下20%的边界情况，人的判断和现场排查经验依然无可替代。

最后说个实用的小技巧：不管你的自动化系统做得多么完善，都请在每台节点上保留人工介入的手段。比如确保每台机器都能通过堡垒机登录、sudo权限没有误删、紧急维护时能直接手动执行kubectl。生产环境永远保留最后一道“人工逃生门”，任何时候都别把路走死。这套控制系统再可靠，也只是工具；真正为业务兜底的，永远是清醒的运维判断。