智汇 IT
城启新篇

Kubernetes 真正贵的那部分没写进文档

凌晨两点,值班的人盯着 kubectl get pods -A 的输出。一屏绿,只有两个 CrashLoopBackOff。业务是好的,集群是好的,就那两个 Pod 在循环重启。

这种画面我看过太多次。它比任何发布会都更接近 Kubernetes 的日常。

声明式换来的,是责任换了个地方待着

Kubernetes 的核心其实很小:etcd 存期望状态,几个控制器不停地比对实际状态和期望状态,不一致就动手。就这么个循环,朴素得像个 while(true)。

Kubernetes控制器reconcile循环比对期望状态示意图
Kubernetes控制器reconcile循环比对期望状态示意图

但正因为它朴素,原来写在运维脑子里、写在一堆 shell 脚本里的“如果这样就这么干”,全被搬进了代码。搬出来是好事,代价是——它得有人写,还得有人读得懂。

命令式脚本的好处在于,出问题你能顺着那几十行读下去,读懂了就懂了。声明式系统一旦漏了一层抽象,你就得同时理解 YAML、准入链、控制器实现、调度器打分。这是一条塌方式的排查路径。

说实话,很多人骂 YAML,骂的不是格式。是那种“我写的和我看到的不是一回事”的失控感。

那些没人负责的中间层

一个中等规模的研发团队,从头到尾数一遍自己集群里有什么:Helm chart 三百个,Kustomize overlay 两套,Operator 十几个,CRD 二三十种,还有若干“临时”留在那里三年没人敢删的 Namespace。

这事挺荒诞的。Kubernetes 本来是想给你一个统一的接口,最后大家各自在上面盖了一层自己的 PaaS。每盖一层,后来的人就少懂一点。

平台工程的兴起,很大程度就是在收拾这个摊子。有人把 chart 收起来,做内部门户、做模板、做默认值。这活儿有价值。但它不是纯技术问题——它要求有人有权说“你不能这么写”。多数团队没有这个人。

麻烦在于,集群不会因为你没人管就停止变化。API 版本会 deprecate,Ingress 要往 Gateway API 挪,PSP 早就没了,PodSecurity 接上。你垒的每一层,都在等着一个升级窗口。

Kubernetes控制平面etcd与apiserver组件架构图
Kubernetes控制平面etcd与apiserver组件架构图

升级这件事从来不在发布会上

升级这件事从来不在发布会上
升级这件事从来不在发布会上

社区一年发三个小版本,支持的窗口大概覆盖最近三个。听着合理。落在实际里就是:你今天升不升,明年都得升,中间隔着若干 breaking change。

跳着升会被劝退。稳妥做法是一个版本一个版本来,升完观察一轮。这意味着一年里有相当一部分精力被固定消耗在“保持不掉队”上。这事没有尽头,也不产生任何面向用户的功能。

有状态服务更难。etcd 的备份、恢复演练、快照体量、磁盘 IO——顺利的时候全是隐形的,出事的时候全是头条。我见过最耗人的活不是写控制器,是写灾备演练的 runbook,写完还得真跑一遍。跑完发现问题,还得改,再跑。

代价就在这:Kubernetes 把扩展性做得很好,把“稳定地待在一个版本上”做得一般。它默认你在持续移动。

账单是会说话的

资源 request 和 limit 这两行,看着只是配置。

Kubernetes Pod资源配置request与limit的yaml文件截图
Kubernetes Pod资源配置request与limit的yaml文件截图

实际上它们决定了整个集群的装箱效率。request 写大了,一个节点装不下几个 Pod,扩容扩得勤,钱花在空转上;写小了,节点超卖,晚高峰互相抢 CPU,延迟毛刺满天飞。

不少团队一开始凭感觉写,统一给 500m。半年后回头看,真实使用率两成不到。这不是谁的错,是没人告诉过他们 request 是调度承诺,不是“我用多少”。

后来又冒出 VPA、HPA、KEDA、各种自动伸缩。工具都好,但那都是对着一开始没想清楚的账在打补丁。节点池、拓扑分布、亲和性、Spot 混部——每一项都能省钱,每一项都得有人懂。省钱和省心在这件事上经常是反的。

什么时候干脆别上

这话不太受欢迎,但该说。

三五个服务,一天几百个请求,团队三四个人。这个规模上 Kubernetes,你获得的是一套需要长期供养的系统,和一堆本来不存在的概念。

虚拟机加 systemd 加一套朴实的部署脚本,能扛很久。真到了要频繁扩缩、多环境、多团队抢资源的时候再迁,也不迟。那次迁移是疼,但比从第一天就开始养集群,疼得值。

另一类是强状态、强 IO 的场景。数据库、消息中间件,跑在 Kubernetes 上比裸金属好吗?看情况,也看谁在运维。StatefulSet 给了个秩序,可延迟这东西不吃秩序。

那它到底解决了什么

那它到底解决了什么
那它到底解决了什么

我的看法是,Kubernetes 最大的贡献是把“我怎么把一个东西部署起来”变成了跨云、跨团队的共同词汇。Deployment、Service、Ingress、ConfigMap,这些词现在到哪儿都通。换个云,人的经验能带走。这事放在十年前是不可想象的。

这个价值是真的,也是它能活下来的原因。

但它不免费。你付出去的那部分,是持续的注意力:版本要跟、YAML 要收、账要算、抽象层要有人守着。省下来的运维人力,多半转成了平台工程的岗位,而不是凭空消失。

凌晨那俩 CrashLoopBackOff,最后查出来是一个 ConfigMap 热更新之后应用没重载。这事跟 Kubernetes 无关,又跟它有关——它给了你热更新的能力,也顺手给了你忘记重启的机会。

免责声明:市场有风险,选择需谨慎!此文仅供参考,不作买卖依据。如有侵权请联系删除。
文章名称:Kubernetes 真正贵的那部分没写进文档
文章链接:https://m.itcdj.com/news/795.html