Kubernetes 资源版本控制

Question

kubectl get with -o yaml在资源上使用，我看到每个资源都有版本控制：

kind: ConfigMap
metadata:
  creationTimestamp: 2018-10-16T21:44:10Z
  name: my-config
  namespace: default
  resourceVersion: "163"

我想知道这些版本控制的意义是什么以及它们的用途是什么？（ 用例 ）

Answer 1

更详细的解释，帮助我准确理解它是如何工作的：

\n\n

\n

您在本书中创建的所有对象\xe2\x80\x99\xe2 ReplicationControllers, Services, Secrets\x80\x94Pods、\n 等等\xe2\x80\x94 需要以持久的方式存储\n 某处，以便它们的清单能够在 API\n 服务器上保存重新启动和失败。为此，Kubernetes 使用etcd，这是一种快速、分布式且一致的键值存储。唯一etcd直接通信的组件是 Kubernetes API 服务器。所有其他组件都通过 API 服务器间接向 etcd 读取和写入数据。

\n\n

这带来了一些好处，其中包括更强大的乐观锁定系统以及验证；并且，通过从所有其他组件中抽象出实际的存储机制，将来替换它会更简单。值得强调的是，etcd\n 是 Kubernetes 存储集群状态和元数据的唯一地方。

\n\n

乐观并发控制（有时称为乐观锁定）是一种方法，该方法不是锁定一段数据并在锁定到位时防止其被读取或更新，而是该数据包含一个版本数字。每次更新数据时，版本号都会增加。更新数据时，会检查版本号，看看版本号在客户端读取数据和提交更新之间是否有所增加。如果发生这种情况，更新将被拒绝，客户端必须重新读取新数据并尝试再次更新。结果是，当两个客户端尝试更新相同的数据条目时，只有第一个客户端成功。

\n\n

结果是，当两个客户端尝试更新相同的数据条目时，只有第一个客户端成功

\n

\n\n

Marko Luksa，“Kubernetes 在行动”

\n\n

因此，所有 Kubernetes 资源都包含一个metadata.resourceVersion字段，客户端在更新对象时需要将其传回 API 服务器。如果版本与\xe2\x80\x99 中存储的版本不匹配etcd，API 服务器将拒绝更新

\n