元数据

扩展属性在普通文件内容流之外，为文件系统对象附加有名字的字节值。应用可以使用 user 命名空间存放小型元数据，其他命名空间则具有内核、安全模块或特权相关语义。它是否可靠，取决于文件系统、访问规则和传输工具。只有工作流程按明确契约保留并解释标签，元数据才能成为下游判断的有效依据。 多个名字可以共享 inode 及其属性。复制会产生独立对象，元数据是否保留取决于工具、目标端和权限；内容相同并不足以验证所需属性。 坏掉的样子 属性值不一定是文本，可以包含空字符或任意二进制数据。把它当作以零结尾的字符串，或者假定固定编码，可能破坏原值。空属性和缺失属性也不是同一状态；如果都返回空字符串，就会隐藏元数据到底被刻意设为空，还是在传输中丢失。使用前需要明确编码与缺失语义，而不是依赖显示工具碰巧如何呈现。 同一文件系统内重命名保留对象及属性，复制内容通常却创建另一个 inode。复制工具决定尝试保留哪些元数据，因此文件哈希相同不能证明扩展属性相同。流程可能成功传递每一个内容字节，却遗漏下游需要的分类、来源或应用版本标签。内容校验通过，只能证明它实际覆盖的内容范围。 命名空间名称不会自动建立应用授权规则。设置 user.classification 为 private，不会让本来可读的文件变得保密。user 属性服从适用的文件访问权限，安全属性则有另外的文档语义与策略。把应用标签当作已经强制执行的访问控制，可能在标签看起来完好的同时暴露内容，因此需要检查实际读写行为。 ...

Annotation 为 Kubernetes 对象附加非识别性元数据，可以记录来源、负责人说明，或供工具消费的配置。标准标签选择器不会按 annotation 值筛选对象，但这并不意味着 annotation 没有作用。控制器、准入组件或发布工具都可能解释约定的键并改变行为。判断元数据修改的影响之前，应先确认具体消费者，不能仅凭字段名称认定它只是无害备注。 历史 Deployment 样例对比顶层与 Pod 模板 annotation。generation 本身不是滚动更新证据。本次绘图未重跑集群样例。 不参与选择，不等于没有校验 Annotation 的键和值都必须是字符串。键遵循限定名称格式，可以包含可选的 DNS 风格前缀和名称部分；一个对象的 annotation 键和值合计大小不能超过 256 KiB。因此，它不是不受限制的任意类型 JSON 存储。如果某个工具把 JSON 序列化后放进字符串，额外的格式与解释规则仍然由这个工具负责，而不是自动成为 Kubernetes 的通用语义。 ...