时间戳

首页 > 解决方案 > Kubernetes - 使用特定的 ConfigMap 版本控制

kubernetes - Kubernetes - 使用特定的 ConfigMap 版本控制

问题描述

我有几个关于 configMap 版本控制的问题。

  1. 是否可以在部署文件中使用特定版本的 configMap？

  2. 我没有看到任何 API 来获取版本列表。如何获取版本列表？

  3. 是否可以比较 configMap b/w 版本？
  4. 如何控制版本数？

谢谢

标签： kubernetes

解决方案

是否可以在部署文件中使用特定版本的 configMap？

并不真地。
“版本”的最接近的概念是 resourceVersion，但这不是用户可以直接操作的。

请参阅API 约定：并发控制和一致性：

Kubernetes 利用资源版本的概念来实现乐观并发。所有 Kubernetes 资源都有一个“ resourceVersion”字段作为其元数据的一部分。这resourceVersion是一个字符串，用于标识对象的内部版本，客户端可以使用该字符串来确定对象何时更改。
当记录即将更新时，会根据预先保存的值检查其版本，如果不匹配，则更新失败并显示StatusConflict（HTTP 状态代码 409）。

resourceVersion每次修改对象时，服务器都会更改它。如果resourceVersion包含在操作中，系统将通过验证当前值是否与指定值匹配PUT来验证在读/修改/写周期期间资源没有其他成功的突变。resourceVersion

目前resourceVersion由 etcd 支持modifiedIndex。
但是，需要注意的是，应用程序不应依赖 Kubernetes 维护的版本控制系统的实现细节。我们将来可能会更改 的实现resourceVersion，例如将其更改为时间戳或每个对象的计数器。

客户端知道预期值的唯一方法resourceVersion是从服务器接收到它以响应先前的操作，通常是GET. 这个值必须被客户端视为不透明的，并且不加修改地传回服务器。
客户端不应假定资源版本对命名空间、不同种类的资源或不同服务器具有意义。
目前， 的值resourceVersion被设置为匹配 etcd 的排序器。您可以将其视为 API 服务器可用于对请求进行排序的逻辑时钟。但是，我们预计 的实现resourceVersion在未来会发生变化，例如在我们按种类和/或命名空间对状态进行分片的情况下，或者移植到另一个存储系统。

在发生冲突的情况下，此时正确的客户端操作是GET再次对资源，重新应用更改，然后再次尝试提交。
此机制可用于防止以下竞争：

Client #1                                  Client #2
GET Foo                                    GET Foo
Set Foo.Bar = "one"                        Set Foo.Baz = "two"
PUT Foo                                    PUT Foo

当这些序列并行发生时，更改为Foo.Bar或更改为Foo.Baz可能会丢失。

另一方面，当指定 时resourceVersion，其中一个PUTs 将失败，因为无论哪个写入成功都会更改resourceVersionfor Foo。

resourceVersion可以用作将来其他操作（例如 , ）的前提条件GET，DELETE例如在存在缓存的情况下读取后写入的一致性。

“监视”操作resourceVersion使用查询参数指定。它用于指定开始监视指定资源的点。
这可用于确保在GET资源（或资源列表）和后续 Watch 之间不会遗漏任何突变，即使资源的当前版本更新。这是目前列表操作（在集合上）返回
的主要原因。GETresourceVersion

推荐阅读