MIUI|Kubernetes配置热更新的两种方式

MIUI|Kubernetes配置热更新的两种方式
文章图片
MIUI|Kubernetes配置热更新的两种方式
文章图片

背景任何应用都需要一些特定的配置项 , 用来自定义应用的特性 。 这些配置通常可以分为两类:

  • 一类是诸如运行环境和外部依赖等非敏感配置
  • 一类是诸如密钥和 SSH 证书等敏感配置 。
这些配置不应该直接放到容器镜像中 , 而是应该配配置与容器分离 , 通过数据卷、环境变量等方式在运行时动态挂载 。
在我们使用kubernetes的过程中 , 通常都会将应用的配置文件放到ConfigMap或/和Secret中 , 但是也经常碰到配置文件更新后如何让其生效的问题 。
用户定义Kubernetes的资源对象(例如Deployment、Daemonset 等) , 配置文件以configmap定义 , 通过Volumemounts进行挂载到Pod里 , 配置文件修改以后 , 服务可以自动reload加载更新配置 。
解决方案2.1 Reloader
  • 限制条件:Kubernetes版本在1.9以及以上
  • 集群安装reloader
  • 通过添加注解annotation的方式实现
2.1.1 全局 configmap 触发更新
2.1.2 按照指定的 configmap 变更自动触发资源对象的配置更新
  • 单 ConfigMap 更新

  • 【MIUI|Kubernetes配置热更新的两种方式】多 configmap , 以逗号对多个 configmap 进行隔离

2.2 checksum 注解checksum 注解是 Helm Charts 中最常用的滚动更新方法 , 即在 Deployment 的 annotations 中加上 Secret 或者 ConfigMap 的 sha256sum , 这样已有的 Pod 就会随着 Secret 或者 ConfigMap 的变更而更新 。
添加这一节的效果就是 , 在/configmap.yaml中有任何内容改变 , 都会导致Deployment的sepc下的annotation被更新 , 进而驱动重建pod , 达到我们想要的效果 。
作者:Honest1y
链接:https://juejin.cn/post/6993128314055426084
来源:掘金

    相关经验推荐