玩转 Helm 之 upgrade
0. 前言
在 玩转 Helm 一文中,简略提到了 Helm upgrade 的策略。
在实际项目开发上,upgrade 多是调研的重点。基于此,这里对 upgrade 继续展开。
1. basic helm upgrade
升级 Release 查看升级情况:
1.1 helm install 部署 Release
$ helm list
NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION
lubanseven ci1 1 2022-04-26 14:32:08.74504337 +0000 UTC deployed lubanseven-0.1.0 0.1.0
查看 manifest:
spec:
replicas: 1
1.2 helm upgrade lubanseven
// 更新 values.yaml replicas: 2
$ helm upgrade -f values.yaml lubanseven .
查看 manifest:
spec:
replicas: 2
1.3 helm rollback lubanseven
$ helm list
NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION
lubanseven ci1 2 2022-04-26 14:39:17.027072285 +0000 UTC deployed lubanseven-0.1.0 0.1.0
$ helm rollback lubanseven 1
注意:
- 这里 revision id 是对 lubanseven 的记录,每执行一次 lubanseven,id 会自增 1。
- 除了对 values.yaml 改动的升级,也可以对 chart 的改动做升级。helm upgrade 背后是解析,比对 manifest 查看资源更新情况,并将更新情况发给 kubernetes 处理。
2. 三路升级策略
基本的升级场景看完,继续看 helm upgrade 的三路升级策略。
如果 manifest 前后不变,helm 在做升降级的时候会对 Release 做改动吗?这在 helm2 答案是不会,在 helm3 中引入了三路策略,可以通过补丁的方式实现升级。
场景如下(该场景引自 这里):
- 部署 Release
- scale pod 数为 0。(这里 manifest 前后未改动)
- helm rollback Release
在 helm2 中,当第二步 scale pod 时,manifest 并未改动,此时 pod 为 0,当 rollback 时,由于 manifest 并未改动,pod 数还是保持为 0,而不是回到原来的 pod 数。
helm3 使用三路升级策略对此进行了改进,我们根据这里做了测试,验证了这一策略的有效性。具体不展开了,更多可参考 这里
3. configmap 改动升级
试想一种场景,升级时 configmap 改动的情况。如果升级的时候 configmap 改动了,那升级后 pod 内使用的是原有的 configmap 还是旧的 configmap 呢。
我们做了简单的测试,发现当改动 configmap 时,pod 内的内容会相应改动,意味着升级回滚都会用改动的 configmap,为什么会这样呢?
configmap 以 volume 的形式挂载到 pod 内,挂载是以 联合文件系统 的方式挂载的。对 volume 的改动会同步反映到 pod 内,
这一过程解析了为什么 configmap 对升级无影响,无影响指的是升级前后都用最新的改动 configmap。
4. 总结
对于升级场景的调研是复杂的,它不仅涉及到应用内部的处理,也涉及到外部资源,升级流程。
对升级流程简单给了一个场景,重点是想说明升级前后 manifest 的变化。
对外部资源,讨论了 configmap 改动对升级的影响,当然影响不止于这一点还有 labels 等资源,这里不一一讨论,有需要再谈。