helm的基础操作

helm3 下载安装后为一个二进制执行文件，可以通过它去操作打包安装K8的各种资源对象（对于常规业务来说需要的为 deployment/service/ingress，其他组件会有PVC、SA、DS等其他组合情况）。以下是基础操作说明。

理解三个词

• image：镜像
• chart： helm的K8资源对象的组合产物包 一般存储在chart repo 仓库。
• release：helm的产物已安装在K8上。

前言密钥验签部分
就是执行 helm 的相关命令（install 或者 upgrade）时，会利用 sops 的 private key 将 helm_vars 目录下的加密内容解密，并且“存放在”values.yaml 文件中。在 chart中的 deployment.yaml 文件中引用 secret 然后secret 是以环境变量的形式注入到 pod 里面。
（也就是helm 在打包的时候会去读取 本地的 机器的kube上的secret的签名串然后以做成变量的形式打入到包里, 包去读取的时候在容器中是以变量的形式存在）

常见命令 HELM 官方手册文档地址 https://helm.sh/zh/docs/helm/helm/

以下是helm在运维开发过程中常见基础操作：

1.仓库认证
增加 一个别名为 test2的myproject仓库的地址，其中password、username 请输入自己的仓库用户密码。domain为仓库访问地址

 helm repo add --username ${username}  --password  ${password}   test2 https://${domain}/chartrepo/myproject

添加一个apisix的仓库
案例：

 helm repo add apisix https://charts.apiseven.com 

2.仓库列表展示（仅列已添加的仓库列表）

 helm repo list      

3.搜索可用版本的包

helm search repo apisix-dashboard

4.下载指定版本 （未指定则下载tag为last的chart包）

helm pull apisix/apisix-dashboard --version 0.4.0

5.创建项目（会默认生成K8资源对象的组合产物包 也就是常用内置对象：Release、Values、Chart、Files、Capabilities、Template）
项目名称不允许下划线 最好和K8的命名规范保持一致。否则会导致安装失败。

devops-cmdb-network 是我自己项目名称 生成的模板文件部分另外说

 helm create devops-cmdb-network

6.打包

helm package devops-cmdb-network

7.上传

helmpush devops-cmdb-network-0.1.0.tgz --username ${username} --password ${password}    https://${domain}/chartrepo/myproject

8.安装（myproject这个为1中的仓库别名）
devops 为 k8 命名空间 config 为 k8认证文件
如果不指定则 调用 本地用户 家目录下 kube中默认的认证文件。

helm install devops-cmdb-network myproject/devops-cmdb-network -n devops  --kubeconfig config

9.发布更新
-f 指定values文件发布。否则使用默认的values.yaml

helm upgrade devops-cmdb-network devops-cmdb-network-0.2.0.tgz -f ./devops-cmdb-network/values.yaml  -n devops  --kubeconfig config 

10.仓库更新
这个指本地同步远程仓库的数据，通常在发布前会同步一次，但是旧版本不能更新指定仓库， 在有外部镜像源的时候会导致更新异常缓慢，（我采用的是helm v3.9.0）具体支持版本可见官网。

helm repo update ${project_name}

11.卸载

helm uninstall ${k8s_app_name}  -n ${name_space} --kubeconfig config 

12.helm 历史查询release
-o 输出为json 方便解析， 也可以为yaml 。看个人

helm hist ${k8s_app_name}  -n ${name_space}  --kubeconfig='${kube_config_dir}' -o json

13.helm指定版本回滚

helm rollback --debug ${k8s_app_name} ${release_version}  -n ${name_space} --kubeconfig config

14.helm manifest 获取组件信息
后接管道也是为了方便代码调试获取信息。 可不加。

 helm get manifest ${k8s_app_name}  -n ${name_space}  --kubeconfig=config | kubectl  --kubeconfig=config -n ${name_space}  get -o json  -f -  

15.预发布检查

helm install --debug --dry-run ${k8s_app_name} ${project_name}/${repo_name}  -n ${name_space} --kubeconfig config

16其他参数说明
案例

helm install  ${k8s_app_name}  ${project_name}/${repo_name} -n  ${name_space} --kubeconfig config
--version ${version} -f ${values_file} --set-string istio.apiMetric.api[0].path=/test --set-string istio.apiMetric.api[0].method=GET  --set autoscaling.minReplicas=1,autoscaling.maxReplicas=1 

上面的 -n 空间 --kubeconfig 指定的集群 --version版本 -f 指定的values文件 -set-string 设置values中的某些参数 --set 设置 autoscaling.minReplicas和autoscaling.maxReplicas为1 ，后者是HPA的常规设置， 也就是说values的文件中的yaml数据 都可以–set动态指定。 优先 动态指定。其次 -f 文件中的值。

关于helm更新的后记。
helm为了确保最小化更新，所以每次upgrade 的时候如果你的image的版本是没有发生变化的话，它是不会触发K8重新拉取的。生产环境一定要对image的版本进行管理 更新，

这里简单说下K8的拉取策略

也就是K8会默认在本地缓存一份，如果你的镜像版本没改 导致里面的代码更新了，运气好 POD重新拉起获取的是旧镜像，运气不好那么新代码将更新到线上。

所以 建议更新版本方便后续回滚 否则 若需要回滚的版本和当前版本一致 且 宿主机未缓存 则拉取的是新版本的镜像， 此时需要依据历史pods的sha256的值进行回退，包括helm的包。