在资源上使用library(dplyr)
library(readr)
sampleDF %>%
t %>%
as_data_frame %>%
type_convert
# A tibble: 3 x 4
# V1 V2 V3 V4
# <int> <int> <int> <chr>
#1 1 2 3 String
#2 1 2 3 4
#3 5 6 7 8
，我看到每个资源都已版本化：
kubectl get with -o yaml我想知道这些版本控制的意义是什么？将它们用于什么目的？ （用例）
答案 0 :(得分：2)
单个资源上的resourceVersion的主要目的是乐观锁定。您可以获取资源，进行更改并将其作为更新提交，并且如果其他客户端同时对其进行了更新，则服务器将拒绝该更新，并出现冲突错误（它们的更新会破坏resourceVersion以及您的值提交会告诉服务器您认为您要更新的版本
答案 1 :(得分：2)
更详细的解释，可以帮助我准确了解其工作原理：
您在本书中创建的所有对象-Pod，
ReplicationControllers, Services, Secrets，依此类推-需要 以持久的方式存储在某处，以便其清单可以保留API 服务器重新启动和失败。为此，Kubernetes使用etcd， 是快速，分布式且一致的键值存储。唯一的 直接与etcd通信的组件是Kubernetes API服务器。 所有其他组件通过以下方式间接将数据读写到etcd中 API服务器。这带来了一些好处，其中包括更强大的乐观 锁定系统以及验证；并且，通过将 其他所有组件的实际存储机制， 将来更换它更简单。值得强调etcd 是Kubernetes唯一存储集群状态和元数据的地方。
乐观并发控制（有时称为 optimistic 锁定）是一种方法，而不是锁定一条数据并 防止在锁定到位时对其进行读取或更新， 该数据包括版本号。每次数据 更新后，版本号增加。更新数据时， 检查版本号是否在两次更新之间增加了 客户端读取数据和提交更新的时间。如果这 发生，更新被拒绝，客户端必须重新读取新的 数据，然后尝试再次更新。结果是当两个客户 尝试更新相同的数据条目，只有第一个成功。
结果是，当两个客户端尝试更新同一数据条目时， 只有第一个成功
Marko Luksa，“ Kubernetes在行动”
因此，所有Kubernetes资源都包含一个metadata.resourceVersion字段，客户端在更新对象时需要将其传递回API服务器。如果版本与etcd中存储的版本不匹配，则API服务器会拒绝更新