李科燃的主页

莱斯利·兰波特有一句话被反复引用：”If you’re thinking without writing, you only think you’re thinking.” 这句话的重量，我在管理开源社区和 AI 基础设施项目的过程中，感受越来越深。 我见过很多工程师，代码写得非常好，方案设计得相当精妙，但一旦要把想法落成文字，就开始模糊、绕圈、或者干脆写不下去。这不是表达能力的问题，而是思考还

“你们用 Kubernetes 了吗？” “用了，我们所有服务都容器化了，用 Helm 管理部署。” “那你们的 Operator 或者 Controller 写了多少？” “……那个还没有。” 这段对话在很多团队里都发生过。工具换了，但运维的思路没换。这是传统自动化运维和云原生运维之间最根本的裂缝——不在技术栈层面，在控制权模型层面。 传统自动化运维的本质：人是最终控制器传统自动化运维的核心是

胡适在给毕业生的文章里写过：”功不唐捐。没有一点努力是会白白丢了的。” 这句话在 gap 期的第三个月，开始有了具体的重量。 今年花了将近十个月找工作。这段时间并不是想象中的”充电”或”沉淀”，更多时候是一种低烈度的焦虑：不知道哪个投出去的简历会有回音，不知道这段空白时间算是在认真准备还是在逃避。 在这期间，我系统地读了 Kubernetes 的源码，搞清楚了控制循环的设计逻辑，理解了为什么声明

声明式和命令式的区别，每篇云原生入门文章都会讲。但大多数解释停留在”你描述目标，系统决定过程”这个层面，然后举个 SQL 的例子，结束。 这个解释并没有错，只是它遮蔽了更重要的工程含义。 本质差异不在语法，在谁持有状态命令式的核心假设：调用方知道当前状态，知道如何从 A 到 B。 123kubectl scale deployment my-app --replicas=5kubectl set

接着第二篇 GVR 数据结构的话题往下走。搞清楚 Kubernetes 怎么在内部表示资源之后，自然会有一个问题：它到底内置了哪些资源，这些资源是怎么组织的，设计边界在哪？ 这篇是读书过程中整理的”内置资源全图”，但我想绕过那种把所有资源逐一列出来的写法。知道 Deployment 管无状态、StatefulSet 管有状态，这种结论每个 K8s 入门文章都有。我更感兴趣的是：这张”全图”背后的分

Group、Version、Resource核心数据结构在整个Kubernetes体系架构中，资源是Kubernetes最重要的概念，可以说Kubernetes的生态系统都围绕着资源运作。Kubernetes系统虽然有相当复杂和众多的功能，但它本质上是一个资源控制系统——注册、管理、调度资源并维护资源的状态。 在Kubernetes庞大而复杂的系统中，只有资源是远远不够的，Kubernetes将资

《Kubernetes 源码剖析》不是一本适合新手的书。它默认你已经会用 K8s，然后带你去看”这些东西为什么这样设计”。读完第一章，我意识到那些我以为自己理解的东西，其实只是停留在 API 层面——我知道怎么写 YAML，但不知道为什么这样写是对的。 真正有价值的，是理解 Kubernetes 的架构模式。这个模式已经远超容器编排这个应用场景本身。 一个本质性的设计决策Kubernetes 的

一个服务上了 Kubernetes，不代表它是”云原生的”。Kubernetes 会尽力调度、重启、扩容你的服务，但它对你的代码有一份隐性的期望清单——不写进文档，但违反了就会出问题。 这份清单里的大多数条目，开发者在本地开发时不会遇到，只有在生产环境里才会被打脸。 SIGTERM 契约：优雅退出不是可选项Kubernetes 停止一个 Pod 时，会先发 SIGTERM 信号，给进程一段时间（

大多数 Kubernetes 入门文章会把 Pod 启动过程讲成一个线性的编号列表：API Server 接收请求 → Scheduler 选节点 → kubelet 拉镜像 → 容器启动。 这个描述没有错，但它掩盖了真正重要的东西：这个过程根本不是线性的，它是多个独立控制循环并发协作的结果，而且每个环节都有自己独特的失败模式。 控制循环，不是调用链理解 Pod 启动的关键，是先放弃”请求-响应

这篇文章的动机很简单：DNSPod 对已备案域名的解析做了限制，导致我无法把域名解析到境外的静态托管服务。绕开它的最直接方式，是把 nameserver 切到 Cloudflare，让 CF 接管整个 DNS 层。 这是一次被动迁移，但结果比预期要好。 问题背景我的博客是 Hexo 静态站，之前托管在国内的云服务商上。域名在腾讯云注册，DNS 解析用 DNSPod。一切都跑得挺稳定。 问题出现在