当它们的configmap被更改/更新时,我如何自动重新启动Kubernetes pod和与部署相关的pod ?
我知道有关于在配置映射发生变化时自动重启pod的讨论,但据我所知,这在Kubernetes 1.2中还没有。
因此(我认为)我想做的是“滚动重新启动”与使用配置映射的pod相关联的部署资源。在Kubernetes中,在不改变实际模板的情况下强制滚动重启部署是否可能?如果可能的话,如何实现?这是目前最好的方式还是有更好的选择?
当它们的configmap被更改/更新时,我如何自动重新启动Kubernetes pod和与部署相关的pod ?
我知道有关于在配置映射发生变化时自动重启pod的讨论,但据我所知,这在Kubernetes 1.2中还没有。
因此(我认为)我想做的是“滚动重新启动”与使用配置映射的pod相关联的部署资源。在Kubernetes中,在不改变实际模板的情况下强制滚动重启部署是否可能?如果可能的话,如何实现?这是目前最好的方式还是有更好的选择?
当前回答
在配置映射更新时向pod发送信号是一个正在工作的功能(https://github.com/kubernetes/kubernetes/issues/22368)。
你总是可以写一个自定义的pid1来通知confimap已经改变并重新启动你的应用程序。
您还可以例如:在两个容器中挂载相同的配置映射,在第二个容器中暴露一个http健康检查,如果配置映射内容的哈希值发生变化,该检查将失败,并将其作为第一个容器的活动探测(因为pod中的容器共享相同的网络名称空间)。当探测失败时,kubelet将为您重新启动第一个容器。
当然,如果您不关心pod在哪些节点上,您可以简单地删除它们,复制控制器将为您“重新启动”它们。
其他回答
另一种方法是将其插入部署的命令部分:
...
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,如果它最终能够工作的话。
(不要那样做;看起来太糟糕了)
向配置映射添加不可变属性完全避免了这个问题。使用配置散列有助于无缝滚动更新,但对回滚没有帮助。你可以看看这个开源项目- 'Configurator' - https://github.com/gopaddle-io/configurator.git .'Configurator'通过以下使用自定义资源工作:
配置器将部署生命周期与configMap绑定在一起。当 配置映射被更新,并为此创建一个新版本 configMap。所有附加到configMap的部署 获得与最新configMap版本绑定的滚动更新。 当您将部署回滚到旧版本时,它会反弹到 configMap在滚动更新之前的版本。
通过这种方式,您可以维护配置映射的版本,并方便与配置映射一起滚转和回滚到部署。
考虑使用kustomize(或kubectl apply -k),然后利用它强大的configMapGenerator特性。例如,来自:https://kubectl.docs.kubernetes.io/references/kustomize/kustomization/configmapgenerator/
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
# Just one example of many...
- name: my-app-config
literals:
- JAVA_HOME=/opt/java/jdk
- JAVA_TOOL_OPTIONS=-agentlib:hprof
# Explanation below...
- SECRETS_VERSION=1
然后在部署中引用my-app-config即可。当使用kustomize构建时,它会自动查找并更新my-app-config的引用,并使用更新的后缀,例如my-app-config-f7mm6mhf59。
额外的好处是,更新秘密:我还使用此技术强制重新加载秘密(因为它们以同样的方式受到影响)。虽然我个人完全单独管理我的秘密(使用Mozilla sops),但您可以将配置映射与您的秘密捆绑在一起,例如在您的部署中:
# ...
spec:
template:
spec:
containers:
- name: my-app
image: my-app:tag
envFrom:
# For any NON-secret environment variables. Name is automatically updated by Kustomize
- configMapRef:
name: my-app-config
# Defined separately OUTSIDE of Kustomize. Just modify SECRETS_VERSION=[number] in the my-app-config ConfigMap
# to trigger an update in both the config as well as the secrets (since the pod will get restarted).
- secretRef:
name: my-app-secrets
然后,像我上面所做的那样,在ConfigMap中添加一个像SECRETS_VERSION这样的变量。然后,每次更改my-app-secrets时,只需增加SECRETS_VERSION的值,这除了触发kustomize'd ConfigMap名称的更改外,没有其他用途,这也应该导致重新启动pod。然后就变成:
在配置映射更新时向pod发送信号是一个正在工作的功能(https://github.com/kubernetes/kubernetes/issues/22368)。
你总是可以写一个自定义的pid1来通知confimap已经改变并重新启动你的应用程序。
您还可以例如:在两个容器中挂载相同的配置映射,在第二个容器中暴露一个http健康检查,如果配置映射内容的哈希值发生变化,该检查将失败,并将其作为第一个容器的活动探测(因为pod中的容器共享相同的网络名称空间)。当探测失败时,kubelet将为您重新启动第一个容器。
当然,如果您不关心pod在哪些节点上,您可以简单地删除它们,复制控制器将为您“重新启动”它们。
如何自动重启Kubernetes pod和相关的pod 当他们的configmap改变/更新部署?
如果您使用configmap作为环境,则必须使用外部选项。
复载机 Kube观察家 配置器
Kubernetes自动重新加载配置映射,如果它被挂载为卷(如果子路径在那里,它不会工作)。
When a ConfigMap currently consumed in a volume is updated, projected keys are eventually updated as well. The kubelet checks whether the mounted ConfigMap is fresh on every periodic sync. However, the kubelet uses its local cache for getting the current value of the ConfigMap. The type of the cache is configurable using the ConfigMapAndSecretChangeDetectionStrategy field in the KubeletConfiguration struct. A ConfigMap can be either propagated by watch (default), ttl-based, or by redirecting all requests directly to the API server. As a result, the total delay from the moment when the ConfigMap is updated to the moment when new keys are projected to the Pod can be as long as the kubelet sync period + cache propagation delay, where the cache propagation delay depends on the chosen cache type (it equals to watch propagation delay, ttl of cache, or zero correspondingly).
正式文档:https://kubernetes.io/docs/concepts/configuration/configmap/#mounted-configmaps-are-updated-automatically
作为环境变量使用的configmap不会自动更新,并且需要pod重新启动。
简单示例
apiVersion: v1
kind: ConfigMap
metadata:
name: config
namespace: default
data:
foo: bar
舱配置
spec:
containers:
- name: configmaptestapp
image: <Image>
volumeMounts:
- mountPath: /config
name: configmap-data-volume
ports:
- containerPort: 8080
volumes:
- name: configmap-data-volume
configMap:
name: config
例如:https://medium.com/@harsh.manvar111/update-configmap- with-restart -pod-56801dce3388