version-control - 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

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

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.

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 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的行动”

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