为什么不能用不等号比较K8s的metadata.resourceVersion资源版本？

你过往观察到的「数值型、单调递增」只是当前Kubernetes默认使用etcd作为存储时的偶然表现，不属于API官方承诺的稳定特性，设置这条限制的原因主要有三个：

• 避免强绑定底层存储实现
  resourceVersion本质是存储层返回的内部修改标识，Kubernetes从未限定必须使用etcd作为存储组件。如果后续更换其他分布式存储，或是etcd自身调整了revision生成规则，resourceVersion完全可能变为哈希字符串、带集群标识的混合格式，天生不支持数值排序。
  即便是一直使用etcd，在集群快照恢复、跨集群数据迁移、联邦多集群同步等场景下，resourceVersion的数值也可能出现跳变、重置，并不保证全局单调递增，不等比较的结果没有任何可靠性。
• 预留API向后兼容的迭代空间
  Kubernetes的API兼容性承诺仅覆盖文档明确公示的字段语义，如果开放不等比较的用法，就等于把resourceVersion的生成逻辑也变成了必须维持的公开承诺，后续官方如果要优化存储层逻辑，就会导致大量依赖排序的存量客户端直接故障。这条限制本质是把底层实现细节和公开API语义做了切割，既给官方留了迭代空间，也避免用户依赖非承诺特性导致业务受损。
• 客户端自行比较没有实际意义
  所有需要校验版本先后的场景，Kubernetes都提供了官方实现方案：提交更新操作时携带你拿到的resourceVersion，API服务端会自动判断是否为当前最新版本，冲突会直接返回409错误；做watch/增量同步时直接把resourceVersion作为请求参数传给API Server，由服务端处理版本匹配逻辑。客户端自行比较既不可靠，也完全没有必要。

合法用法提示：如果仅需要判断资源是否发生过变更，直接比较两个resourceVersion的字符串是否相等即可，这是文档明确保证的有效用法。

内容的提问来源于stack exchange，提问作者Dmitri Gekhtman