Kubernetes中为何PATCH自定义资源/status子资源会触发父资源变更

这是Kubernetes的完全预期行为，你的CRD配置、PATCH/PUT操作方式都不存在任何问题。

子资源的存储本质 #

Kubernetes的/status等子资源并非独立存储的API实体，仅为父自定义资源提供的特殊访问端点：

• 所有对/status端点的写操作，最终都会将修改后的status字段内容合并回父CRD的完整对象实例中，存储到etcd的同一个对象key下
• 对象的metadata.resourceVersion是全局版本标识，只要etcd中存储的对象任意字段发生变更（包括status、metadata.managedFields、注释等非核心业务字段），该值就会全局递增
• Watch机制的事件触发源是etcd中对应对象key的实际值变更，不存在字段级别的事件拆分：只要对象的resourceVersion变化，所有监听该对象的客户端都会收到对应的MODIFIED事件，和变更的字段位置无关

观察结果的合理性验证 #

从你抓取的MODIFIED事件输出可以验证所有行为完全符合设计：

• 父资源的spec.message字段无任何改动，始终保持初始设置的Hi there!，不存在spec被意外修改的情况
• 事件中实际发生的变更仅两部分：
  • 新增status.ready: true字段值
  • metadata.managedFields中新增了curl操作对应的字段管理记录
• metadata.generation值始终保持为1，没有发生递增——这正是Kubernetes对子资源写操作的设计约定：只有spec字段发生变更时，才会全局递增generation值，status字段的变更不会触发generation更新

子资源隔离的实际生效效果 #

你在CRD中配置的subresources.status: {}已经正确生效，它的实际作用是实现写权限的拆分：

• 拦截所有对父资源根路径的写请求，强制忽略请求中提交的status字段，只有通过/status端点发起的写请求，才能实际修改对象的status段
• 这种隔离仅作用于写操作的权限校验，不会拆分watch事件的分发逻辑，不存在“子资源变更不触发父资源事件”的设计

常见认知误区 #

很多开发者会误以为子资源是独立的API实体，会产生独立的事件流，实际上不管是内置的/status、/scale子资源，还是CRD自定义的其他子资源，所有写操作最终都会落地到父对象的整体状态上，必然触发父对象层级的watch事件。
如果需要在watch逻辑中区分“业务spec变更”和“状态类更新”，无需依赖特殊的事件类型，仅需在收到MODIFIED事件时做两个判断即可：

• 对比新旧对象的metadata.generation值，如果值发生变化，说明spec字段存在变更
• 对比新旧对象的spec字段内容，确认是否是业务逻辑关心的spec调整
• 其余未改变spec的MODIFIED事件，均为status、元数据辅助字段（如managedFields、资源版本）的常规更新

内容的提问来源于stack exchange，提问作者Brian Warsing