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

Question

我使用的是自托管 Kubernetes 集群，并且没有使用 GitLab 的 Kubernetes 集成。SIGHUP在我的 GitLab CI 工作中，我正在更改关联 ConfigMap 中 Prometheus 部署的配置，并且我希望通过向 Prometheus 进程发送信号来让 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 的非交互性等）是否会导致这种行为，但我不知道我能对此做些什么。

我还尝试kubectl exec在 CI 中运行一个虚拟程序来看看它是否有效：

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

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

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

Answer 1

配置映射不会立即更新。更改在 Pod 内反映出来可能会有最多 2 分钟的延迟（从 v1.18 开始）。

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

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

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

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

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

如果您仍然需要使用 SIGHUP，shelltest可以将文件修改时间与-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"