在资源上使用kubectl get with -o yaml，我看到每个资源都是版本化的：
kind: ConfigMap
metadata:
creationTimestamp: 2018-10-16T21:44:10Z
name: my-config
namespace: default
resourceVersion: "163"
我想知道这些版本控制的意义是什么，它们的用途是什么？ （用例）
【问题讨论】：
标签： version-control kubernetes
更详细的解释，帮助我准确理解其工作原理：
您在本书中创建的所有对象——Pod，
ReplicationControllers, Services, Secrets等等——需要 以持久的方式存储在某处，因此它们的清单在 API 中存在 服务器重新启动和故障。为此，Kubernetes 使用etcd，它 是一种快速、分布式且一致的键值对存储。唯一的 直接与etcd对话的组件是 Kubernetes API 服务器。 所有其他组件通过间接读取和写入数据到 etcd API 服务器。这带来了一些好处，其中包括更强大的乐观 锁定系统以及验证；并且，通过抽象出 所有其他组件的实际存储机制， 以后更容易更换。值得强调的是，etcd 是 Kubernetes 存储集群状态和元数据的唯一地方。
乐观并发控制（有时称为乐观 锁定) 是一种方法，它不是锁定一条数据，而是 防止在锁定到位时读取或更新它， 该数据包括版本号。每次数据都是 更新，版本号增加。更新数据时， 检查版本号以查看它是否在时间之间增加 客户端读取数据和提交更新的时间。如果这 发生，更新被拒绝，客户端必须重新读取新的 数据并尝试再次更新。结果是当两个客户端 尝试更新相同的数据条目，只有第一个成功。
结果是当两个客户端尝试更新同一个数据条目时， 只有第一个成功
Marko Luksa，“Kubernetes 在行动”
因此，所有 Kubernetes 资源都包含一个 metadata.resourceVersion 字段，客户端在更新对象时需要将其传递回 API 服务器。如果版本与etcd 中存储的版本不匹配，API 服务器将拒绝更新
【讨论】：
单个资源上的 resourceVersion 的主要目的是乐观锁定。您可以获取资源，进行更改并将其作为更新提交，如果同时另一个客户端更新了它，服务器将拒绝更新并出现冲突错误（他们的更新会碰撞资源版本，并且您的值提交告诉服务器你认为你正在更新什么版本）
【讨论】：
metadata.resourceVersion），发送新的更新(PUT) 尝试。请参阅github.com/kubernetes/community/blob/master/contributors/devel/… 和推荐的实现godoc.org/k8s.io/client-go/util/retry#RetryOnConflict。在概念上类似于“git fetch; git rebase; git push --ff-only”，此流程允许任意客户端“解决冲突”。
kubectl apply，以及稍微不同的 "server-side apply"（这两个使用额外的元数据，而不仅仅是 resourceVersion。它们适用于特定场景，并非一切都需要他们...）