k8s之helm的小知识

现在helm基本已经是k8s应用发布的标配了，下面整理了一些小知识

一、v2和v3有什么区别？

1、移除tiller

v2版本： helm通过tiller组件与apiserver去交互的，tiller是需要部署在k8s中的
v3版本： helm直接通过kubeconfig去和apiserver通信了，精简了tiller，稳定性和性能貌似更好了

2、删除一个release的命令改变

v3版本中不需要指定--purge了，默认就自带这个参数了

v2版本：  helm  delete   test_release  --purge
v3版本：  helm  uninstall test_release

3、查看charts信息的命令改变

只是更改了一个单词，结果看起来好像一样

v2版本:    helm inspect  release-name
v3版本:    helm  show   release-name

4、拉取chart包的命令改变

只是改了一个单词，变得和docker类似

v2版本:    helm fetch chart-name
v3版本:    helm  pull  chart-name

5、可命名相同名称的release

v2版本： release名称具有唯一性，不能存在相同名称的release
v3版本： release名称可以相同，用不同的namespace区分

5、部署release时候需要指定名称

v2版本:  不需要指定
v3版本:  helm install  test_release ./mychart

 6、release信息存储的命名空间改变

v2版本： 存储在tiller命名空间下，所以release名称不能相同
v3版本： 没有tiller，存储在release实例对应的命名空间下，所以在不同命名空间，可能存在相同名称的release

二、使用helm镜像应用升级时，镜像的tag不要用latest

曾经搞过一个第三方的k8s集群,那边规划的应用镜像tag为latest，每次发布的时候会把镜像升级，然后覆盖打上latest标签，然后就开始了入坑之旅

同类应用使用同一模版，用不通的yam来控制变量

1、更新镜像后覆盖latest标签，然后执行应用发布，我这里chart部署是statefulset应用

helm upgrade -f xxx.yaml  test_release  harbor/mychart -n dev

执行以后，statefulset没什么动静，pod也没有滚动的迹象，k8s竟然没有重新编排！因为helm的配置并没有改动，如果镜像拉取规则是Always，手动进行滚动可以实现，如果是IfNotPresent，那么此方法不能进行升级，且容易受到本地的镜像伪装攻击。

2、尝试加入--set image.tag=latest

helm upgrade -f xxx.yaml  --set image.tag=latest test_release  harbor/mychart -n dev

奇怪的事情来了，执行以后只会升级标识为0的pod，即使我重新设置了滚动更新策略

updateStrategy:
    type: RollingUpdate
    rollingUpdate:
      partition:  0

最后效果并不管用，k8s编排完全无视了我的这个设置，所以还是无法正常的发布应用的。

3、尝试加入 --set image.tag=2021-04-25-12-00-00 (随便设置了个时间戳)

helm upgrade -f xxx.yaml  --set image.tag=2021-04-25-12-00-00 test_release  harbor/mychart -n dev

发现应用可以正常滚动升级

建议使用helm进行应用发布时，镜像版本千万不要用latest！