从要求2开始：
每当我更新一个特定的configMap时，客户端群集应该自动开始使用新的configMap
如果将configmap装载到部署中，它将自动更新，但是，如果作为环境重新启动注入是唯一的选项，除非您正在使用附属解决方案或重新启动进程。
对于参考：Update configmap without restarting POD

我应该如何实现这一目标？

• 我认为ImagePullpolicy不是一个好的选项，但是在这种情况下，需要手动干预来重新启动部署，并且它会从客户端拉取最新映像，而且不会以受控方式进行。

"使用Kubernetes Cronjobs？"

• Cronjobs你将运行哪一边？如果客户端也可以这样做。

否则，您可以使用Exposed API保持部署，当任何映像被推送到您的Docker注册表时，该API将运行作业以使用最新的标记更新部署。

Kubernetes运算子？

• 运算符是一个很好的原生K8选项，您可以使用Go、Python或您的首选语言（带/不带运算符框架或客户端库）进行编写。

"还是别的什么"
如果您只是想更新部署，请在部署或作业中运行API，您可以以受控的方式安排，如果您可以创建、管理和部署一个操作员，则操作员也不会有问题，这将是一个更本地化的好方法。
如果将来您需要从单个信息源管理多个客户端的所有群集（部署、服务、防火墙、网络），您可以探索Anthos。
Config management from Git repo sync with Anthos

您可以构建一个Kubernetes运算符来监视您的特定配置Map并触发集群重新启动。至于滚动更新，您可以根据自己的要求配置部署。当且仅当部署的单元模板（即.spec.template）的值，例如，如果更新了模板的标签或容器图像，请在Kubernetes部署.spec部分添加滚动更新规范：

type: RollingUpdate
 rollingUpdate:
  maxSurge: 3             //the maximum number of pods to be created beyond the desired state during the upgrade
  maxUnavailable: 1       //the maximum number of unavailable pods during an update
  timeoutSeconds: 100     //the time (in seconds) that waits for the rolling event to timeout
  intervalSeconds: 5      //the time gap in seconds after an update
  updatePeriodSeconds: 5  //time to wait between individual pods migrations or updates