读《Kubernetes 源码剖析》笔记三：内置资源全图背后的分层逻辑
接着第二篇 GVR 数据结构的话题往下走。搞清楚 Kubernetes 怎么在内部表示资源之后，自然会有一个问题：它到底内置了哪些资源，这些资源是怎么组织的，设计边界在哪？
这篇是读书过程中整理的”内置资源全图”，但我想绕过那种把所有资源逐一列出来的写法。知道 Deployment 管无状态、StatefulSet 管有状态，这种结论每个 K8s 入门文章都有。我更感兴趣的是：这张”全图”背后的分层逻辑是什么，以及它为什么要这么设计。
资源不是功能，是控制意图的投影
看 Kubernetes 的内置资源，很容易陷入一个思维定式：把它们当成”功能模块”来理解，部署用 Deployment，任务用 Job，存储用 PV/PVC……
但这个理解是错的，或者说是不够的。
Kubernetes 的资源，本质上是对控制意图的类型化表达。每一种资源背后，都对应着一个控制器的期望语义——而不是一个具体的操作。当你写下 replicas: 3，你没有告诉 K8s 去启动三个容器；你是在声明一个意图，然后等 Deployment Controller 去实现它。
这个区别很重要。因为它意味着：资源的设计边界，本质上是控制器职责的边界。理解资源分层，就是在理解 Kubernetes 认为哪些控制关注点值得单独抽象。
三层分法比”大全”更有用
书里给出的内置资源全图，如果展平来看会让人眼花。我自己整理时发现，按”控制关注点”来分三层，更有助于建立直觉：
第一层：工作负载层
Pod 是最小单位，但 Pod 本身是脆弱的——它死了就死了，没人管它。所以有了 Deployment（无状态，关注副本数）、StatefulSet（有状态，关注身份稳定）、DaemonSet（节点覆盖，关注全局分布）、Job/CronJob（关注任务完成语义而非存活）。
每种资源回答的问题不同：这个负载死了之后，谁来、如何、在哪里把它拉起来？ 不同的业务语义对应不同的答案，所以有不同的资源类型。
第二层：基础设施绑定层
这一层解决的是工作负载与底层资源的绑定问题：网络（Service、Ingress）、存储（PV/PVC/StorageClass）、配置（ConfigMap/Secret）。
有趣的是，这一层的资源大多不是控制执行的主体，而是描述”绑定关系”的契约。PVC 不决定存储怎么供给，它只表达”我要这样规格的存储”；Service 不决定流量怎么路由，它只声明”这些 Pod 应该在这个端点后面”。真正的执行在各个 Controller 和 CNI/CSI 插件里。
第三层：治理层
Namespace、RBAC（Role/ClusterRole/RoleBinding）、NetworkPolicy、ServiceAccount——这一层的资源不直接管应用，管的是谁有权做什么、在哪个范围内做。
治理层是最容易被忽视的。很多团队到了生产出问题才意识到，RBAC 的粒度设计和命名空间规划，对多租户系统的稳定性影响远超应用配置。
CRD 是边界，不是补丁
内置资源全图读下来，有一个结论让我印象深：Kubernetes 的内置资源并没有试图覆盖所有场景。它设计了一条明确的扩展路径：CRD（Custom Resource Definition）。
内置资源解决的是通用场景；CRD 解决的是”你的业务需要一个新的控制关注点”。这不是设计缺陷，是刻意的边界。
实际工作中，我们在 AI 基础设施场景下写过几个 Custom Resource，用来描述推理服务的扩缩容策略和 GPU 亲和性声明。这些场景用 Deployment + 各种 Annotation 堆出来当然也能用，但一旦抽象成 CRD + 对应 Operator，控制逻辑就干净了很多——因为资源类型本身就在表达业务意图，而不是靠 Annotation key 来猜。
这大概就是 Kubernetes 资源模型最核心的工程价值：它让你可以在同一套控制架构下，用相同的声明式语义表达任意复杂度的业务控制逻辑。内置资源是起点，不是终点。
一个简单但有用的判断框架
读完这章，我自己沉淀了一个判断框架，用来决定什么时候该用内置资源、什么时候该考虑 CRD：
- 如果你的需求可以用内置资源 + 合理配置表达清楚，就不要引入 CRD。运维复杂度实打实的。
- 如果你在代码里或者 CI 流水线里，频繁地用 Annotation / Label 来传递本该在资源定义里表达的业务语义，说明是时候抽象了。
- 如果你的控制逻辑变成了”watch 某个 ConfigMap 然后触发一堆副作用”，大概率是在绕过应该用资源来建模的问题。
Kubernetes 的内置资源全图，不是要背下来的知识点，是用来校准直觉的参照系。