K8s集群又双叒叕崩了你们是不是也在经历这种循环半夜被告警电话叫醒一脸懵地打开电脑SSH连上master节点看着满屏的报错日志心跳跟etcd的leader选举一样忽上忽下。先说一下我们团队的背景500多人的研发团队K8s集群支撑着从研发测试环境到生产业务的所有容器化服务高峰期每天调度上万个Pod。在切换到新的集群管理方案之前我们的集群故障率高得离谱——平均每个月要出8次左右的重大故障每次故障平均恢复时间在1到4小时不等。每周五下午三点整个平台组的同学都会下意识地紧张起来因为根据墨菲定律这个时间点线上集群最容易出幺蛾子。后来我们团队做了一个决定把集群的底层运维方式彻底换掉从传统的“裸Kubernetes 手工维护各种周边组件”切换到Sealos这套云原生基础设施方案。半年多下来结果比较直接月均故障次数从8次降到了0。这不是什么魔法也不是某个工具开了光而是把之前那些“人肉运维”导致的不确定性全部消灭掉了顺便把团队从救火队员的角色里解放了出来。这篇文章我不打算给你讲一堆纯理论而是把我们从崩溃边缘走到相对稳定的全过程中选型背后的思考、踩过的坑、实际操作的步骤以及那些常规文档里不会写清楚的东西尽量原原本本梳理出来。如果你正在被K8s集群的稳定性问题折磨或者刚准备上手自建集群这篇文章应该能帮你少走几个月的弯路。1. 先把话说明白K8s集群为什么会“动不动就崩”在聊怎么解决之前我们得先搞清楚K8s集群为什么那么容易出问题。很多人觉得K8s就是“装好Docker、装好Kubelet、再把控制面拉起来”就完事了但真正跑过生产环境的人都清楚K8s的复杂程度跟你自己写过一个高可用服务时体会到的复杂度完全不是一个量级。1.1 崩溃点不是K8s本身而是围绕它的“木桶短板效应”K8s本身是一个非常健壮的分布式系统它的设计目标就是“哪怕一个节点挂掉整个系统照样能跑”。但问题恰恰出在这里K8s为了保持这种健壮性引入了大量的外围依赖和组件比如网络插件CNI、存储驱动CSI、负载均衡MetalLB或云厂商LB、DNS插件、证书管理机制以及最著名的分布式存储组件etcd。任何一个组件出现异常都会直接表现为“集群不可用”或者“Pod调度卡住”。举几个我们真实遇到过的案例etcd磁盘满了。这个是最常见也是最致命的。etcd默认数据目录空间使用率超过90%时它会停止接受写入请求直接导致整个集群进入“只读”状态连Pod的调度都没法执行。当时的排查过程极其痛苦因为K8s的各个组件表面上都在正常运行但就是创建不了新Pod修改不了Deployment副本数最终一层层查下去才发现是etcd空间满了。证书过期。Kubernetes集群内的组件之间全部通过TLS证书通信自签证书的有效期一般是1年有些发行版是3年。到期前如果没有自动轮换机制集群会在一瞬间“失联”。CNI网络插件版本不兼容。有一次升级集群Kubelet版本和Calico的版本不兼容集群节点全部变成NotReady状态Pod创建出来了但网络不通业务同事报了一堆故障。Kube-apiserver内存被打爆。当集群规模上来之后apiserver作为所有请求的门户如果监控不完善或者存在大量不合理的list/watch请求内存和CPU都会飙升最终节点OOM控制面瘫痪。这些故障的共性是什么它们都不是K8s的核心调度逻辑坏了而是围绕K8s的各种外围能力出现了问题。传统方式部署K8s意味着你不仅需要一个好用的K8s还得自己独立运维etcd、Calico、CoreDNS、Ingress Controller、监控组件、日志组件……样样精通这是极其反人类的。1.2 “人肉运维”的不确定性是故障率飙升的根源我们再往深挖一层为什么同样是K8s有的团队用得好好的有的团队天天救火以我们团队为例在切换方案之前集群的构建方式非常“原始”基于文档手工部署先装kubeadm再初始化控制面然后手动安装网络插件再手动配存储、配Ingress、配监控。好处是灵活坏处是你很难保证生产、测试、预发环境的配置完全一致。我在帮别的团队排查问题的时候经常发现同一个配置项在A环境写的是enable-self-signed在B环境写的是enable-ssl这种隐蔽的差异带来的是完全不可预期的行为。更关键的是K8s刚兴起那两年网上的教程和各种“最佳实践”鱼龙混杂很多操作手册拿到生产环境一跑就出问题。版本差异、内核参数、网络环境限制每一个变量都能让你折腾到深夜。我一度觉得K8s运维的本质就是用命去填知识的盲区。所以降故障率的第一步不是找一个更牛逼的监控平台也不是配一个更高级的告警规则而是把“不可控的环境差异”压缩到最小。2. 为什么偏偏选了Sealos从“搭积木”到“开箱即用”的转变我们当时也考虑过不少方案。Rancher现在是RKE2用过一段时间界面确实漂亮后期是Corporate版本Kubesphere的社区很活跃它的可视化做得很不错也有人推荐直接用云厂商的托管K8s服务但我们有相当一部分业务要跑在自建机房物理机上这个没法直接适用。当时恰好我在调研过程中接触到了Sealos它有几个非常戳中我痛点的特性这是最终促使我们决定在自建机房环境做一次完整升级的关键。2.1 Sealos不是一个面板而是一套完整的“集群操作系统”很多初次接触Sealos的人会问它是不是又一个K8s可视化面板还真不是。你可以把它理解为一个“打包好的集群镜像”类似你用Docker镜像来封装应用环境一样Sealos封装的是一整个K8s集群运行所需的全部软件栈包括容器运行时、Kubernetes本体、网络、存储、Ingress、监控甚至还有数据库、消息队列这类基础云服务组件。这意味着过去我们需要花两三天去装的插件、调的参数、配的优化项现在通过Sealos的方式一次性收敛进集群镜像里。换一个说法它把底层操作系统和K8s周边设施像Docker image 一样做成了镜像资产直接扔给任何一台干净的服务器就能拉起一个完整可用的集群环境。这带来一个非常直接的好处可复现性。不管你是初始化生产集群还是临时建一套测试环境拉取同一个镜像出来的集群环境是一致的不会再出现“生产环境和测试环境行为不一致然后就崩了”的鬼故事。2.2 对比传统部署方案优势是“少”而不是“多”在选择技术方案之前最忌讳的就是盲目赶时髦。决定采用Sealos之前我们团队做了一个比较详细的对比在这里分享给你可以作为你们选型的参考。对比维度传统kubeadm手工部署Rancher/KubesphereSealos集群初始化复杂度高需要手工执行大量初始化命令中等界面引导但仍然要理解每项配置含义低单条命令完成部署组件一致性低各版本混装是家常便饭中受面板自身版本捆绑高镜像化统一管理升级难度高涉及证书、组件、参数兼容性中需要面板进行复杂版本升级低重新应用新版本镜像即可外围组件存储、网络、监控需要单独部署管理和调优一些厂商配套部分组件需单独内置并预调优对运维人员的要求需要精通底层原理需要掌握面板操作与底层原理需要了解基本原理但不要求精通所有细节注意我这里的结论不是说Sealos让运维人员不需要懂任何原理了。它减少的是踩坑的随机性而不是减少你理解系统的必要性。这非常关键。一个完全不懂etcd的人用Sealos虽然能拉起集群但遇到故障依然两眼一抹黑。所以它解决的是把大量“因为经验差异导致的偏差”消灭掉让问题能够稳定复现、稳定解决。2.3 一个特别打动我们的细节单机模式也有一致的体验很多中大型团队其实都有这样的尴尬需求开发环境或者临时压测环境不需要那么大的集群但线上生产又要按真实规模来。如果部署方式不一致开发和测试阶段根本复现不了生产环境的问题。Sealos通过镜像参数化的方式可以快速创建一个单节点集群作为开发环境但它的集群组件、网络方案、运行时跟生产环境的多节点集群完全一致。这让“开发环境能跑生产环境一定也能跑”这句以前是口号的东西第一次变成了比较靠谱的保障。3. 实操记录我是怎么用Sealos重建集群并稳定跑上生产的光说不练假把式。这一部分我会尽量详细地还原我们部署的完整流程包括命令细节、资源规划、高可用配置、以及日常运维的关键动作。如果你想直接参考落地这一章应该最有价值。3.1 部署前的资源规划按职责划分别混用K8s集群部署前最忌讳的是角色划分混乱。我们之前的旧集群node节点既跑业务Pod又跑集群监控和日志组件导致资源竞争业务高峰时Pod CPU被监控组件抢掉直接雪崩。资源规划看起来是件小事其实解决了大量潜在故障。我们这套Sealos集群的标准规划如下节点角色数量配置参考主要承担职责Master/Control Plane3台16C32G系统盘200G SSD运行etcd、apiserver、scheduler、controller-managerWorker/业务节点8台32C64G起系统盘与数据盘分离运行业务容器、中间件容器存储节点可选3台起32C64G大容量高性能盘提供分布式存储能力如果你需要Sealos内置的存储我们的经验是Master节点在资源满足要求的前提下不应部署繁重的业务负载。有人为了省钱在测试环境让Master兼任Worker角色这在测试环境还能忍生产环境这么干一旦遇到峰值流量apiserver和业务容器抢CPU整个集群调度都会变得极其不稳定。3.2 集群初始化从裸机到可用集群只用一套命令在新方案下集群初始化确实变得非常简单。准备一台干净的Linux服务器我们在生产环境用的是Rocky Linux 9内核和系统基础组件配置好之后直接执行类似以下指令取决于你选用Sealos版本的命令语法# 拉取对应版本的集群镜像 sealos pull labring/kubernetes:v1.29.0 # 针对多节点集群初始化第一个master节点 sealos run labring/kubernetes:v1.29.0 \ --masters 192.168.10.10,192.168.10.11,192.168.10.12 \ --nodes 192.168.11.10,192.168.11.11,192.168.11.12 \ --passwd your-secure-password这里稍微解释几个细节因为很多人第一次用的时候容易困惑--masters参数是控制面节点的IP列表写上三个IPSealos会自动把这3台机器组成一个高可用控制面内部的etcd集群和apiserver负载均衡会自动配置好。--nodes参数对应的就是要加入的业务节点IP列表。如果你用的是SSH密钥认证可以指定对应的私钥参数这样不用在命令行里直接写密码。执行完成之后Sealos会自动把环境检查、ssh通信、容器运行时安装、控制面初始化、节点加入、网络插件部署这一整套动作串联起来。整个过程快的话大概十来分钟就能得到一个多节点高可用集群。这个体验对我们这些曾经花三天手工部署的人心情是复杂且激动的。3.3 高可用细节证书与负载均衡怎么处理很多人关心多Master如何保证高可用。传统kubeadm方式下你需要自己配置外部负载均衡比如HAProxy/Nginx把API Server的请求分发到三个Master节点。Sealos内部对高可用的处理方式跟这个思路类似但自动化程度更高。需要注意的一个点是DNS和VIP虚拟IP的处理。如果你的自建机房环境有现成的负载均衡设备或者支持VIP可以配合使用。如果没有Sealos在初始化过程中也会帮你完成一套内置的负载均衡方案。实际使用中我们发现它会让kubelet和kubectl自动指向一个本地的LB地址从而规避单点故障。之前手工部署时最噩梦的就是证书管理初始化生成的CA证书、各组件证书、ServiceAccount密钥过期时间不同维护起来非常烦。Sealos在集群镜像中默认处理了证书自动轮换的问题这也让我们从“怕证书过期”的心理阴影中彻底走出来了。3.4 日常升级不再是“拆炸弹”在旧集群环境里我们最害怕的就是升级K8s版本生怕哪个组件升级后配置不兼容。基本上每次升级都要提前一个月做方案评审、预演、回滚计划结果还是经常出篓子。Sealos对升级的处理相对平滑。它的做法还是基于镜像机制拉取一个更高版本的集群镜像然后执行升级命令它会自动处理控制面和节点的滚动升级。我们在半年内顺利做过一次大版本升级整个升级过程中业务没有出现中断具体操作大致类似# 先拉取新版本镜像 sealos pull labring/kubernetes:v1.30.0 # 执行集群升级 sealos upgrade --cluster my-cluster当然我不是建议你就盲目相信升级一定零风险任何生产环境的升级都建议先在测试集群做一次完整演练再把方案搬到生产环境。但至少在操作复杂度上这个过程已经变成了“标准操作”不需要投入全部运维人力去搏一把。4. 稳定运行半年后我们如何做集群体检与故障预防故障率降下来不等于不用干运维的活了。相反我们的精力从“紧急救火”转向了“日常体检”和“容量规划”。以下这些检查项和方法是这半年来我们维护集群最核心的几个动作。4.1 把etcd健康检查排在第一位etcd是K8s的地基地基一出问题整栋楼都摇摇欲坠。我们的巡检脚本里第一项就是检查etcd集群的健康状态、空间使用率、碎片率和慢请求情况。相关命令并不复杂重要的是你要定期去看并设好告警阈值。我建议至少关注以下几个指标指标建议阈值为什么不安全etcd db大小总空间使用率低于70%超90%直接拒绝写入集群只读etcd leader切换次数一段时间内不频繁切换频繁切换说明网络不稳定或磁盘IO抖动apiserver请求成功率99.9%以上低于阈值说明控制面压力过大或组件故障节点NotReady状态0个出现则排查kubelet、容器运行时、网络4.2 监控告警让问题暴露在用户发现之前Sealos这套方案自带了一些监控组件集群部署完成后可以快速启动一个Dashboard和监控大盘。为方便快速查看节点的CPU、内存、网络和磁盘状态我们也保留并配置了Prometheus等监控工具链。这类工具的使用门槛不高但要记住一个关键点告警规则不能太多否则大家会麻木最终真的故障来临时反而没人响应。我们定义告警规则的筛选原则是只告警“影响业务可用性”和“可能导致数据丢失”的场景。比如kube-system命名空间下的Pod重启次数异常上升节点内存使用率持续超过85%且持续时间超过10分钟etcd请求成功率低于99%证书剩余有效期不足30天其他一些“毛刺”类的问题宁可让它默默记录到日志里也不要疯狂打扰值班的同学。4.3 备份与恢复演练是安全感真正的来源一个稳定的集群备份是底线。K8s的备份和传统数据库备份不太一样你不仅要考虑etcd里的元数据还要考虑持久化存储里的业务数据。我们在Sealos集群环境里最常做的备份动作就是周期性对etcd做快照并把快照文件同步到独立的备份存储机器上注意别放在同一个节点上。几乎每个季度我们都会做一次完整的恢复演练搭建一套全新的临时集群用etcd快照进行恢复验证关键业务能正常拉起。只有当你亲手做过一次恢复流程且成功之后你面对“集群挂了”这件事时才能真正心平气和而不是慌不择路。4.4 巡检checklist一套免费的“治未病”方案这块内容是我们团队每周五例行巡检时实际使用的分享出来可以直接用检查所有Master节点的/var/log/messages或者journalctl日志有没有持续刷新的异常信息。检查etcd空间使用率同时执行etcdctl defrag如果开启自动压缩和碎片整理周期。查看Kubernetes事件筛选Warning级别且频繁出现的事件特别是那些“Liveness probe failed”和“Back-off restarting failed container”。检查核心组件Pod副本数是否都符合预期特别是kube-proxy、coredns、calico或flannel这类基础组件。抽查业务Pod的调度分布是否均匀避免因为某个节点被打爆而引发连锁反应。检查证书有效期确认自动轮换机制正常执行。坚持半年做下来你会发现很多潜在故障苗头确实能在萌芽阶段被掐掉。5. 故障排查实录那些依然可能出现的问题与快速定位思路虽然号称“故障率降到0”这里我想特别说明一下0是指没有因为运维操作失误或者基础设施不确定性导致的重大故障。但这不意味着集群永远不会出任何波浪。以下记录一些我们切换后依然会遇到的典型情况以及排查思路供大家参考。5.1 问题某业务Pod频繁重启整个节点负载升高有一次线上突然出现一批Pod反复重启现象表现为容器启动后很快被kill然后重新调度。我们通过监控发现原因是Pod的内存Limit设置过小而业务流量突增后内存占用超限。这个跟Sealos本身没关系纯属资源配额不合理。我们用的小技巧是给业务方一个资源画像工具让每个团队定期查看自己服务的基础资源消耗及时调整资源配置。这个过程中最大的启发是K8s集群的故障往往最后都追溯为“人的问题”。要么是应用配置不合理要么是资源预估不足。平台的职责是给你一个清晰的视图去发现这些东西而不是替你杜绝它们。5.2 问题节点组成“僵死”kubelet挂着但业务不通有一次某个业务节点虽然kubelet进程还活着但已经无法创建新Pod旧Pod也不断报网络异常。我们排查的路径查看kubelet日志没有明显的panic或者报错。再检查容器运行时发现是containerd的存储驱动出现了磁盘空间不足的状况。因为K8s的镜像拉取都需要宿主机存储支撑数据盘满了之后新Pod的镜像拉取直接失败。快速处理的中间步骤是找到并清理废弃的镜像和悬空的日志文件再把监控大盘的磁盘预警收紧了避免再发生类似默默饿死的场景。5.3 问题有人误删了Ingress或ServiceK8s集群人一多权限管理不到位就很容易出事故。比如某团队同学误删了一个全局共享的Ingress配置导致下游服务瞬间不可访问。Sealos默认是基于Kubernetes标准对象做管理所以如果你集群内接入了多个团队建议一定要配置好RBAC权限隔离。权限最小化是集群生产环境的第一安全底线。当然这类误操作可以通过开启审计日志、或者启用回收站类组件去缓解但最核心的永远是流程和权限工具只能辅助。5.4 常见问题速查表异常表现优先排查方向快速处理建议新建Pod一直Pending节点资源不足 / 存储或网络插件问题查看kubectl describe pod事件排查调度器日志控制面组件频繁重启apiserver负载 / etcd性能检查etcd磁盘IO、慢请求、内存占用Node状态NotReady容器运行时异常 / CPU抢占重启containerd/kubelet检查系统负载网络不通或DNS异常CNI配置 / CoreDNS副本重启相应组件检查iptables规则与网络插件集群突然只读etcd空间不足清理etcd数据目录、执行压缩与碎片整理写在最后从“人肉抗灾”到“秩序化运维”这半年我最大的体会很多朋友看到“故障率从月均8次降到0”这个结果第一反应都是“Sealos是不是特别牛的神器能解决所有问题”。其实我更愿意把它看成一种“运维范式”的切换。过去我们把大量的精力花在不停修补“环境差异”和“配置偏差”上根本没有多少余力去关注真正的系统架构、容量演进和业务稳定而当底层环境变成了一套可复现的、标准化的镜像之后我们才终于腾出手来去把那些真正影响稳定性的问题系统化地解决掉。从团队的实际变化来说大家最大的感受是运维终于不再需要“英雄”了。以前每次出大故障总需要有一个资深工程师临危不乱从一堆日志里面找到蛛丝马迹靠直觉和运气挽救集群。而环境标准化之后任何一个合格的工程师照着手册和监控就能完成大部分日常维护与快速恢复团队整体的应对水平被拉齐了。这种“安全感”比任何财务上的指标都更让人踏实。如果你也想迁移到Sealos我个人建议不要一上来就动生产先拿测试集群跑一个月把该踩的坑踩掉再逐步扩大范围。另外不同版本的SealOS命令和配置方式可能会随着时间迭代建议以官方最新文档为准。这套做法的核心思想其实是值得参考的让基础设施向软件资产一样去版本化、可复现、可演进而不要把它当作永远需要人肉呵护的脆弱装置。最后再分享一个小细节我们之前做“周五下午不敢上线新版本”现在虽然还是会有变更但心态完全不一样了。因为环境的可预测性变高了变更的风险变低了遇到问题我们能够迅速定位和回滚。有时候想想真正的技术安全感不是你有多精通底层而是你知道出了问题之后一定有条路能走出来Sealos帮我们打通了这条路剩下的还是需要我们珍惜这段来之不易的稳定期把业务打磨得更好。
从月均8次故障到0：我们如何用Sealos重建稳定K8s集群
K8s集群又双叒叕崩了你们是不是也在经历这种循环半夜被告警电话叫醒一脸懵地打开电脑SSH连上master节点看着满屏的报错日志心跳跟etcd的leader选举一样忽上忽下。先说一下我们团队的背景500多人的研发团队K8s集群支撑着从研发测试环境到生产业务的所有容器化服务高峰期每天调度上万个Pod。在切换到新的集群管理方案之前我们的集群故障率高得离谱——平均每个月要出8次左右的重大故障每次故障平均恢复时间在1到4小时不等。每周五下午三点整个平台组的同学都会下意识地紧张起来因为根据墨菲定律这个时间点线上集群最容易出幺蛾子。后来我们团队做了一个决定把集群的底层运维方式彻底换掉从传统的“裸Kubernetes 手工维护各种周边组件”切换到Sealos这套云原生基础设施方案。半年多下来结果比较直接月均故障次数从8次降到了0。这不是什么魔法也不是某个工具开了光而是把之前那些“人肉运维”导致的不确定性全部消灭掉了顺便把团队从救火队员的角色里解放了出来。这篇文章我不打算给你讲一堆纯理论而是把我们从崩溃边缘走到相对稳定的全过程中选型背后的思考、踩过的坑、实际操作的步骤以及那些常规文档里不会写清楚的东西尽量原原本本梳理出来。如果你正在被K8s集群的稳定性问题折磨或者刚准备上手自建集群这篇文章应该能帮你少走几个月的弯路。1. 先把话说明白K8s集群为什么会“动不动就崩”在聊怎么解决之前我们得先搞清楚K8s集群为什么那么容易出问题。很多人觉得K8s就是“装好Docker、装好Kubelet、再把控制面拉起来”就完事了但真正跑过生产环境的人都清楚K8s的复杂程度跟你自己写过一个高可用服务时体会到的复杂度完全不是一个量级。1.1 崩溃点不是K8s本身而是围绕它的“木桶短板效应”K8s本身是一个非常健壮的分布式系统它的设计目标就是“哪怕一个节点挂掉整个系统照样能跑”。但问题恰恰出在这里K8s为了保持这种健壮性引入了大量的外围依赖和组件比如网络插件CNI、存储驱动CSI、负载均衡MetalLB或云厂商LB、DNS插件、证书管理机制以及最著名的分布式存储组件etcd。任何一个组件出现异常都会直接表现为“集群不可用”或者“Pod调度卡住”。举几个我们真实遇到过的案例etcd磁盘满了。这个是最常见也是最致命的。etcd默认数据目录空间使用率超过90%时它会停止接受写入请求直接导致整个集群进入“只读”状态连Pod的调度都没法执行。当时的排查过程极其痛苦因为K8s的各个组件表面上都在正常运行但就是创建不了新Pod修改不了Deployment副本数最终一层层查下去才发现是etcd空间满了。证书过期。Kubernetes集群内的组件之间全部通过TLS证书通信自签证书的有效期一般是1年有些发行版是3年。到期前如果没有自动轮换机制集群会在一瞬间“失联”。CNI网络插件版本不兼容。有一次升级集群Kubelet版本和Calico的版本不兼容集群节点全部变成NotReady状态Pod创建出来了但网络不通业务同事报了一堆故障。Kube-apiserver内存被打爆。当集群规模上来之后apiserver作为所有请求的门户如果监控不完善或者存在大量不合理的list/watch请求内存和CPU都会飙升最终节点OOM控制面瘫痪。这些故障的共性是什么它们都不是K8s的核心调度逻辑坏了而是围绕K8s的各种外围能力出现了问题。传统方式部署K8s意味着你不仅需要一个好用的K8s还得自己独立运维etcd、Calico、CoreDNS、Ingress Controller、监控组件、日志组件……样样精通这是极其反人类的。1.2 “人肉运维”的不确定性是故障率飙升的根源我们再往深挖一层为什么同样是K8s有的团队用得好好的有的团队天天救火以我们团队为例在切换方案之前集群的构建方式非常“原始”基于文档手工部署先装kubeadm再初始化控制面然后手动安装网络插件再手动配存储、配Ingress、配监控。好处是灵活坏处是你很难保证生产、测试、预发环境的配置完全一致。我在帮别的团队排查问题的时候经常发现同一个配置项在A环境写的是enable-self-signed在B环境写的是enable-ssl这种隐蔽的差异带来的是完全不可预期的行为。更关键的是K8s刚兴起那两年网上的教程和各种“最佳实践”鱼龙混杂很多操作手册拿到生产环境一跑就出问题。版本差异、内核参数、网络环境限制每一个变量都能让你折腾到深夜。我一度觉得K8s运维的本质就是用命去填知识的盲区。所以降故障率的第一步不是找一个更牛逼的监控平台也不是配一个更高级的告警规则而是把“不可控的环境差异”压缩到最小。2. 为什么偏偏选了Sealos从“搭积木”到“开箱即用”的转变我们当时也考虑过不少方案。Rancher现在是RKE2用过一段时间界面确实漂亮后期是Corporate版本Kubesphere的社区很活跃它的可视化做得很不错也有人推荐直接用云厂商的托管K8s服务但我们有相当一部分业务要跑在自建机房物理机上这个没法直接适用。当时恰好我在调研过程中接触到了Sealos它有几个非常戳中我痛点的特性这是最终促使我们决定在自建机房环境做一次完整升级的关键。2.1 Sealos不是一个面板而是一套完整的“集群操作系统”很多初次接触Sealos的人会问它是不是又一个K8s可视化面板还真不是。你可以把它理解为一个“打包好的集群镜像”类似你用Docker镜像来封装应用环境一样Sealos封装的是一整个K8s集群运行所需的全部软件栈包括容器运行时、Kubernetes本体、网络、存储、Ingress、监控甚至还有数据库、消息队列这类基础云服务组件。这意味着过去我们需要花两三天去装的插件、调的参数、配的优化项现在通过Sealos的方式一次性收敛进集群镜像里。换一个说法它把底层操作系统和K8s周边设施像Docker image 一样做成了镜像资产直接扔给任何一台干净的服务器就能拉起一个完整可用的集群环境。这带来一个非常直接的好处可复现性。不管你是初始化生产集群还是临时建一套测试环境拉取同一个镜像出来的集群环境是一致的不会再出现“生产环境和测试环境行为不一致然后就崩了”的鬼故事。2.2 对比传统部署方案优势是“少”而不是“多”在选择技术方案之前最忌讳的就是盲目赶时髦。决定采用Sealos之前我们团队做了一个比较详细的对比在这里分享给你可以作为你们选型的参考。对比维度传统kubeadm手工部署Rancher/KubesphereSealos集群初始化复杂度高需要手工执行大量初始化命令中等界面引导但仍然要理解每项配置含义低单条命令完成部署组件一致性低各版本混装是家常便饭中受面板自身版本捆绑高镜像化统一管理升级难度高涉及证书、组件、参数兼容性中需要面板进行复杂版本升级低重新应用新版本镜像即可外围组件存储、网络、监控需要单独部署管理和调优一些厂商配套部分组件需单独内置并预调优对运维人员的要求需要精通底层原理需要掌握面板操作与底层原理需要了解基本原理但不要求精通所有细节注意我这里的结论不是说Sealos让运维人员不需要懂任何原理了。它减少的是踩坑的随机性而不是减少你理解系统的必要性。这非常关键。一个完全不懂etcd的人用Sealos虽然能拉起集群但遇到故障依然两眼一抹黑。所以它解决的是把大量“因为经验差异导致的偏差”消灭掉让问题能够稳定复现、稳定解决。2.3 一个特别打动我们的细节单机模式也有一致的体验很多中大型团队其实都有这样的尴尬需求开发环境或者临时压测环境不需要那么大的集群但线上生产又要按真实规模来。如果部署方式不一致开发和测试阶段根本复现不了生产环境的问题。Sealos通过镜像参数化的方式可以快速创建一个单节点集群作为开发环境但它的集群组件、网络方案、运行时跟生产环境的多节点集群完全一致。这让“开发环境能跑生产环境一定也能跑”这句以前是口号的东西第一次变成了比较靠谱的保障。3. 实操记录我是怎么用Sealos重建集群并稳定跑上生产的光说不练假把式。这一部分我会尽量详细地还原我们部署的完整流程包括命令细节、资源规划、高可用配置、以及日常运维的关键动作。如果你想直接参考落地这一章应该最有价值。3.1 部署前的资源规划按职责划分别混用K8s集群部署前最忌讳的是角色划分混乱。我们之前的旧集群node节点既跑业务Pod又跑集群监控和日志组件导致资源竞争业务高峰时Pod CPU被监控组件抢掉直接雪崩。资源规划看起来是件小事其实解决了大量潜在故障。我们这套Sealos集群的标准规划如下节点角色数量配置参考主要承担职责Master/Control Plane3台16C32G系统盘200G SSD运行etcd、apiserver、scheduler、controller-managerWorker/业务节点8台32C64G起系统盘与数据盘分离运行业务容器、中间件容器存储节点可选3台起32C64G大容量高性能盘提供分布式存储能力如果你需要Sealos内置的存储我们的经验是Master节点在资源满足要求的前提下不应部署繁重的业务负载。有人为了省钱在测试环境让Master兼任Worker角色这在测试环境还能忍生产环境这么干一旦遇到峰值流量apiserver和业务容器抢CPU整个集群调度都会变得极其不稳定。3.2 集群初始化从裸机到可用集群只用一套命令在新方案下集群初始化确实变得非常简单。准备一台干净的Linux服务器我们在生产环境用的是Rocky Linux 9内核和系统基础组件配置好之后直接执行类似以下指令取决于你选用Sealos版本的命令语法# 拉取对应版本的集群镜像 sealos pull labring/kubernetes:v1.29.0 # 针对多节点集群初始化第一个master节点 sealos run labring/kubernetes:v1.29.0 \ --masters 192.168.10.10,192.168.10.11,192.168.10.12 \ --nodes 192.168.11.10,192.168.11.11,192.168.11.12 \ --passwd your-secure-password这里稍微解释几个细节因为很多人第一次用的时候容易困惑--masters参数是控制面节点的IP列表写上三个IPSealos会自动把这3台机器组成一个高可用控制面内部的etcd集群和apiserver负载均衡会自动配置好。--nodes参数对应的就是要加入的业务节点IP列表。如果你用的是SSH密钥认证可以指定对应的私钥参数这样不用在命令行里直接写密码。执行完成之后Sealos会自动把环境检查、ssh通信、容器运行时安装、控制面初始化、节点加入、网络插件部署这一整套动作串联起来。整个过程快的话大概十来分钟就能得到一个多节点高可用集群。这个体验对我们这些曾经花三天手工部署的人心情是复杂且激动的。3.3 高可用细节证书与负载均衡怎么处理很多人关心多Master如何保证高可用。传统kubeadm方式下你需要自己配置外部负载均衡比如HAProxy/Nginx把API Server的请求分发到三个Master节点。Sealos内部对高可用的处理方式跟这个思路类似但自动化程度更高。需要注意的一个点是DNS和VIP虚拟IP的处理。如果你的自建机房环境有现成的负载均衡设备或者支持VIP可以配合使用。如果没有Sealos在初始化过程中也会帮你完成一套内置的负载均衡方案。实际使用中我们发现它会让kubelet和kubectl自动指向一个本地的LB地址从而规避单点故障。之前手工部署时最噩梦的就是证书管理初始化生成的CA证书、各组件证书、ServiceAccount密钥过期时间不同维护起来非常烦。Sealos在集群镜像中默认处理了证书自动轮换的问题这也让我们从“怕证书过期”的心理阴影中彻底走出来了。3.4 日常升级不再是“拆炸弹”在旧集群环境里我们最害怕的就是升级K8s版本生怕哪个组件升级后配置不兼容。基本上每次升级都要提前一个月做方案评审、预演、回滚计划结果还是经常出篓子。Sealos对升级的处理相对平滑。它的做法还是基于镜像机制拉取一个更高版本的集群镜像然后执行升级命令它会自动处理控制面和节点的滚动升级。我们在半年内顺利做过一次大版本升级整个升级过程中业务没有出现中断具体操作大致类似# 先拉取新版本镜像 sealos pull labring/kubernetes:v1.30.0 # 执行集群升级 sealos upgrade --cluster my-cluster当然我不是建议你就盲目相信升级一定零风险任何生产环境的升级都建议先在测试集群做一次完整演练再把方案搬到生产环境。但至少在操作复杂度上这个过程已经变成了“标准操作”不需要投入全部运维人力去搏一把。4. 稳定运行半年后我们如何做集群体检与故障预防故障率降下来不等于不用干运维的活了。相反我们的精力从“紧急救火”转向了“日常体检”和“容量规划”。以下这些检查项和方法是这半年来我们维护集群最核心的几个动作。4.1 把etcd健康检查排在第一位etcd是K8s的地基地基一出问题整栋楼都摇摇欲坠。我们的巡检脚本里第一项就是检查etcd集群的健康状态、空间使用率、碎片率和慢请求情况。相关命令并不复杂重要的是你要定期去看并设好告警阈值。我建议至少关注以下几个指标指标建议阈值为什么不安全etcd db大小总空间使用率低于70%超90%直接拒绝写入集群只读etcd leader切换次数一段时间内不频繁切换频繁切换说明网络不稳定或磁盘IO抖动apiserver请求成功率99.9%以上低于阈值说明控制面压力过大或组件故障节点NotReady状态0个出现则排查kubelet、容器运行时、网络4.2 监控告警让问题暴露在用户发现之前Sealos这套方案自带了一些监控组件集群部署完成后可以快速启动一个Dashboard和监控大盘。为方便快速查看节点的CPU、内存、网络和磁盘状态我们也保留并配置了Prometheus等监控工具链。这类工具的使用门槛不高但要记住一个关键点告警规则不能太多否则大家会麻木最终真的故障来临时反而没人响应。我们定义告警规则的筛选原则是只告警“影响业务可用性”和“可能导致数据丢失”的场景。比如kube-system命名空间下的Pod重启次数异常上升节点内存使用率持续超过85%且持续时间超过10分钟etcd请求成功率低于99%证书剩余有效期不足30天其他一些“毛刺”类的问题宁可让它默默记录到日志里也不要疯狂打扰值班的同学。4.3 备份与恢复演练是安全感真正的来源一个稳定的集群备份是底线。K8s的备份和传统数据库备份不太一样你不仅要考虑etcd里的元数据还要考虑持久化存储里的业务数据。我们在Sealos集群环境里最常做的备份动作就是周期性对etcd做快照并把快照文件同步到独立的备份存储机器上注意别放在同一个节点上。几乎每个季度我们都会做一次完整的恢复演练搭建一套全新的临时集群用etcd快照进行恢复验证关键业务能正常拉起。只有当你亲手做过一次恢复流程且成功之后你面对“集群挂了”这件事时才能真正心平气和而不是慌不择路。4.4 巡检checklist一套免费的“治未病”方案这块内容是我们团队每周五例行巡检时实际使用的分享出来可以直接用检查所有Master节点的/var/log/messages或者journalctl日志有没有持续刷新的异常信息。检查etcd空间使用率同时执行etcdctl defrag如果开启自动压缩和碎片整理周期。查看Kubernetes事件筛选Warning级别且频繁出现的事件特别是那些“Liveness probe failed”和“Back-off restarting failed container”。检查核心组件Pod副本数是否都符合预期特别是kube-proxy、coredns、calico或flannel这类基础组件。抽查业务Pod的调度分布是否均匀避免因为某个节点被打爆而引发连锁反应。检查证书有效期确认自动轮换机制正常执行。坚持半年做下来你会发现很多潜在故障苗头确实能在萌芽阶段被掐掉。5. 故障排查实录那些依然可能出现的问题与快速定位思路虽然号称“故障率降到0”这里我想特别说明一下0是指没有因为运维操作失误或者基础设施不确定性导致的重大故障。但这不意味着集群永远不会出任何波浪。以下记录一些我们切换后依然会遇到的典型情况以及排查思路供大家参考。5.1 问题某业务Pod频繁重启整个节点负载升高有一次线上突然出现一批Pod反复重启现象表现为容器启动后很快被kill然后重新调度。我们通过监控发现原因是Pod的内存Limit设置过小而业务流量突增后内存占用超限。这个跟Sealos本身没关系纯属资源配额不合理。我们用的小技巧是给业务方一个资源画像工具让每个团队定期查看自己服务的基础资源消耗及时调整资源配置。这个过程中最大的启发是K8s集群的故障往往最后都追溯为“人的问题”。要么是应用配置不合理要么是资源预估不足。平台的职责是给你一个清晰的视图去发现这些东西而不是替你杜绝它们。5.2 问题节点组成“僵死”kubelet挂着但业务不通有一次某个业务节点虽然kubelet进程还活着但已经无法创建新Pod旧Pod也不断报网络异常。我们排查的路径查看kubelet日志没有明显的panic或者报错。再检查容器运行时发现是containerd的存储驱动出现了磁盘空间不足的状况。因为K8s的镜像拉取都需要宿主机存储支撑数据盘满了之后新Pod的镜像拉取直接失败。快速处理的中间步骤是找到并清理废弃的镜像和悬空的日志文件再把监控大盘的磁盘预警收紧了避免再发生类似默默饿死的场景。5.3 问题有人误删了Ingress或ServiceK8s集群人一多权限管理不到位就很容易出事故。比如某团队同学误删了一个全局共享的Ingress配置导致下游服务瞬间不可访问。Sealos默认是基于Kubernetes标准对象做管理所以如果你集群内接入了多个团队建议一定要配置好RBAC权限隔离。权限最小化是集群生产环境的第一安全底线。当然这类误操作可以通过开启审计日志、或者启用回收站类组件去缓解但最核心的永远是流程和权限工具只能辅助。5.4 常见问题速查表异常表现优先排查方向快速处理建议新建Pod一直Pending节点资源不足 / 存储或网络插件问题查看kubectl describe pod事件排查调度器日志控制面组件频繁重启apiserver负载 / etcd性能检查etcd磁盘IO、慢请求、内存占用Node状态NotReady容器运行时异常 / CPU抢占重启containerd/kubelet检查系统负载网络不通或DNS异常CNI配置 / CoreDNS副本重启相应组件检查iptables规则与网络插件集群突然只读etcd空间不足清理etcd数据目录、执行压缩与碎片整理写在最后从“人肉抗灾”到“秩序化运维”这半年我最大的体会很多朋友看到“故障率从月均8次降到0”这个结果第一反应都是“Sealos是不是特别牛的神器能解决所有问题”。其实我更愿意把它看成一种“运维范式”的切换。过去我们把大量的精力花在不停修补“环境差异”和“配置偏差”上根本没有多少余力去关注真正的系统架构、容量演进和业务稳定而当底层环境变成了一套可复现的、标准化的镜像之后我们才终于腾出手来去把那些真正影响稳定性的问题系统化地解决掉。从团队的实际变化来说大家最大的感受是运维终于不再需要“英雄”了。以前每次出大故障总需要有一个资深工程师临危不乱从一堆日志里面找到蛛丝马迹靠直觉和运气挽救集群。而环境标准化之后任何一个合格的工程师照着手册和监控就能完成大部分日常维护与快速恢复团队整体的应对水平被拉齐了。这种“安全感”比任何财务上的指标都更让人踏实。如果你也想迁移到Sealos我个人建议不要一上来就动生产先拿测试集群跑一个月把该踩的坑踩掉再逐步扩大范围。另外不同版本的SealOS命令和配置方式可能会随着时间迭代建议以官方最新文档为准。这套做法的核心思想其实是值得参考的让基础设施向软件资产一样去版本化、可复现、可演进而不要把它当作永远需要人肉呵护的脆弱装置。最后再分享一个小细节我们之前做“周五下午不敢上线新版本”现在虽然还是会有变更但心态完全不一样了。因为环境的可预测性变高了变更的风险变低了遇到问题我们能够迅速定位和回滚。有时候想想真正的技术安全感不是你有多精通底层而是你知道出了问题之后一定有条路能走出来Sealos帮我们打通了这条路剩下的还是需要我们珍惜这段来之不易的稳定期把业务打磨得更好。
