helm upgrad 和 helm rollback

helm upgrad 和 helm rollback

前置变量：

helm repo add stable https://charts.helm.sh/stable 
helm show values stable/tomcat
helm install stable/tomcat --generate-name
helm list

当你想升级到 chart 的新版本，或是修改 release 的配置，你可以使用 helm upgrade 命令。Helm 会
尝试执行最小侵入式升级。即它只会更新自上次发布以来发生了更改的内容

我们来演试一下：

[root@master helm]# cat values.yaml 
service:
  type: ClusterIP

执行：

helm upgrade -f values.yaml tomcat-1769138869 stable/tomcat

在上面的例子中， tomcat-1769138869 这个 release 使用相同的 chart 进行升级，但是使用了一个新的
YAML 文件：

service:
  type: ClusterIP

我们可以使用 helm get values 命令来看看配置值是否真的生效了

helm get values tomcat-1769138869

现在，假如在一次发布过程中，发生了不符合预期的事情，也很容易通过 helm rollback [RELEASE]
[REVISION] 命令回滚到之前的发布版本

helm rollback tomcat-1769138869 

上面这条命令将我们的 apache-23213213 回滚到了它最初的版本。release 版本其实是一个增量修订
（revision）。 每当发生了一次安装、升级或回滚操作，revision 的值就会加1。

第一次 revision 的值
永远是1。我们可以使用 helm history [RELEASE] 命令来查看一个特定 release 的修订版本号

helm get values tomcat-1769138869

安装、升级、回滚时的有用选项

--timeout：一个 Go duration 类型的值， 用来表示等待 Kubernetes 命令完成的超时时间，默认
值为 5m0s。such as "300ms", "-1.5h" or "2h45m". Valid time units are "ns", "us" (or "µs"),
"ms", "s", "m", "h"。

--wait：表示必须要等到所有的 Pods 都处于 ready 状态，PVC 都被绑定，Deployments 都至少拥
有最小 ready 状态 Pods 个数（Desired减去 maxUnavailable），并且 Services 都具有 IP 地址
（如果是LoadBalancer， 则为 Ingress），才会标记该 release 为成功。最长等待时间由 --
timeout 值指定。如果达到超时时间，release 将被标记为 FAILED。注意：当 Deployment 的
replicas 被设置为1，但其滚动升级策略中的 maxUnavailable 没有被设置为0时，--wait 将返回就
绪，因为已经满足了最小 ready Pod 数

--no-hooks ：不运行当前命令的钩子，即为安装此 chart 时的已定义的安装前或者安装后的动作
--recreate-pods：（仅适用于 upgrade 和 rollback ）：这个参数会导致重建所有的
Pod（deployment中的Pod 除外）。（在 Helm 3 中已被废弃）

欢迎来撩 ： 汇总all