假设我有一个带有configMap（或秘密）卷的容器。 在Pod的创建过程中存在ConfigMap（或secret）对象，但是在Pod运行时，我删除了主节点上的configMap（或secret）对象。 预期的行为是什么？它在任何地方都有记录吗？
正在运行的吊舱是否已终止？ 是否已删除configMap（或机密）文件，并且pod继续运行？
这是我可以找到的关于documentation的更新，没有提及删除的内容。
更新已在卷中使用的ConfigMap时，最终也会投影投影的键。 Kubelet正在检查是否在每个定期同步中都重新安装已安装的ConfigMap。但是，它使用其基于本地ttl的缓存来获取ConfigMap的当前值。结果，从更新ConfigMap到将新键投射到Pod的总延迟时间与kubelet一样长。 kubelet中的ConfigMaps缓存的同步周期+ ttl。
答案 0 :(得分：1)
您的工作负载没有任何反应。一旦它们由主节点上的kube-scheduler进行调度，然后由节点上的kubelet进行调度，ConfigMaps，Secrets等将存储在节点的本地文件系统中。默认值是这样的：
# ConfigMaps
/var/lib/kubelet/pods/<pod-id>/volumes/kubernetes.io~configmap/configmapname/
# Secret
/var/lib/kubelet/pods/<pod-id>/volumes/kubernetes.io~secret/secret-token/
这些实际上最终安装在容器上，位于容器规范上指定的路径上。
当您在Kubernetes中删除对象时，它实际上已从其数据存储区（etcd）中删除。假设您的Pod出于某种原因需要重新启动，则它们将无法重新启动。
简短的回答是，您的工作负载没有任何反应，但是如果您的Pod需要重新启动，它们将无法重新启动。