我有一个Kubernetes窗格（我们称其为 POD-A ），我希望它使用某个配置文件来使用k8s API执行某些操作。配置文件将是YAML或JSON，将由pod内的应用程序进行解析。
该配置文件由云上的应用程序服务器托管，并且可以基于触发器来获取其最新版本。该配置文件包含k8s集群中所有部署的配置详细信息，并将用于通过 POD-A 中的k8s API更新部署。
现在我在想的是将这个配置文件保存在一个config-map中，每当一个新的配置文件被拉出时，使用k8s API的pod都会创建一个新的config-map。
我想做的是使用某个标志（一个键和一个值）更新以前的配置映射，这基本上可以帮助应用程序知道哪个是当前的部署版本。假设我有一个运行中的k8s集群，其中有多个Pod，其中有一个config-map，其中包含针对这些Pod的所有配置详细信息（映像版本，名称空间等），以及一个标志，用于通知当前部署和 POD-A 中的应用程序将通过加载config-map知道这一点。现在，当拉出新的配置文件时，将创建一个新的配置图，并且对于先前的配置图，当前部署的标志设置为false，对于最新创建的配置图，其设置为true。然后，该配置映射用于更新群集中的所有Pod。
我知道有很多细节，但是我不得不向他们解释以下问题：
1）configmaps是否可以用于此目的？
2）我可以更新configmaps还是必须完全重写它们？我正在考虑在configmap中写文件，因为那样会更简单。
3）我知道configmaps存储在etcd中，但是它们是持久存储在磁盘上还是保留在内存中？
4）假设 POD-A 下降会对configmaps产生影响吗？它们以某种方式与吊舱的生命周期相关联吗？
5）如果k8s集群本身发生故障，那么configmaps会发生什么？由于它们在 etcd 中，因此如果持久存在，它们将再次可用吗？
注意：这里还有一个limit on the size of configmaps，所以我必须牢记这一点。尽管我猜想1MB足以存储配置文件，因为它通常只有几个字节。
答案 0 :(得分：1)
1）我认为您不应该以这种方式使用它。
2）ConfigMap是kubernetes资源。您可以更新它们。
3）如果启用了etcd到磁盘的备份。
4）否。除非pod更改（删除）configmap，否则pod的生命周期不应影响configmap。
5）如果群集本身发生故障。假设etcd也在同一群集上运行，则在群集再次恢复之前，etcd将不可用。 ETCD具有将备份持久保存到磁盘的选项。如果启用了此选项，则在备份etcd时，它将恢复备份中的值。因此，一旦集群＆etcd启动，它就应该可用。
有多种方法可以在容器中挂载configMap，例如环境变量，文件等。 如果您更改配置映射，则值不会在configMaps中作为文件更新。仅configMaps的值作为env变量会动态更新。现在，在pod中运行的进程应该检测到env变量已更新，并采取了一些措施。
所以我认为系统会太复杂。
相反，触发一个部署，该部署杀死旧的Pod，并调出使用更新的configMaps的新Pod。