Kubernetes资源版本控制 [英] Kubernetes resource versioning

问题描述

在资源上使用kubectl get with -o yaml，我看到每个资源都已版本化:

Using kubectl get with -o yaml on a resouce , I see that every resource is versioned:

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

我想知道这些版本控制的意义是什么?将它们用于什么目的? (用例)

I wonder what is the significance of these versioning and for what purpose these are used? ( use cases )

推荐答案

更详细的解释，可以帮助我准确地了解其工作原理:

A more detailed explanation, that helped me to understand exactly how this works:

您在本书中创建的所有对象-Pod， ReplicationControllers, Services, Secrets，依此类推-需要 以持久的方式存储在某处，以便其清单可以保留API 服务器重新启动和失败.为此，Kubernetes使用etcd， 是一个快速，分布式且一致的键值存储.唯一的 直接与etcd对话的组件是Kubernetes API服务器. 所有其他组件通过以下方式间接将数据读写到etcd中 API服务器.

All the objects you’ve created throughout this book—Pods, ReplicationControllers, Services, Secrets and so on—need to be stored somewhere in a persistent manner so their manifests survive API server restarts and failures. For this, Kubernetes uses etcd, which is a fast, distributed, and consistent key-value store. The only component that talks to etcd directly is the Kubernetes API server. All other components read and write data to etcd indirectly through the API server.

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

This brings a few benefits, among them a more robust optimistic locking system as well as validation; and, by abstracting away the actual storage mechanism from all the other components, it’s much simpler to replace it in the future. It’s worth emphasizing that etcd is the only place Kubernetes stores cluster state and metadata.

乐观并发控制(有时称为 optimistic 锁定)是一种方法，该方法不是锁定一条数据，而是 防止在锁定到位时对其进行读取或更新， 该数据包括版本号.每次数据 更新后，版本号增加.更新数据时， 检查版本号是否在两次更新之间增加了 客户端读取数据和提交更新的时间.如果这 发生，更新被拒绝，客户端必须重新读取新的 数据，然后尝试再次更新.结果是当两个客户 尝试更新相同的数据条目，只有第一个成功.

Optimistic concurrency control (sometimes referred to as optimistic locking) is a method where instead of locking a piece of data and preventing it from being read or updated while the lock is in place, the piece of data includes a version number. Every time the data is updated, the version number increases. When updating the data, the version number is checked to see if it has increased between the time the client read the data and the time it submits the update. If this happens, the update is rejected and the client must re-read the new data and try to update it again. The result is that when two clients try to update the same data entry, only the first one succeeds.

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

The result is that when two clients try to update the same data entry, only the first one succeeds

Marko Luksa，"Kubernetes在行动"

Marko Luksa, "Kubernetes in Action"

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

So, all the Kubernetes resources include a metadata.resourceVersion field, which clients need to pass back to the API server when updating an object. If the version doesn’t match the one stored in etcd, the API server rejects the update

这篇关于Kubernetes资源版本控制的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！