又是 PagerDuty 的铃声。
手机屏幕显示 3:17 AM，告警内容是 Kubernetes 节点内存压力导致 Pod 驱逐。我盯着天花板发呆了三秒——这周第四次了。
爬起来开电脑，SSH 进去排查，发现是某个服务内存泄漏，之前设置的 resource limits 太保守。处理完已经快五点，睡是睡不着了。
这不是个例。过去两年，我们团队维护着一套"标准"的 K8s 基础设施：三个云厂商、十几个集群、各种自建组件。每次有人问"你们 DevOps 团队几个人"，我都不好意思说——运维人头成本已经超过云资源成本了。
从"管集群"到"不管集群"的转变
传统的 Kubernetes 运维模式有个根本性矛盾：K8s 是为了简化应用部署而生的，但它本身的运维复杂度却在不断膨胀。
你需要操心：
-
控制平面高可用
-
etcd 备份恢复
-
证书轮换
-
CNI 网络插件选型和故障排查
-
存储卷供应
-
监控告警体系搭建
-
日志收集
-
安全加固
-
版本升级……
这些东西，每一项都能写本书。
Sealos 的解法很直接：把 Kubernetes 当操作系统内核用，上层只暴露应用层抽象。你不需要知道进程调度器怎么实现的，只需要会启动程序。同样，你也不需要知道 Pod 怎么调度的，只需要会部署应用。
企业级使用的实际操作路径
上个月我们把一个业务线迁移到 Sealos，主要动机是那边的 SRE 离职了，没人接手那套"祖传"集群。
迁移过程比预想的简单。核心步骤就三个：
第一步：在 Sealos Cloud 上创建工作空间，把团队成员拉进来。权限体系是原生的，不需要额外搭建 RBAC。
第二步：通过应用商店一键部署基础组件——数据库、缓存、消息队列这些。以前我们自己维护 MySQL 主从，光处理主从同步延迟的告警就够喝一壶。现在直接用数据库服务，SLA 是平台的事。
第三步：业务容器走标准的镜像部署流程，配置好环境变量和存储卷挂载即可。
整个过程没碰过 kubectl，没写过 YAML（除了迁移时参考旧配置）。
那些不再需要处理的告警
迁移一个月后，我统计了一下这个业务线的告警情况：
-
节点 NotReady：0 次（以前平均每周 2 次）
-
Pod OOMKilled：3 次（以前平均每周 7 次，现在的都是代码问题）
-
证书过期警告：0 次
-
存储卷挂载失败：0 次
不是告警被静默了，是底层基础设施的问题被平台吸收了。
成本账怎么算
企业级使用绕不开成本。简单算一笔账：
旧模式（自建 K8s）：
-
3 个 SRE 年薪成本 ≈ 180 万
-
云资源（冗余设计导致利用率低）≈ 96 万/年
-
故障导致的隐性损失：难以量化
新模式（Sealos）：
-
平台费用按实际使用量计费
-
SRE 团队缩减到 1 人（主要做架构和应急）
-
资源利用率提升（弹性伸缩真的生效了）
具体数字因业务规模而异，但方向是明确的：把复杂度转移给专业平台，自己只关注业务代码。
最近几周，凌晨三点的告警少了很多。偶尔还是会醒——习惯了。但打开手机，发现没有未读消息时，那种感觉挺好的。
基础设施这东西，最好的状态就是让人忘记它的存在。
