K8s集群又崩了这个标题我看着特别眼熟因为一年多前的我们就是这么过来的。我们团队500人跑在K8s集群上的业务有几百个生产、预发、测试、开发环境加起来十几个集群。最惨的时候平均一个月出8次故障几乎每周都要救火有一次证书过期直接把线上打挂整整影响两个小时。后来我们干了一件事把底层从手工维护的kubeadm集群逐步迁移到Sealos并且把交付、升级、监控、演练这套流程重新捋了一遍关键故障率才真正降到0。这篇文章不是给Sealos吹彩虹屁也不是说K8s不好而是想把我踩过的坑、试过的方案、最后沉淀下来的实操方法分享出来给正在被集群稳定性折磨的运维、SRE、后端架构师一个参考。先说清楚这篇文章能解决什么问题如果你还在手工搭K8s或者集群动不动就证书过期、节点NotReady、etcd磁盘满那你大概率能从里面找到共性原因。如果你已经在用Sealos也可以看看我们的环境规划、监控告警和故障演练是怎么做的有些细节是官方文档不会写的。1. 500人团队的K8s集群为什么会月均崩8次1.1 不是K8s不行是很多故障根本不是K8s的故障先说一个我自己的判断我们那8次故障真正由Kubernetes核心组件本身引起的可能也就一两回。剩下的大部分都死在周边生态和人的操作上。举个例子有一次生产集群“崩了”表面现象是所有Deployment都拉不起新Pod业务接口频繁超时。大家第一反应是K8s控制面出问题了一通排查apiserver、scheduler、controller-manager全都没事。最后才发现是某个同事在清理镜像时不小心把集群的镜像仓库里好几个业务镜像tag覆盖了Kubelet那边拉不到镜像。你说这算K8s的故障吗严格说不算但它确实让平台不可用了。还有一次更憋屈某台master节点的证书过期kubelet没法跟apiserver建立TLS连接节点状态直接变成NotReady。当时我们还在用kubeadm搭的老集群证书续期全靠手工哪台机器忘了续哪台就出事。这种问题根子上不是K8s不稳定而是你的集群生命周期管理根本没有自动化。1.2 老集群是怎么一步步变成“定时炸弹”的我们早期搭K8s用的是kubeadm一台一台初始化master再手动join节点。当时觉得没啥毕竟文档都有照着敲命令就行。但问题在于每个环境都是不同的人在不同时间搭的Kubernetes版本、CNI插件、containerd版本都不一样。证书有效期默认一年到期前没人记得续也没有监控能提前发现。升级永远不敢做因为不知道升级后会不会把老配置搞坏。高可用靠额外部署HAProxy和Keepalived但这两套东西本身也要维护一旦VIP漂移有问题整个apiserver入口就堵住了。这些配置漂移和手工操作才是真正的“定时炸弹”。我们曾经统计过一次故障发现至少有一半是可以被自动化操作避免的。1.3 8次故障的构成表我整理了一下当时一个月的典型故障构成方便你对照自己环境故障类型出现次数根因平均处理时长证书过期2手工续期遗漏1~2小时etcd磁盘满1没有备份清理策略2小时节点NotReady2磁盘空间或kubelet异常1小时DNS解析超时1CoreDNS副本数不足、节点负载高40分钟人为错误1误删镜像tag/误操作ConfigMap2小时镜像仓库故障1仓库存储后端过载1.5小时看着好像每个故障都不大但在业务方眼里任何一次POD重启、接口超时、服务不可用都是“K8s崩了”。这也倒逼我们后面做了一个决定与其继续补补丁不如把整个集群交付方式推倒重来。2. Sealos凭什么能让故障率降下来2.1 先用一句话说清楚Sealos是什么Sealos本质上是一个Kubernetes发行版也是一套集群生命周期管理工具。它把原来需要手动执行的kubeadm初始化、CNI部署、证书管理、高可用负载均衡配置、甚至常用组件安装全部收拢成“集群镜像”和“一条命令”。我打个比方以前用kubeadm算是买零件自己组装服务器主板、CPU、内存、电源都得自己匹配运气好能点亮运气不好点不亮还得查兼容性。Sealos更像是给你一台品牌整机厂商已经把关键硬件兼容性测过了你开机就能用后面加内存条、换显卡也有标准操作。当然它不是只解决“安装”这一步。Sealos后续还可以用来加节点、删节点、重置集群、升级版本、安装应用商店里的中间件相当于把集群的“一辈子”都管起来。2.2 我们对比过的几套K8s部署方案当时我们内部认真对比过几套方案不是头脑一热就换的方案安装复杂度高可用默认能力证书维护组件生态我们最终选择kubeadm高手动步骤多弱需要自己搭LB手工续期标准但啥都要自己装弃用RKE2中命令简洁较强内置etcd快照自动轮换来自Rancher生态可以但离线分发麻烦KubeKey中KubeSphere底座较强有管理界面跟KubeSphere绑定较深没选Sealos低一条命令内置IPVS/LVS负载均衡支持延长与轮换应用商店集群镜像机制采用这里不是说其他方案不行。RKE2在不少公司跑得很稳KubeKey可视化也不错但结合我们团队的实际痛点——环境多、人手少、要快速复制、还要能“救回来”——Sealos的集群镜像机制和快速重建能力是和我们最匹配的。2.3 Sealos真正帮我们省时间的地方从实际使用感受来说Sealos帮我们省掉的不只是搭建时间而是整个运维心智负担交付一套HA集群从一天缩短到半小时而且结果可预期。集群镜像能像Docker镜像一样打tag、复用测试环境验证过的镜像生产环境跑同一套消灭“环境差异”。证书过期时间可以拉到10年再配合巡检基本不用怕证书问题。应用商店里点几下就能拉起MySQL、Redis、Prometheus等常见组件适合快速搭环境。就算集群真的搞坏了也能跑一遍reset后重新run重建成本极低。一句话总结以前是“不确定性”主导每次部署都像赌博现在是“可重复性”主导跑多少次都一样。故障率降下来靠的就是把不可控变成可控。3. 我们是怎么用Sealos重建整个K8s环境的3.1 建集群前先做环境规划别急着执行安装命令。Sealos虽然命令简单但底层还是K8s集群操作系统、网络、存储、时间同步这些地基不打好后面照样出问题。我们当时整理了这样一份环境检查清单操作系统统一用Ubuntu 22.04 LTS内核版本更新驱动兼容性好。网络所有节点内网互通预留VIP网段防火墙放行K8s相关端口。时间所有节点必须同步NTP时间漂移会导致证书校验失败。主机名规划好命名规则避免默认的localhost。磁盘/var/lib/containerd 单独挂大容量数据盘避免跟系统盘抢空间。swap必须关闭否则kubelet会报警。SSH准备好root免密或密码Sealos需要通过SSH在节点上执行命令。这套清单我们后来做成了自动化脚本所有新节点都会先跑一遍检查通过后再进入Sealos流程。3.2 一条命令跑起来实际执行记录Sealos 4.x 的操作路径大概是先安装二进制然后拉取集群镜像最后一条命令把master和node节点传进去# 安装Sealos命令行工具 curl -sfL https://raw.githubusercontent.com/labring/sealos/main/scripts/install.sh | sh -s v4.3.0 # 拉取目标版本集群镜像 sealos pull kubernetes:v1.27.3 # 创建3个master 3个node的高可用集群 sealos run kubernetes:v1.27.3 \ --masters 192.168.1.11,192.168.1.12,192.168.1.13 \ --nodes 192.168.1.21,192.168.1.22,192.168.1.23 \ --passwd YourStrongPass这里解释一下参数--masters传多个IP时Sealos会把这几个master放到同一个高可用组里面自动配置负载均衡不需要你再单独部署HAProxy。--passwd是SSH登录密码用于远程执行初始化。如果你用的是密钥认证可以不传这个参数。我们实测下来三台master加三台node的集群大概15到20分钟就能装完。装完之后用kubectl get nodes看六个节点全是Ready状态。这个速度在以前用kubeadm手工搭的时候是不可想象的。注意生产环境不要用弱密码能用SSH密钥就不用密码如果第一次执行失败先看日志修好环境问题再重试不要反复重置节点。3.3 高可用不只是多masterSealos里的负载均衡很多人理解高可用就是多放几台master但Kubernetes控制面还有个很关键的组件——负载均衡。kube-apiserver需要有一个稳定的入口让所有node上的kubelet和外部kubectl都能连上。以前我们用kubeadm要么自建HAProxyKeepalived要么买云上的SLB都很费劲。Sealos在创建多master集群时会内置一套基于IPVS的负载均衡方案VIP会在多台master之间漂移。也就是说你传三个master IP进去它自己就把“前端VIP”和“后端apiserver”之间的关系搭好了。这套设计给我们带来的直接好处是master节点再也不是单点哪怕其中一台Master因为运维问题重启apiserver入口依然可用业务侧无感。3.4 应用商店和Operator从“装个中间件折腾一天”到“点一下”K8s集群搭好只是第一步真正让500人团队用起来还得解决中间件的问题。以前测试环境要一套Redis我们得先配StorageClass再写Helm values最后还要等PVC创建成功一个不小心就是两个小时。后来Sealos自带的应用商店帮了很大忙MySQL、Redis、MinIO、Prometheus这些常用组件都有现成入口测试环境基本是点一点就能用。但这里我要泼一盆冷水生产环境的中间件不要天真地直接商店一键部署。我们只是用商店快速拉起测试环境生产环境依然是专业Operator和定制配置在管。工具降低的是重复劳动的边际成本业务数据和可用性要求还是要自己掌控。3.5 监控告警体系故障从“用户发现”变成“告警发现”监控和告警是整个稳定性体系里最容易被低估的部分。K8s集群不是搭完就完事你得知道它什么时候开始恶化而不是等业务方跑来告诉你“又崩了”。我们在重建集群时顺手部署了kube-prometheus-stack覆盖了节点、Pod、容器、apiserver、etcd等关键指标。告警规则专门盯这几个节点状态异常NodeNotReadyetcd leader切换频繁apiserver访问延迟过高持久化卷状态失败证书剩余天数小于30天告警通道接到企业微信值班同学手机上就能看到。说实话这个体系在Sealos集群上搭建变得异常简单因为基础设施一致了监控规则可以复用不会再出现“生产环境用的告警规则测试环境配不上”这种尴尬事。4. 故障率从月均8次降到0背后的人与流程4.1 把“老师傅经验”变成“版本化配置”很多团队HOLD不住K8s不是技术不行而是“经验只存在于老师傅的脑子里”。谁搭的集群当时用了什么参数版本有没有打过补丁全靠问。人一走知识就断了。Sealos的集群镜像机制让我第一次觉得“集群”这东西可以像软件一样做版本管理。我们把所有环境的集群描述都收进Git仓库测试环境验证过的镜像版本生产环境必须用同一个版本。新增一套环境时不再需要“问一下之前是谁搭的”直接按照仓库里的README跑一遍命令半小时就能复现一套和线上同等配置的集群。这一步看着跟故障率没关系其实关系最大。因为很多故障就是“环境不一样”造成的测试环境没问题生产环境一跑就挂根因往往是某个依赖版本漂移了。4.2 证书、备份、升级最烦的三件事全部自动化我挑三件最枯燥但最容易引发故障的事说第一证书。Sealos支持把证书有效期配置得足够长同时也能在证书接近过期时自动轮换。我们所有新集群直接用长证书配置然后每个月巡检一次剩余天数。这基本让“证书过期”这个故障从我们清单里消失了。第二etcd备份。我们每天凌晨对etcd快照传到对象存储并且写了一个小脚本定期在测试环境尝试恢复一次快照。为什么一定要做恢复演练因为只备份不演练真到灾难发生时你根本不知道备份能不能用。我们第一次做恢复演练时足足花了40分钟后来优化了流程才压到10分钟以内。第三版本升级。以前用kubeadm升级一想到乱七八糟的etcd迁移和证书轮换就头大。Sealos的方法相对简单先在测试环境用新版集群镜像run一遍验证业务兼容性再在生产环境按步骤执行升级。因为配置文件是统一的升级路径也成了标准动作而不是每半年一次的“渡劫”。4.3 故障演练第一个月每周“故意搞坏一次”这里分享一个我们内部做了觉得特别值的事重建集群后的第一个月我们每周挑一套非生产环境故意搞坏一次练的是“恢复动作”。重启一台master节点看VIP会不会漂移。把某个node的Kubelet停掉看Pod调度是否正常。在测试环境把etcd数据目录塞满模拟磁盘满再走一遍清理和恢复流程。直接把集群reset掉然后用Sealos重新run一套。这轮演练逼出了很多平时发现不了的问题比如DNS缓存超时、某个脚本没有幂等性、备份恢复时PVC权限不对。等到这些问题全部修掉我们才敢把“故障率归零”这句话说出来。4.4 500人团队的协作平台工程化和自助化最后说人。500人团队如果人人都能摸kubectl那不是先进是灾难。我们当时的做法是把K8s封装成一个内部发布平台底层是Sealos集群上层是统一的发布入口。业务只需要填项目名、镜像地址、副本数点发布。平台负责生成Deployment、Service、Ingress等资源。这样改了之后底层集群的变更权限收拢到平台团队少数几个人手里业务方不需要关心节点、Pod、调度这些概念。很多人为操作故障比如误删命名空间、改错ConfigMap被平台权限和流程挡住了故障率自然掉下来。5. 常见问题与排查技巧实录5.1 Sealos执行安装中途卡住如果你第一次跑Sealos时卡在某个节点上先别急着重新安装。从我们经验看大部分卡住跟Sealos本身无关而是节点“预检查”没过。重点排查这几个点SSH能否正常连通、root用户是否允许远程登录、系统是否做过swapoff、防火墙有没有放行K8s端口、节点之间DNS能否解析。我们后来在安装前先跑一遍环境检查脚本问题少了一大半。如果真的卡住了先确认是不是网络下载集群镜像太慢必要时提前把镜像pull到本地或配置镜像加速再重新执行。5.2 集群运行很久后证书又过期了就算有Sealos也不代表证书一定能完全免运维。现象是kubectl执行命令时报HTTP错误或者apiserver日志里出现TLS相关报错。处理思路不要手动去删secret正确的做法是用Sealos提供的证书更新能力或者通过kubeadm类似的命令重新生成证书并滚动重启组件。更重要的不是“出问题怎么救”而是“怎么不出问题”——把证书剩余天数监控起来剩余少于30天自动告警提醒。5.3 节点NotReady但看起来还活着这种是最烦人的SSH上去看CPU内存都正常但K8s就是把你踢出可用节点。常见原因有三个磁盘满了容器运行时无法创建新容器。kubelet服务异常journalctl -u kubelet -f -n 200能直接看到错误。CNI插件出问题比如Pod网络网段冲突、路由规则丢失。我的建议是先查看kubelet日志再看/var/lib/containerd的磁盘占用最后查CNI的Pod状态。大部分NodeNotReady都不是节点“死”了而是节点“没法跑新Pod”。5.4 网络插件和CoreDNS的坑我们经历过业务反馈“DNS解析超时”最开始的排查绕了不少弯路。后来发现是CoreDNS副本数太少节点一忙起来队列就积压。把副本数调成与CPU核数相关并开启了nodeLocal DNSCache之后这个告警基本消失。另外如果你在Sealos集群里换了CNI插件要特别注意节点上的路由规则和iptables是否干净换网络插件前最好在新节点上先验证不要直接在已有生产节点上操作。5.5 一些建议工具层面Sealos确实帮我们把集群交付和运维做得更简单但它不是银弹。真正让故障率降下来的是“可重复交付 自动化运维 监控告警 故障演练”这一整套组合拳。如果你们团队的集群还是手工维护、没有告警、没有备份恢复演练换个工具大概率也就是从一种混乱变成另一种混乱。我个人最深的体会是用了Sealos之后团队的注意力终于从“怎么把K8s跑起来”变成了“怎么让业务在K8s上跑得更好”。以前看到告警第一反应是慌现在看到告警第一反应是按预案处理。这种心态上的转变可能比任何工具都值钱。最后再说一个实用的小技巧不管你用什么工具搭K8s建议每个月挑一个周末的凌晨把整个集群的搭建流程完整走一遍就当是灾备演练。这个习惯我们坚持了一年多期间发现了很多文档没更新、脚本失效、镜像tag被覆盖之类细节问题。等到真正需要紧急恢复集群的时候你会感谢当初那个“多跑一遍”的自己。