生活
放下手机，回归真实
放下手机，回归真实 一、原作者的观点 原作者（微博suelence）通过自己的经历，深刻地揭示了手机对人们生活的影响。她指出： 1. 手机让我们逃避现实：在无聊的时候拿起手机，因为我们失去了观察世界的乐趣和能力。 2. 手机让我们失去感知力：太久的虚拟生活，让长着五官手脚的我们，活得越来越没有感受力
想法
关于写作
莱斯利·兰波特有一句话被反复引用："If you're thinking without writing, you only think you're thinking." 这句话的重量，我在管理开源社区和 AI 基础设施项目的过程中，感受越来越深。 --- 我见过很多工程师，代码写得非常好，方案设
云原生
云原生运维与传统自动化运维：本质不是工具，是控制权在谁手里
"你们用 Kubernetes 了吗？" "用了，我们所有服务都容器化了，用 Helm 管理部署。" "那你们的 Operator 或者 Controller 写了多少？" "……那个还没有。" 这段对话在很多团队里都发生过。工具换了，但运维的思路没换。这是传统自动化运维和云原生运维之间最根本的裂缝
想法
功不唐捐
胡适在给毕业生的文章里写过："功不唐捐。没有一点努力是会白白丢了的。" 这句话在 gap 期的第三个月，开始有了具体的重量。 --- 今年花了将近十个月找工作。这段时间并不是想象中的"充电"或"沉淀"，更多时候是一种低烈度的焦虑：不知道哪个投出去的简历会有回音，不知道这段空白时间算是在认真准备还是在
云原生
声明式与命令式：一个被讲烂的概念，以及它真正重要的地方
声明式和命令式的区别，每篇云原生入门文章都会讲。但大多数解释停留在"你描述目标，系统决定过程"这个层面，然后举个 SQL 的例子，结束。 这个解释并没有错，只是它遮蔽了更重要的工程含义。 --- 本质差异不在语法，在谁持有状态 命令式的核心假设：调用方知道当前状态，知道如何从 A 到 B。 bash
云原生
读《Kubernetes 源码剖析》笔记三：内置资源全图背后的分层逻辑
接着第二篇 GVR 数据结构的话题往下走。搞清楚 Kubernetes 怎么在内部表示资源之后，自然会有一个问题：它到底内置了哪些资源，这些资源是怎么组织的，设计边界在哪？ 这篇是读书过程中整理的"内置资源全图"，但我想绕过那种把所有资源逐一列出来的写法。知道 Deployment 管无状态、Sta
云原生
读书笔记-kubernetes源码剖析-2-数据结构
Group、Version、Resource核心数据结构 在整个Kubernetes体系架构中，资源是Kubernetes最重要的概念，可以说Kubernetes的生态系统都围绕着资源运作。Kubernetes系统虽然有相当复杂和众多的功能，但它本质上是一个资源控制系统——注册、管理、调度资源并维护
云原生
读《Kubernetes 源码剖析》：控制循环才是真正的架构遗产
《Kubernetes 源码剖析》不是一本适合新手的书。它默认你已经会用 K8s，然后带你去看"这些东西为什么这样设计"。读完第一章，我意识到那些我以为自己理解的东西，其实只是停留在 API 层面——我知道怎么写 YAML，但不知道为什么这样写是对的。 真正有价值的，是理解 Kubernetes 的
云原生
云原生给开发者立的隐性规矩
一个服务上了 Kubernetes，不代表它是"云原生的"。Kubernetes 会尽力调度、重启、扩容你的服务，但它对你的代码有一份隐性的期望清单——不写进文档，但违反了就会出问题。 这份清单里的大多数条目，开发者在本地开发时不会遇到，只有在生产环境里才会被打脸。 --- SIGTERM 契约：优
云原生
Pod 启动过程：从 kubectl apply 到容器就绪
大多数 Kubernetes 入门文章会把 Pod 启动过程讲成一个线性的编号列表：API Server 接收请求 → Scheduler 选节点 → kubelet 拉镜像 → 容器启动。 这个描述没有错，但它掩盖了真正重要的东西：这个过程根本不是线性的，它是多个独立控制循环并发协作的结果，而且每