对象

Annotation 为 Kubernetes 对象附加非识别性元数据，可以记录来源、负责人说明，或供工具消费的配置。标准标签选择器不会按 annotation 值筛选对象，但这并不意味着 annotation 没有作用。控制器、准入组件或发布工具都可能解释约定的键并改变行为。判断元数据修改的影响之前，应先确认具体消费者，不能仅凭字段名称认定它只是无害备注。 不参与选择，不等于没有校验 Annotation 的键和值都必须是字符串。键遵循限定名称格式，可以包含可选的 DNS 风格前缀和名称部分；一个对象的 annotation 键和值合计大小不能超过 256 KiB。因此，它不是不受限制的任意类型 JSON 存储。如果某个工具把 JSON 序列化后放进字符串，额外的格式与解释规则仍然由这个工具负责，而不是自动成为 Kubernetes 的通用语义。 自动化写入的键应使用负责组织控制的前缀。普通负责人说明与某个控制器专用参数，即使都位于同一张映射中，也具有不同含义。应记录哪个组件负责写入、哪个组件负责读取每个操作性键。来自另一种控制器、看起来很熟悉的 annotation，不能在没有核对契约时就当作可移植配置使用。 标签与 annotation 的选择角色也不同。标准选择器可以匹配标签表达式，而描述性的 annotation 通常需要另外读取和解释。这不意味着每一个任意标签都拥有专门存储索引，更不意味着 annotation 无法影响协调过程。字段选择应依据消费者的 API，而不是机械遵循“机器只读标签、人只读备注”的错误分工。 坏掉的样子 字段所在的位置会改变效果。修改 Deployment 顶层 metadata，与修改 spec.template 里面的 metadata，是不同操作。即使容器镜像和选择器标签没有改变，Pod 模板变化仍可能触发滚动更新。反过来，只写在 Deployment 对象上的 annotation，也不会自动变成 Pod 模板里的变化。审阅补丁时应明确完整字段路径，不能只比较键名。 ...