kubernetes - 从 GitLab CI 作业向 Kubernetes Pod 发送信号

Question

我使用的是自托管 Kubernetes 集群，我没有使用 GitLab 的 Kubernetes 集成。在我的 GitLab CI 作业中，我在其关联的 ConfigMap 中更改 Prometheus 部署的配置，我想通过向其进程发送 SIGHUP 信号让 Prometheus 了解新配置。这是我更新 ConfigMap 并发送信号的作业脚本:

for x in *; do kubectl get configmap prometheus-config -o json | jq --arg name "$(echo $x)" --arg value "$(cat $x)" '.data[$name]=$value' | kubectl apply -f -; done;
kubectl exec deployments/prometheus -- /bin/sh -c "/bin/pkill -HUP prometheus"

这种方法在我的本地终端上运行良好。在ConfigMap中手动更改并通过上述命令发送信号后，我可以在Prometheus中看到之后的效果。

问题是，当我将这些命令放入我的 GitLab CI 作业脚本时，它似乎什么也没做。命令成功运行，我的 CI 作业已完成，但 Prometheus 中没有任何刷新。

我想知道 GitLab 执行其作业的方式(shell 的非交互性等)是否会导致这种行为，但我不知道我能做些什么。

我还尝试在 CI 中运行虚拟 kubectl exec 以查看它是否有效:

kubectl exec deployments/prometheus -- /bin/sh -c "echo hi"

它成功地打印了hi。那么，当我通过它发送信号时，kubectl 和 GitLab CI 有什么问题？

附言我保持 Pod 存活并使用新配置更新它而不是仅仅重新启动它的方法似乎是一种不好的做法，但是如果我重新启动 Pod，Prometheus 需要 5~10 分钟才能再次读取 tsdb，而我没有想因为配置更改而失去我的监控系统。所以，我现在坚持发送那个信号。

Answer 1

Config Maps 不 update immediately .可以延迟 up to 2 minutes (从 v1.18 开始)，以便在 Pod 中反射(reflect)更改。

一个常见的解决方案是将配置映射视为不可变数据，因此必须创建一个新的配置映射，这将需要一个新的部署模板，并触发 pod 推出。 ConfigMap 名称中的时间戳或版本号通常有效。

  volumes:
    - name: config-volume
      configMap:
        name: config-20200527-013643

另一种解决方案是在部署模板中包含一个带有配置映射数据校验和的注释。当校验和更新时，新的 pod 将使用更新的 ConfigMap 启动。这在 helm 模板中很常见:

annotations:
  checksum/config: {{ include (print $.Template.BasePath "/config.yaml") . | sha256sum }}

在 prometheus 缓慢启动的特定情况下，触发部署 pod 推出在技术上是重新启动，因此“中断”取决于 Prometheus 的“就绪”探测是否满足您对“在线”的期望。

如果您仍然需要使用 SIGHUP，一个 shell test能够比较文件修改时间与 -ot 和 -nt。在 while 循环中，作业可以等待 configmap 文件更新:

kubectl exec deployments/prometheus -- /bin/sh -c "touch /tmp/cireload"
# apply config map changes
kubectl exec deployments/prometheus -- /bin/sh -c "while [ /tmp/cireload -ot /path/to/configmap.yaml ]; do sleep 5; echo "waiting for configmap $(date)"; done; /bin/pkill -HUP prometheus"