玩转 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 等资源，这里不一一讨论，有需要再谈。
标签：改动,upgrade,configmap,升级,helm,玩转,Helm,lubanseven 来源： https://www.cnblogs.com/xingzheanan/p/16198482.html