云原生不是上云，是重构网络基因的三步跃迁

　　去年七月份，我在客户机房盯备案变更的最后一步，空调出风口正对着我后颈，吹得人发僵。备案表刚提交十秒，监控钉钉弹出告警：主站域名 DNS 解析失败——不是超时，是根本没返回 A 记录。我摸出手机查了三遍，确认没输错域名，也确认自己没点错“回滚”按钮。

　　我原以为只是 NS 服务器缓存延迟，等二十来分钟就好。结果三十八分钟后，运维小张冲进来，工牌绳子上挂着半截断掉的挂绳扣，说：“李工，云DNS控制台里那个 zone，删不掉。”

　　我说“不可能”，他调出后台截图给我看：zone 名字底下灰着一行字，“状态：pending_destroy”，后面跟着一个转圈图标，第七次点击“强制终止”后，图标还是转。我让他清浏览器缓存重登，他照做了；我让他换 Chrome 登，他换了；我让他用客户提供的堡垒机 SSH 连到 DNS 节点查 etcd，查出来 key 确实还在，但 get 返回的 revision 是空的。他敲完命令抬头看我，嘴唇动了动，没出声。那会儿我后颈的冷汗突然下去了，换成一股干热往上顶。

　　这时候客户方的架构师老陈端着保温杯踱过来，杯沿还沾着一点枸杞渣，说：“你们这个‘云原生 DNS’，是真把 bind 配置文件藏进 operator 里了吧？我刚才翻了下你们交付文档，第十二页写‘自动收敛解析拓扑’，可我没看见哪一行写了‘手动回滚路径’。”

　　他没看我，盯着屏幕右下角跳动的时间戳。我点了下鼠标右键想关掉终端窗口，结果误触了旁边的 Dock 上一个叫“ConfigMap Snapshot”的小工具——那玩意儿是我们自己写的，去年五月上线后就没再维护过，图标还是蓝色圆角矩形，底下一行小字“v0.2.1”。

　　我也不知道它怎么还在那儿。

　　老陈又补了一句：“你昨天邮件说‘容器化即云原生’，这话我现在当面驳回。”

　　我点头，手指悬在键盘上没动。其实我根本没发过那封邮件——是实习生代发的，漏抄了我，标题写的是《关于 DNS 模块迁移至 Kubernetes 的阶段性同步》，正文里混进了两段从某云厂商 PPT 抄来的术语。我压根没审。

　　可现在，zone 删不掉，A 记录不回来，CDN 回源全 502，而最要命的是，客户刚刚把这条“pending_destroy”的状态截图发给了他们集团信息部——附言只有一行：“这就是你们说的‘弹性伸缩’？”

　　八分钟后，我蹲在机柜侧面扯出一根绿色光纤线，发现接口上沾着一小块黑色胶布，边角卷起来了。那是上周五下午粘的，因为光电模块温度告警太频，临时贴了层散热胶布，结果贴反了方向——本该朝外散热的那一面，被我糊死了。这事儿跟 DNS 没一毛钱关系，但我盯着那卷边看了足足十四秒，才松手让它落回地板上。

　　我其实直到现在也没搞懂，那个 pending_destroy 状态到底卡在 operator controller 里，还是卡在 etcd 的 watcher 队列里，还是……压根就是某个 CRD schema 更新时，校验逻辑漏判了一个 nil 指针。反正最后是运维小张把节点上的 kube-controller-manager 服务 restart 了三次，中间穿插了一次 configmap 强制 delete —— 第八次操作后，zone 列表里那条记录终于灰掉了，三秒后彻底消失。

　　然后 A 记录就回来了。

　　没有 rollup，没有 rollback log，没有 trace ID 可查。就像什么都没发生过。除了那块胶布，还歪在光纤接口上。

文章配图，仅供参考

　　我原以为云原生是把服务打包扔上 Kubernetes 就算数。结果发现不是——它是把你的配置习惯、排障肌肉记忆、甚至手抖频率，全打碎了，塞进 Operator 的 reconcile 循环里，由一套你不熟的错误处理机制重新筛一遍。优胜劣汰？对，但被淘汰的常常不是代码，是你十年前在 IDC 里练出来的直觉。

　　有谁碰到过这个吗

（编辑：航空爱好网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!