共 4 篇
从 Java 转过来的人打开 kubernetes 源码，第一反应是找 controller、service、dao——看到的却是 cmd、pkg、staging。顺着这个困惑往下追：这三个目录各是什么来历，为什么 etcd 连 cmd 和 internal 都没有，k8s 的 controller 为什么不是那个 controller，multica 又怎么长回了 handler/service/db 三层，prometheus 为什么连 service 层的生态位都没有。
Kubernetes 的 CRD 里有一行 self.minReplicas <= self.replicas，Google Cloud 的 IAM 条件、Envoy 的 RBAC 里也是同一种写法。它叫 CEL。我们从一个普通需求出发：让用户在平台里自己写放行规则。嵌入脚本语言会碰到能调用什么、会不会停、写错了何时知道、每次多慢四个问题；CEL 用非图灵完备、类型检查和成本估算回答它们。再把 CEL 和 expr、Rego、Cedar、JsonLogic、Starlark、Lua、SpEL 等 22 个同类实现放进同一组场景实测，最后整理出在 Go 里用好 CEL 的做法。
Agent Substrate 的演示里，约 250 个有状态的智能体跑在 8 个 Pod 上。顺着这个数字往下追：它管的 actor 是什么、平时在哪，模板里的镜像怎么跑在 gVisor 上、和 E2B 的构建有什么不同，一个请求怎么把它叫醒，一个要跑几天的智能体，状态靠什么保住、什么时候会丢，它为什么装在 Kubernetes 上却不让 Kubernetes 管 actor，又和同样靠快照起沙箱的 E2B 差在哪里。
一份普通的 Dockerfile 原封不动就能变成 E2B 沙箱，可 E2B 又说每个沙箱是一台 Firecracker 虚拟机。顺着这份 Dockerfile 往下追：为什么不直接用容器，镜像进了 E2B 之后变成了什么，虚拟机怎么启动得和容器一样快，它创建沙箱和 Kubernetes 创建 Pod 有什么不同、又怎么跑在 Kubernetes 上，最后反过来看沙箱里怎么跑 Docker。