当它们的configmap被更改/更新时,我如何自动重新启动Kubernetes pod和与部署相关的pod ?


我知道有关于在配置映射发生变化时自动重启pod的讨论,但据我所知,这在Kubernetes 1.2中还没有。

因此(我认为)我想做的是“滚动重新启动”与使用配置映射的pod相关联的部署资源。在Kubernetes中,在不改变实际模板的情况下强制滚动重启部署是否可能?如果可能的话,如何实现?这是目前最好的方式还是有更好的选择?


当前回答

Helm 3文档页

通常情况下,配置映射或秘密作为配置文件注入到容器中。根据应用程序的不同,如果后续的头盔升级更新了这些配置,则可能需要重新启动,但如果部署规范本身没有更改,则应用程序将继续使用旧配置运行,从而导致部署不一致。

sha256sum函数可以与include函数一起使用,以确保在其他规范更改时更新部署模板部分:

kind: Deployment
spec:
  template:
    metadata:
      annotations:
        checksum/config: {{ include (print $.Template.BasePath "/secret.yaml") . | sha256sum }}
[...]

在我的例子中,由于某些原因,$. template。BasePath没有工作,但$. chart。名称:

spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: admin-app
      annotations:
        checksum/config: {{ include (print $.Chart.Name "/templates/" $.Chart.Name "-configmap.yaml") . | sha256sum }}

其他回答

我也在这个问题上思考了一段时间,希望以一种优雅而快速的方式解决这个问题。

以下是我的20美分:

如果您正在更新标签,这里提到的使用标签的答案将不起作用。但如果你总是添加标签的话就可以了。详情请点击这里。 这里提到的答案是最优雅的方式来快速做到这一点,根据我,但有处理删除的问题。我在这个答案的基础上补充说:

解决方案

我在一个Kubernetes操作符中这样做,在一个调和循环中只执行一个任务。

Compute the hash of the config map data. Say it comes as v2. Create ConfigMap cm-v2 having labels: version: v2 and product: prime if it does not exist and RETURN. If it exists GO BELOW. Find all the Deployments which have the label product: prime but do not have version: v2, If such deployments are found, DELETE them and RETURN. ELSE GO BELOW. Delete all ConfigMap which has the label product: prime but does not have version: v2 ELSE GO BELOW. Create Deployment deployment-v2 with labels product: prime and version: v2 and having config map attached as cm-v2 and RETURN, ELSE Do nothing.

就是这样!它看起来很长,但这可能是最快的实现,并且原则上将基础设施视为牛(不可变性)。

此外,当您的Kubernetes部署有rebuild更新策略时,上述解决方案也可以工作。在其他情况下,逻辑可能需要稍作调整。

我发现最好的方法是运行Reloader

它允许您定义要监视的配置映射或秘密,当它们更新时,将执行部署的滚动更新。这里有一个例子:

你有一个部署foo和一个名为foo- ConfigMap的ConfigMap。您希望在每次更改configmap时滚动部署的pod。你需要运行Reloader:

kubectl apply -f https://raw.githubusercontent.com/stakater/Reloader/master/deployments/kubernetes/reloader.yaml

然后在部署中指定这个注释:

kind: Deployment
metadata:
  annotations:
    configmap.reloader.stakater.com/reload: "foo-configmap"
  name: foo
...

Helm 3文档页

通常情况下,配置映射或秘密作为配置文件注入到容器中。根据应用程序的不同,如果后续的头盔升级更新了这些配置,则可能需要重新启动,但如果部署规范本身没有更改,则应用程序将继续使用旧配置运行,从而导致部署不一致。

sha256sum函数可以与include函数一起使用,以确保在其他规范更改时更新部署模板部分:

kind: Deployment
spec:
  template:
    metadata:
      annotations:
        checksum/config: {{ include (print $.Template.BasePath "/secret.yaml") . | sha256sum }}
[...]

在我的例子中,由于某些原因,$. template。BasePath没有工作,但$. chart。名称:

spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: admin-app
      annotations:
        checksum/config: {{ include (print $.Chart.Name "/templates/" $.Chart.Name "-configmap.yaml") . | sha256sum }}

当部署在子图表中,而控制它的值在父图表的值文件中时,出现了这个问题。这是我们用来触发重启的:

spec:
  template:
    metadata:
      annotations:
        checksum/config: {{ tpl (toYaml .Values) . | sha256sum }}

显然,这将在任何值更改时触发重新启动,但它适用于我们的情况。最初在子图中的内容只有在配置。Yaml在子图中本身发生了变化:

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

另一种方法是将其插入部署的命令部分:

...
command: [ "echo", "
  option = value\n
  other_option = value\n
" ]
...

或者,为了使它更像configmap,使用一个额外的部署,它只会在命令节中托管该配置,并在其上执行kubectl create,同时在其名称中添加一个唯一的“版本”(比如计算内容的哈希值),并修改所有使用该配置的部署:

...
command: [ "/usr/sbin/kubectl-apply-config.sh", "
  option = value\n
  other_option = value\n
" ]
...

我可能会发布kubectl-apply-config.sh,如果它最终能够工作的话。

(不要那样做;看起来太糟糕了)