没有任何规则反对它。许多软件利用kube API来执行某种逻辑/状态，即领导者选举。所有这些都需要应用程序将更改应用到kube资源。记住这一点，它总是会给你的API带来一些额外的负载，如果你不走运，这可能会成为一个问题。大约两年前，我们“我在一个托管k8s服务上遇到了API限制耗尽的问题，因为我们使用了大量具有相当密集的领导者选举逻辑的部署（每5秒每个pod 2个请求）。这个问题从那时起就消失了，但它显示了在设计这样的交互时必须考虑的因素（重试，回退等）。

使用configMap非常适合此类用例。您可以使用客户端库来监视给定configMap上的更新，但是更干净的解决方案是将configMap作为文件挂载到pod中，并从给定文件设置配置。由于您将configMap挂载为卷，更改将不需要pod重新启动以使更改在pod中可见（不像env变量，它只在pod重新创建后才“刷新”）。
假设您有这样的configMap：

apiVersion: v1
kind: ConfigMap
metadata:
  name: special-config
  namespace: default
data:
  SPECIAL_LEVEL: very
  SPECIAL_TYPE: charm

然后将此configMap作为卷装载到Pod中：

apiVersion: v1
kind: Pod
metadata:
  name: dapi-test-pod
spec:
  containers:
    - name: test-container
      image: registry.k8s.io/busybox
      command: [ "/bin/sh", "-c", "ls /etc/config/" ]
      volumeMounts:
      - name: config-volume
        mountPath: /etc/config
  volumes:
    - name: config-volume
      configMap:
        # Provide the name of the ConfigMap containing the files you want
        # to add to the container
        name: special-config
  restartPolicy: Never

pod运行时，命令ls /etc/config/生成以下输出：

SPECIAL_LEVEL
SPECIAL_TYPE

通过这种方式，您还可以减少API服务器的“噪音”，因为您可以简单地查询给定的文件以获取任何配置的更新。