Kubernetes configMap 版本为什么？

Question

我对我们为什么使用 configMap 版本感到困惑。我在连接到部署/sts 的 k8s 集群中看到了多个版本的 confimap。我期待如果我在我的 yaml 中应用一些更改，它将反映在所有 configMap 版本中，但这并没有发生。有人可以帮忙吗？

我在 configmap 中没有任何 subdir。

您知道多少时间来反映已安装卷中的这些更改吗？或者我在这里缺少的东西

示例配置映射输出

NAME                          DATA   AGE
ca-bundles                    4      3d17h
c-rules-alerts            1      3d17h
c-rules-alerts-v000       1      3d16h
c-rules-alerts-v001       1      50m
c-rules-metrics           1      3d17h
c-rules-metrics-v000      1      3d16h
c-rules-metrics-v001      1      50m
c-alertmanager        1      3d17h
c-alertmanager-v000   1      3d16h
c-server              3      3d17h
c-server-v000         3      3d16h

这是挂载配置

          volumeMounts:

            - name: config-metric-volume
              mountPath: /oracle_exporter
      volumes:
        - name: data-volume
          emptyDir:
            sizeLimit: 2Gi
        - name: config-metric-volume
          configMap:
            name: chron-rules-metrics

Answer 1

Kubernetes 默认提供了一种存储某些资源的推出信息的方法，其中之一就是部署。

您可以执行一些提供--record 标志的命令，该标志将记录部署的当前和新状态，允许您执行rollback

详情请见this answer

其他资源，没有该功能和工具，如 helm 和 kapp 创建资源版本以允许您回滚部署/状态集/等及其所有相关资源，如机密、配置图、入口等。

一些工具将该信息存储在注释中，而另一些工具则创建一个命名重复当前资源，并遵循约定的后缀。

---

因此，除此之外，我们可以谈谈如何查看反映在您的部署中的更改。

同样，默认情况下，如果您更改部署（sts、ds 等）规范中影响 pod 的任何内容，kuberntes 将触发推出并重新创建所有 pod 以反映新规范。

当您更新映射到 pod 的机密和配置映射时，不会发生这种情况。有赞成和反对这种行为的论据，有些人认为这很有用，有些人认为这可能会导致集群中出现一些巨大的连锁反应。

无论讨论在哪里结束，这都是今天的行为。

要查看 pod 上反映的配置映射或机密更改，您必须触发重启。

kubectl rollout restart deployment/my-awesome-app