我对configMap版本控制有几个问题。
是否可以在部署文件中使用特定版本的configMap？
我没有看到任何API来获取版本列表。如何获取版本列表？
由于
答案 0 :(得分：1)
是否可以在部署文件中使用特定版本的configMap？
不是真的。
最近的＆＃34;版本＆＃34;是resourceVersion，但这不是由用户直接采取行动。
请参阅API conventions: concurrency control and consistency：
Kubernetes利用资源版本的概念来实现乐观并发。所有Kubernetes资源都有一个＆＃34;
resourceVersion＆＃34;字段作为其元数据的一部分。此resourceVersion是一个字符串，用于标识客户端可用于确定对象何时更改的对象的内部版本。
即将更新记录时，会根据预先保存的值检查其版本，如果匹配不匹配，则更新将失败，并显示StatusConflict（HTTP状态代码409）每次修改对象时，服务器都会更改
resourceVersion。如果resourceVersion操作中包含PUT，则系统将在读取/修改/写入周期内验证资源没有其他成功的突变，方法是验证当前值{{1匹配指定的值。
resourceVersion目前由etd＆＃39;resourceVersion支持 但是，重要的是要注意应用程序不应该依赖于Kubernetes维护的版本控制系统的实现细节。我们将来可能会更改modifiedIndex的实现，例如将其更改为时间戳或每个对象的计数器。客户端知道
resourceVersion的预期值的唯一方法是从服务器接收它以响应先前的操作，通常是resourceVersion。客户端必须将此值视为不透明，并将未修改的值传递回服务器 客户端不应该假设资源版本在命名空间，不同类型的资源或不同的服务器中具有意义 目前，GET的值设置为匹配etcd的音序器。您可以将其视为API服务器可用于订购请求的逻辑时钟。 但是，我们希望将来resourceVersion的实现会发生变化，例如我们按类和/或命名空间分区状态，或者将端口分配给另一个存储系统。如果发生冲突，此时正确的客户端操作是再次
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会失败，因为无论哪个写入成功，都会更改PUT的{{1}}。
resourceVersion可以在将来用作其他操作（例如，Foo，resourceVersion）的前提条件，例如在存在缓存时的写后读写一致性＆＃34;观看＆＃34;操作使用查询参数指定
GET。它用于指定开始观察指定资源的点 这可用于确保DELETE资源（或资源列表）与后续Watch之间不会遗漏任何突变，即使当前版本的资源更新。 这是目前列表操作（集合上的resourceVersion）返回GET的主要原因。