Kubernetes：ConfigMap特定版本使用及版本管理相关技术问询

嘿，很高兴能帮你梳理这些ConfigMap版本控制的问题，结合实际K8s使用经验，我逐一给你拆解：

1. 是否可以在Deployment文件中使用特定版本的ConfigMap？ #

Kubernetes原生并没有给ConfigMap内置版本号机制，默认情况下Deployment引用ConfigMap时只会关联当前名称的最新状态。不过咱可以通过两种实用方式实现“绑定特定版本”的需求：

• 版本化命名：给不同版本的ConfigMap加后缀区分，比如my-app-config-v1、my-app-config-v2，然后在Deployment的volume或环境变量配置里直接指定对应名称的ConfigMap。这种方式简单直观，适合中小规模场景。
• GitOps管理：把ConfigMap的定义托管在Git仓库里，用Argo CD、Flux这类工具同步到集群。Deployment可以绑定到Git仓库中特定提交/tag对应的ConfigMap版本，通过Git的版本控制来间接实现绑定。

注意：K8s的resourceVersion是内部用于资源一致性校验的字段，不能用来指定旧版本的ConfigMap，Deployment不支持通过这个字段引用历史版本。

2. 如何获取ConfigMap的版本列表？ #

K8s原生API没有保存ConfigMap的历史版本，所以没有直接获取版本列表的接口，但可以通过以下方法追踪历史版本：

• 启用审计日志：配置K8s审计策略，记录所有ConfigMap的创建、修改、删除操作。之后可以从审计日志中提取出每次变更的时间、内容和操作者，整理成版本列表。
• Git仓库托管：把所有ConfigMap的yaml定义存在Git仓库，Git的提交历史就是天然的版本列表。用git log --oneline path/to/configmap.yaml就能快速查看所有版本的变更记录。
• 第三方备份工具：用Velero这类工具定期备份ConfigMap，备份的快照集合就是版本列表，你可以通过Velero的命令查看所有备份的快照信息。
• 自定义控制器：写一个简单的K8s控制器，监听ConfigMap的变更事件，每次修改时把旧版本保存到自定义CRD或专用的ConfigMap中，手动维护版本列表。

3. 能否对比不同版本的ConfigMap？ #

当然可以，具体方式取决于你用的版本追踪方法：

• Git托管场景：直接用Git的对比命令，比如git diff <commit-hash-1> <commit-hash-2> -- path/to/configmap.yaml，就能清晰看到两个版本的配置差异。
• 备份快照场景：从Velero备份中提取不同版本的ConfigMap yaml内容，保存到本地文件后用diff命令对比，比如diff v1-config.yaml v2-config.yaml。
• 版本化命名场景：把不同版本的ConfigMap导出到本地，再对比：

  kubectl get configmap my-app-config-v1 -o yaml > v1.yaml
  kubectl get configmap my-app-config-v2 -o yaml > v2.yaml
  diff v1.yaml v2.yaml
  

• 审计日志场景：从审计日志中提取两次变更前后的ConfigMap内容，再用文本对比工具查看差异。

4. 如何控制ConfigMap的版本数量？ #

根据你采用的版本管理方式，有对应的控制方法：

• Git托管场景：Git本身不需要刻意限制版本数量，但可以通过标签标记重要版本（比如v1.0.0），定期清理无用的临时分支，或者用Git的gc命令优化存储。
• 自定义控制器场景：在控制器逻辑里添加版本保留策略，比如只保留最近5个版本，每次新增版本时自动删除最旧的那个。
• 备份工具场景：在Velero的备份配置中设置保留规则，比如只保留最近7天的备份，或者最多保留10个快照，超过数量的自动清理。
• 版本化命名场景：制定团队规范，比如只保留最近3个活跃版本，写个简单的Shell脚本定期清理旧版本的ConfigMap，比如：

  # 保留最近3个版本，删除更早的
  kubectl get configmaps -l app=my-app | grep "my-app-config-v" | sort -r | awk 'NR>3 {print $1}' | xargs kubectl delete configmap
  

内容的提问来源于stack exchange，提问作者user1578872