K8s运行时修改Pod挂载ConfigMap配置及交互式运行方案咨询

直接修改对应ConfigMap的x.config.file字段内容即可，K8s会自动同步挂载该ConfigMap的所有Pod内的对应文件，不管现有多少实例、后续扩容的新实例，都会自动加载最新的ConfigMap内容。

• 如果你需要更快的同步速度，不想等K8s默认的同步周期，可以在修改ConfigMap后手动触发Pod的滚动重启：kubectl rollout restart deployment x，该操作会无中断重建所有Pod实例，新Pod会直接拉取最新ConfigMap内容。

可以实现，但不建议作为生产环境的常规配置方案，仅可用于临时调试场景：

• 你需要修改Deployment的Pod模板配置，给容器添加tty: true和stdin: true参数，开启容器的交互式终端能力：

spec:
  containers:
  - name: x-container # 替换为你实际的容器名
    image: 你的镜像地址
    tty: true
    stdin: true
    # 其余原有配置保持不变

• 配置生效后，你可以通过kubectl exec -it <pod名> -- 你的应用命令行交互指令直接和应用进程通信修改配置，但注意该方式修改的配置仅对当前单个Pod生效，Pod重建、新扩容的Pod都会恢复为ConfigMap中的配置，且多实例场景下需要逐个操作，一致性无法保障。

该问题是K8s ConfigMap挂载的默认实现机制导致的：K8s更新ConfigMap挂载文件时，并不是直接修改原文件内容，而是先写入临时文件，再通过原子替换软链接的方式更新目标文件，默认的inotify监听规则如果是监听文件本身的修改事件，就会捕获不到该更新。
解决方法有两种，可根据实际场景选择：

• 方案1：修改应用的FileWatcher监听逻辑，改为监听配置文件所在的目录的变更事件，而不是监听单个config.yaml文件的变更，目录会在软链接替换时触发修改事件，你在收到事件后重新读取config.yaml内容即可。
• 方案2：如果没法修改应用代码，可以给ConfigMap挂载配置添加subPath字段，直接挂载单个文件而非整个ConfigMap目录，这种方式更新时K8s会直接修改原文件内容，可触发inotify的文件修改事件，修改后的Deployment卷挂载配置参考：

spec:
  containers:
  - name: x-container
    volumeMounts:
    - name: config
      mountPath: /你容器内配置文件的路径/config.yaml # 替换为实际路径
      subPath: config.yaml # 新增这一行
  volumes:
    - name: config
      configMap:
        name: x-config
        items:
          - key: x.config.file
            path: config.yaml
        defaultMode: 420

注意：使用subPath挂载ConfigMap的场景下，后续ConfigMap更新不会自动同步到Pod内的文件，需要手动滚动重启Pod才能加载新配置。

内容的提问来源于stack exchange，提问作者jparisu