云原生Kubernetes：简化K8S应用部署工具Helm

一、理论

1.HELM

2.部署HELM2

3.部署HELM3

二、实验

1.部署 HELM2

2.部署HELM3

三、问题

1.api版本过期

2.helm初始化报错

3.pod状态为ImagePullBackOff

4.helm 命令显示 no repositories to show 的错误

5.Helm安装报错

6.git命令报错

7.CentOS 7 下git clone配置使用

8.签名密钥(signing keys)和认证密钥(authentication keys)的区别

9.make build 报错

10.查看helm的plugin路径

11.go 语言 proxy.golang.org timeout 无法访问

12.Go mod问题

四、总结

一、理论

1.HELM

（1）简介

Helm 是 Deis 开发的一个用于 Kubernetes 应用的包管理工具，主要用来管理 Charts。有点类似于 Ubuntu 中的 APT 或 CentOS 中的 YUM。Helm Chart 是用来封装 Kubernetes 原生应用程序的一系列 YAML 文件。可以在你部署应用的时候自定义应用程序的一些 Metadata，以便于应用程序的分发。对于应用发布者而言，可以通过 Helm 打包应用、管理应用依赖关系、管理应用版本并发布应用到软件仓库。对于使用者而言，使用 Helm 后不用需要编写复杂的应用部署文件，可以以简单的方式在 Kubernetes 上查找、安装、升级、回滚、卸载应用程序。

在 Kubernetes 中部署容器云的应用也是一项有挑战性的工作，Helm 就是为了简化在 Kubernetes 中安装部署容器云应用的一个客户端工具。通过 helm 能够帮助开发者定义、安装和升级 Kubernetes 中的容器云应用，同时也可以通过 helm 进行容器云应用的分享。在 Kubeapps Hub 中提供了包括 Redis、MySQL 和 Jenkins 等常见的应用，通过 helm 可以使用一条命令就能够将其部署安装在自己的 Kubernetes 集群中。

Helm 是管理 Kubernetes 包的工具，Helm 能提供下面的能力：

1）创建新的 charts(图表)
2）将 charts 打包成 tgz 文件
3）与 chart 仓库交互
4）安装和卸载 Kubernetes 的应用
5）管理使用 Helm 安装的 charts 的生命周期

（2）架构

Helm 架构由 Helm 客户端、Tiller 服务器端和 Chart 仓库所组成；Tiller 部署在 Kubernetes 中，Helm 客户端从 Chart 仓库中获取 Chart 安装包，并将其安装部署到 Kubernetes 集群中。

（3）重要概念

1）Charts：是创建 Kubernetes 应用实例的信息集合，也就是一个 helm 的程序包，它包含了运行一个 k8s 应用所有需要的镜像、依赖关系和资源定义等，必要时还会包含 Service 资源定义，它类似于 yum 的 rpm 文件
2）Repository：Chart 仓库，用于集中存储和分发 Charts。
3）Config：应用程序实例化安装时运行使用的配置信息
4）Release：chart 的运行实例，包含特定的 config

（4）组件

在 Helm 中有两个主要的组件，即 Helm 客户端和 Tiller 服务器。

① helm 客户端

它是一个供终端用户使用的命令行工具

客户端负责如下的工作：

1）本地 chart 开发
2）管理仓库
3）与 Tiller 服务器交互（发送需要被安装的 charts、请求关于发布版本的信息、请求更新或者卸载已安装的发布版本）

② Tiller 服务器

Tiller 是 helm 的服务器端，一般运行于 kubernetes 集群之上，定义 tiller 的 ServiceAccount，并通过 ClusterRoleBinding 将其绑定至集群管理员角色 cluster-admin，从而使得它拥有集群级别所有的最高权限

Tiller 服务器负责如下的工作：

1）监听来自于 Helm 客户端的请求
2）组合 chart 和配置来构建一个发布
3）在 Kubernetes 中安装，并跟踪后续的发布
4）通过与 Kubernetes 交互，更新或者 chart

（5）版本

区别：

Helm2是C/S架构，主要分为客户端helm和服务端Tiller; 与之前版本相同。
Helm3同样在Release页面提供了预编译好的二进制文件。
差别在于原先的二进制包下载下来你会看到helm和tiller 。而Helm3则只有helm的存在了。

Tiller主要用于在Kubernetes集群中管理各种应用发布的版本，在Helm3中移除了Tiller, 版本相关的数据直接存储在了Kubernetes中。

Helm2的问题：

Helm2的一个主要问题是需要在k8s集群里面运行一个服务端，而这就需要把tiller的端口暴露给外界，会产生安全隐患。

在helm 2中引入的tiller主要是当时k8s还没有RBAC机制，所以就引入了服务端tiller。

而后来k8s的功能相应完善，加入了RBAC和CRD等，都使得tiller这个东西显得多余。

Helm3：

helm3只有一个客户端，没有服务端，所以安装起来很方便，把相应的程序下下来即可，不需要helm init安装了。

相对于helm2，helm3有几大特性：
1）移除了tiller
2）支持分布式helm hub, 有了它就可以在很多时候不需要手动添加非官方repo了，例如helm3 search hub <package name>
3）为chart输入值进行json schema验证。
4）可以给helm charts添加test了，通过helm test <release>就能针对部署的应用跑一些tests。
5）部署的时候release name必须指定了，helm2的时候不指定会自动生成一个。
6）删除的时候不需要--purge了，删了就是删了。

Helm2到Helm3的迁移：

helm官方提供了一个小插件，帮助我们把已经部署的helm2应用迁移到helm3上。

安装插件
$ helm3 plugin install https://github.com/helm/helm-2to3
迁移helm2的配置，例如仓库
$ helm3 2to3 move config
迁移helm2部署的应用(确保helm2和helm3同时安装在同一台机器上)
$ helm3 2to3 convert <release-name> --delete-v2-releases

（6）HELM2常用命令

#查看版本
helm version
#查看当前安装的charts
helm list
#查询 charts
helm search nginx
#安装charts
helm install --name nginx --namespace test aliyun/nginx
#查看charts状态
helm status nginx
#删除charts
helm delete --purge nginx
#增加repo
helm repo add stable https://kubernetes.oss-cn-hangzhou.aliyuncs.com/charts
#更新repo仓库资源
helm repo update
#创建charts
helm create helm_charts
#测试charts语法
helm lint
#打包charts
cd helm_charts && helm package ./
#查看生成的yaml文件
helm template helm_charts-0.1.1.tgz
#更新image
helm upgrade --set image.tag=‘v2019-05-09-18-48-40’ study-api-en-oral myharbor/study-api-en-oral
#回滚relase
helm hist study-api-en-oral
helm rollback study-api-en-oral 4

(7) HELM3命令

（8）Helm 3不再存在的Helm 2的命令

在前面的示例中，发现helm init已经在Helm 3中不存在了。类似的共有如下7条命令，在Helm 3中或删除或改名或则功能增强，比如因为Tiller的去除，所以导致了reset命令没有存在的意义，同时init存在仅剩客户端需要设定的功能，所以被去除了。另外诸如fetch命令，而在Helm 3中提供了pull命令予以替代。本来home命令用于显示HELM_HOME环境变量，而在Helm 3中提供env命令可以显示所有的环境变量信息，用增强的功能予以了替换。但是无论如何，总之已经无法在Helm 3中直接使用如下7条命令。

（9）Helm 3:相较与Helm 2新增的命令

相较于Helm 2，从helm --help中获得的信息看到如下5条命令在Helm 3中为新增的命令。

说明如下：

env是对被删除的命令home的强化
pull是对被删除的命令fetch的替换
show是对被删除的命令inspect的替换
help命令本身在Helm 2时代就可以使用，只是helm --help里面没有显示，算是文档自包含的强化
uninstall是功能特性的增强

（10）Helm 3:命令说明发生变化

由于Tiller的移除，版本显示命令helm version的表述从显示client/server的版本信息变成了显示client的版本信息，类似的发生变化的共有5条命令，到底是文档的变化还是功能性的反映，在后续的文章中将继续通过实例进行进一步的说明。

（11）Helm版本支持策略

Helm | Helm版本支持策略

支持的版本

Helm的版本用 x.y.z 描述，x是主版本，y是次版本，z是补丁版本，遵循 语义化版本 术语。

Helm项目维护了一个针对最近次要版本的发布分支。适当的修复，包括安全修复、从发布分支中的cherry-pick， 视严重程度而定。更多细节请查看 Helm版本策略。

可支持的版本偏差

当一个Helm的新版本发布时，它是针对Kubernetes的一个特定的次版本编译的。比如，Helm 3.0.0 与Kubernetes的1.16.2的客户端版本交互，一次可以兼容Kubernetes 1.16。

从Helm 3开始，Helm 编译时假定与针对n-3版本的Kubernetes兼容。由于Helm 2对Kubernetes次版本变更的支持稍微严格一点， 则假定与Kubernetes的n-1版本兼容。

例如，如果在使用一个针对Kubernetes 1.17客户端API版本编译的Helm 3版本，那么它应该可以安全地使用Kubernetes 1.17， 1.16，1.15，以及1.14。如果您在使用一个针对Kubernetes 1.16客户端API版本编译的Helm 2版本，那么它应该可以安全地使用 Kubernetes 1.16 和 1.15。

不推荐将Helm用于比编译它所依赖的版本更高的Kubernetes版本，因为Helm并没有做出任何向前兼容的保证。

如果选择了一个Kubernetes版本不支持的Helm，需自负风险。

Helm版本与K8S集群兼容：

2.部署HELM2

（1）安装 helm 客户端

[root@master ~]# wget https://get.helm.sh/helm-v2.14.3-linux-amd64.tar.gz
[root@master ~]# tar zxvf helm-v2.14.3-linux-amd64.tar.gz    
[root@master ~]# mv linux-amd64/helm /usr/local/bin/
[root@master ~]# chmod +x /usr/local/bin/helm 
[root@master ~]# echo 'source <(helm completion bash)' >> /etc/profile
[root@master ~]# . /etc/profile

（2）安装 Tiller server（需要创建授权用户）

第一种方法：（K8s1.16以下版本）

#创建授权用户
[root@master ~]# vim tiller-rbac.yaml   
apiVersion: v1
kind: ServiceAccount
metadata:
  name: tiller
  namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
  name: tiller
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
  - kind: ServiceAccount
    name: tiller
    namespace: kube-system

[root@master ~]# kubectl apply -f tiller-rbac.yaml
[root@master ~]# helm init --service-account=tiller
[root@master ~]# kubectl get pod -n kube-system | grep tiller
[root@master ~]# kubectl edit pod tiller-deploy-8557598fbc-tvfsj -n kube-system
//编辑 pod 的 yaml 文件，将其使用的镜像改为国内阿里云的，默认是 Google 的镜像，下载不下来
//修改 spec 字段的 image 指定的镜像如下：
    image: gcr.io/kubernetes-helm/tiller:v2.14.3
//修改如下：
    image: registry.cn-hangzhou.aliyuncs.com/google_containers/tiller:v2.14.3
//修改后，保存退出即可，它会去自动下载新镜像（如果没有自动下载，就想办法吧，比如说在 tiller 容器所在的节点手动下载下来镜像，然后重启该节点的 kubelet，或重启该容器）
[root@master ~]# kubectl get pod -n kube-system | grep tiller
//只要保证 tiller 的 pod 正常运行即可
tiller-deploy-8557598fbc-m986t   1/1     Running   0          7m54s

第二种方法：（k8s1.16以上版本）

kubectl create serviceaccount --namespace kube-system tiller
kubectl create clusterrolebinding tiller --clusterrole=cluster-admin --serviceaccount=kube-system:tiller
helm init --service-account tiller --override spec.selector.matchLabels.'name'='tiller',spec.selector.matchLabels.'app'='helm' --output yaml | sed 's@apiVersion: extensions/v1beta1@apiVersion: apps/v1@' | kubectl apply -f -

[root@master ~]# kubectl get pod -n kube-system | grep tiller
[root@master ~]# kubectl edit pod tiller-deploy-8557598fbc-tvfsj -n kube-system
//编辑 pod 的 yaml 文件，将其使用的镜像改为国内阿里云的，默认是 Google 的镜像，下载不下来
//修改 spec 字段的 image 指定的镜像如下：
    image: gcr.io/kubernetes-helm/tiller:v2.14.3
//修改如下：
    image: registry.cn-hangzhou.aliyuncs.com/google_containers/tiller:v2.14.3
//修改后，保存退出即可，它会去自动下载新镜像（如果没有自动下载，就想办法吧，比如说在 tiller 容器所在的节点手动下载下来镜像，然后重启该节点的 kubelet，或重启该容器）
[root@master ~]# kubectl get pod -n kube-system | grep tiller
//只要保证 tiller 的 pod 正常运行即可
tiller-deploy-54d45574c4-zdt72    1/1     Running   0          7m54s

（3）配置 helm 仓库

[root@master ~]# helm repo list      //查看其仓库信息
NAME  	URL                                             
stable	https://kubernetes-charts.storage.googleapis.com
//如上，默认是 Google，在国外，速度特别慢
local 	http://127.0.0.1:8879/charts    
//执行下面命令，更改为国内阿里云的仓库
[root@master ~]# helm repo add stable https://kubernetes.oss-cn-hangzhou.aliyuncs.com/charts
[root@master ~]# helm repo list      //再次查看，可以发现更改生效了
NAME  	URL                                                   
stable	https://kubernetes.oss-cn-hangzhou.aliyuncs.com/charts
local 	http://127.0.0.1:8879/charts        
[root@master ~]# helm repo update    //更新一下 helm 仓库
[root@master ~]# helm version        //查看 helm 版本信息，必须保证可以查看出来 client 和 server，才可正常使用 helm
Client: &version.Version{SemVer:"v2.14.3", GitCommit:"0e7f3b6637f7af8fcfddb3d2941fcc7cbebb0085", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.14.3", GitCommit:"0e7f3b6637f7af8fcfddb3d2941fcc7cbebb0085", GitTreeState:"clean"}

（4）测试 helm 是否可以正常使用

[root@master ~]# helm search mysql      //搜索 MySQL
//查看到的是 charts 包文件，查出来的版本是 helm 的 Charts 包的版本
[root@master ~]# helm inspect stable/mysql    //查看其详细信息
[root@master ~]# helm fetch stable/mysql      //下载搜索到的包到本地
[root@master templates]# helm install stable/mysql     //在线安装这个 MySQL

如在线安装失败，需要更换stable repo源

[root@master1 ~]# helm repo add stable http://mirror.azure.cn/kubernetes/charts/
"stable" has been added to your repositories
您在 /var/spool/mail/root 中有新邮件
[root@master1 ~]# helm search mysql  
NAME                            	CHART VERSION	APP VERSION	DESCRIPTION                                                 
stable/mysql                    	1.6.9        	5.7.30     	DEPRECATED - Fast, reliable, scalable, and easy to use op...
stable/mysqldump                	2.6.2        	2.4.1      	DEPRECATED! - A Helm chart to help backup MySQL databases...
stable/prometheus-mysql-exporter	0.7.1        	v0.11.0    	DEPRECATED A Helm chart for prometheus mysql exporter wit...
stable/percona                  	1.2.3        	5.7.26     	DEPRECATED - free, fully compatible, enhanced, open sourc...
stable/percona-xtradb-cluster   	1.0.8        	5.7.19     	DEPRECATED - free, fully compatible, enhanced, open sourc...
stable/phpmyadmin               	4.3.5        	5.0.1      	DEPRECATED phpMyAdmin is an mysql administration frontend   
stable/gcloud-sqlproxy          	0.6.1        	1.11       	DEPRECATED Google Cloud SQL Proxy                           
stable/mariadb                  	7.3.14       	10.3.22    	DEPRECATED Fast, reliable, scalable, and easy to use open...
[root@master1 ~]# helm repo list
NAME  	URL                                      
stable	http://mirror.azure.cn/kubernetes/charts/

在线安装

[root@master1 ~]# helm install stable/mysql
NAME:   exegetical-lionfish
LAST DEPLOYED: Thu Oct  5 15:44:37 2023
NAMESPACE: default
STATUS: DEPLOYED

RESOURCES:
==> v1/ConfigMap
NAME                            DATA  AGE
exegetical-lionfish-mysql-test  1     1s

==> v1/Deployment
NAME                       READY  UP-TO-DATE  AVAILABLE  AGE
exegetical-lionfish-mysql  0/1    1           0          0s

==> v1/PersistentVolumeClaim
NAME                       STATUS   VOLUME  CAPACITY  ACCESS MODES  STORAGECLASS  AGE
exegetical-lionfish-mysql  Pending  0s

==> v1/Pod(related)
NAME                                       READY  STATUS   RESTARTS  AGE
exegetical-lionfish-mysql-8ffb45b5f-pfjr6  0/1    Pending  0         0s

==> v1/Secret
NAME                       TYPE    DATA  AGE
exegetical-lionfish-mysql  Opaque  2     1s

==> v1/Service
NAME                       TYPE       CLUSTER-IP    EXTERNAL-IP  PORT(S)   AGE
exegetical-lionfish-mysql  ClusterIP  10.96.248.54  <none>       3306/TCP  0s


NOTES:
MySQL can be accessed via port 3306 on the following DNS name from within your cluster:
exegetical-lionfish-mysql.default.svc.cluster.local

To get your root password run:

    MYSQL_ROOT_PASSWORD=$(kubectl get secret --namespace default exegetical-lionfish-mysql -o jsonpath="{.data.mysql-root-password}" | base64 --decode; echo)

To connect to your database:

1. Run an Ubuntu pod that you can use as a client:

    kubectl run -i --tty ubuntu --image=ubuntu:16.04 --restart=Never -- bash -il

2. Install the mysql client:

    $ apt-get update && apt-get install mysql-client -y

3. Connect using the mysql cli, then provide your password:
    $ mysql -h exegetical-lionfish-mysql -p

To connect to your database directly from outside the K8s cluster:
    MYSQL_HOST=127.0.0.1
    MYSQL_PORT=3306

    # Execute the following command to route the connection:
    kubectl port-forward svc/exegetical-lionfish-mysql 3306

    mysql -h ${MYSQL_HOST} -P${MYSQL_PORT} -u root -p${MYSQL_ROOT_PASSWORD}

3.部署HELM3

（1）下载helm3最新版本

可以从rancher国内仓库下载helm3工具

wget http://rancher-mirror.cnrancher.com/helm/v3.4.1/helm-v3.4.1-linux-amd64.tar.gz
tar -zxvf helm-v3.4.1-linux-amd64.tar.gz
cp linux-amd64/helm /usr/local/bin/helm3

确认helm版本

# helm3 version
WARNING: Kubernetes configuration file is group-readable. This is insecure. Location: /root/.kube/config
version.BuildInfo{Version:"v3.4.1", GitCommit:"c4e74854886b2efe3321e185578e6db9be0a6e29", GitTreeState:"clean", GoVersion:"go1.14.11"}

（2）安装helm-2to3插件

参考：https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/

第一种方法：（网页安装）

helm3 plugin install https://github.com/helm/helm-2to3

第二种方法：（源码安装）

yum install -y git

yum install -y go

$ mkdir -p ${GOPATH}/src/github.com/helm

$ cd $_

$ git clone git@github.com:helm/helm-2to3.git

$ cd helm-2to3

$ make build

$ export HELM_LINTER_PLUGIN_NO_INSTALL_HOOK=true

$ helm plugin install <your_path>/helm-2to3

（3）查看helm3插件

# helm3 plugin list
WARNING: Kubernetes configuration file is group-readable. This is insecure. Location: /root/.kube/config
NAME    VERSION DESCRIPTION                                                               
2to3    0.7.0   migrate and cleanup Helm v2 configuration and releases in-place to Helm v3

（4）迁移helm2配置至helm3

迁移helm2部署的应用(确保helm2和helm3同时安装在同一台机器上)

首先来检查可用的选项：

$ helm3 2to3 convert -h
migrate Helm v2 release in-place to Helm v3
 
Usage:
    2to3 convert [flags] RELEASE
 
Flags:
        --delete-v2-releases    v2 releases are deleted after migration. By default, the v2 releases are retained
        --dry-run               simulate a convert
    -h, --help                  help for convert
    -l, --label                 string label to select tiller resources by (default "OWNER=TILLER")
    -s, --release-storage       string v2 release storage type/object. It can be 'secrets' or 'configmaps'. This is only used with the 'tiller-out-cluster' flag (default "secrets")
    -t, --tiller-ns             string namespace of Tiller (default "kube-system")
        --tiller-out-cluster    when Tiller is not running in the cluster e.g. Tillerless

列出Helm v2的releases，并从中挑选一个用于迁移测试：

$ helm list

为了保证安全，我们先使用–dry-run 标志：

$ helm3 2to3 convert --dry-run postgres
NOTE: This is in dry-run mode, the following actions will not be executed.
Run without --dry-run to take the actions described below:
 
Release "postgres" will be converted from Helm 2 to Helm 3.
[Helm 3] Release "postgres" will be created.
[Helm 3] ReleaseVersion "postgres.v1" will be created.

执行真正的迁移工作：

$ helm3 2to3 convert postgres
Release "postgres" will be converted from Helm 2 to Helm 3.
[Helm 3] Release "postgres" will be created.
[Helm 3] ReleaseVersion "postgres.v1" will be created.
[Helm 3] ReleaseVersion "postgres.v1" created.
[Helm 3] Release "postgres" created.
Release "postgres" was converted successfully from Helm 2 to Helm 3. Note: the v2 releases still remain and should be removed to avoid conflicts with the migrated v3 releases.

检查是否迁移成功：

$ helm list

$ helm3 list

如果还有其他应用，需要一个个迁移过来

（6）清理helm2数据

注意：由于我们并没有指定 --delete-v2-releases 标志，所以Helm v2 的postgres release仍然保留了下来，以后我们可以使用kubectl命令来删除它。

迁移时直接删除helm2 release。

helm3 2to3 convert <release-name> --delete-v2-releases

当已经准备好了迁移你所有的releases时，可以在一个循环中自动运行它，以应用helm3 2to3 转换每一个Helm v2对应的release。

注意，这一步将会删除tiller pod以及helm2在主机上相关文件，执行之后无法还原，如果不确定可以先不执行

helm3 2to3 cleanup

二、实验

1.部署 HELM2

（1）安装 helm 客户端

（2）安装 Tiller server（需要创建授权用户）

使用第二种方法（k8s 1.16以上版本）

编辑 pod 的 yaml 文件，将其使用的镜像改为国内阿里云的

修改 spec 字段的 image 指定的镜像如下：

tiller 的 pod 正常运行

（3）配置 helm 仓库

（4）测试 helm 是否可以正常使用

搜索 MySQL，查看到的是 charts 包文件，查出来的版本是 helm 的 Charts 包的版本

查看其详细信息

下载搜索到的包到本地

在线安装这个 MySQL，如遇到报错需要更换stable repo源

安装

2.部署HELM3

（1）下载helm3最新版本

可以从rancher国内仓库下载helm3工具

确认helm版本

（2）安装helm-2to3插件

采用第二种方法：（源码安装）

（3）更新repo源

查看repo源

三、问题

1.api版本过期

（1）问题

（2）原因分析

api已经过期了,因为现在使用的是1.20版本，有的api版本已经过期，需要修改下

（3）解决方法

rbac.authorization.k8s.io/v1beta1 
改为：
rbac.authorization.k8s.io/v1

修改前：

修改后：

成功：

2.helm初始化报错

（1）报错

k8s主节点部署helm（版本：v2.14.3），初始化报错

（2）原因分析

第一种原因：

因访问权限原因导致

第二种原因：

仓库地址变更

https://kubernetes-charts.storage.googleapis.com/index.yaml 已经弃用，
新的仓库是：
https://charts.helm.sh/stable

第三种原因：

参考：Helm · Kubernetes指南 (gitbooks.io)

对于 Kubernetes v1.16.0 以上的版本，有可能会碰到 Error: error installing: the server could not find the requested resource 的错误。这是由于 extensions/v1beta1 已经被 apps/v1 替代。

（3）解决方法

第一种方法：

创建丢失文件，再次执行helm init 即可

echo "" > /root/.helm/repository/repositories.yaml

第二种方法：

修改仓库地址

#tiller服务端
helm init --stable-repo-url=https://charts.helm.sh/stable --service-account=tiller

#client客户端
helm init --stable-repo-url=https://charts.helm.sh/stable --client-only

第三种方法：

kubectl create serviceaccount --namespace kube-system tiller
kubectl create clusterrolebinding tiller --clusterrole=cluster-admin --serviceaccount=kube-system:tiller
helm init --service-account tiller --override spec.selector.matchLabels.'name'='tiller',spec.selector.matchLabels.'app'='helm' --output yaml | sed 's@apiVersion: extensions/v1beta1@apiVersion: apps/v1@' | kubectl apply -f -

这里采用第三种方法：

3.pod状态为ImagePullBackOff

（1）报错

（2）原因分析

查看pod的事件

[root@master2 ~]# kubectl describe pod tiller-deploy-54d45574c4-zdt72 -n kube-system
Name:         tiller-deploy-54d45574c4-zdt72
Namespace:    kube-system
Priority:     0
Node:         node1/192.168.204.182
Start Time:   Thu, 05 Oct 2023 14:43:44 +0800
Labels:       app=helm
              name=tiller
              pod-template-hash=54d45574c4
Annotations:  cni.projectcalico.org/podIP: 10.244.166.148/32
              cni.projectcalico.org/podIPs: 10.244.166.148/32
Status:       Pending
IP:           10.244.166.148
IPs:
  IP:           10.244.166.148
Controlled By:  ReplicaSet/tiller-deploy-54d45574c4
Containers:
  tiller:
    Container ID:   
    Image:          gcr.io/kubernetes-helm/tiller:v2.14.3
    Image ID:       
    Ports:          44134/TCP, 44135/TCP
    Host Ports:     0/TCP, 0/TCP
    State:          Waiting
      Reason:       ImagePullBackOff
    Ready:          False
    Restart Count:  0
    Liveness:       http-get http://:44135/liveness delay=1s timeout=1s period=10s #success=1 #failure=3
    Readiness:      http-get http://:44135/readiness delay=1s timeout=1s period=10s #success=1 #failure=3
    Environment:
      TILLER_NAMESPACE:    kube-system
      TILLER_HISTORY_MAX:  0
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from tiller-token-fj88w (ro)
Conditions:
  Type              Status
  Initialized       True 
  Ready             False 
  ContainersReady   False 
  PodScheduled      True 
Volumes:
  tiller-token-fj88w:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  tiller-token-fj88w
    Optional:    false
QoS Class:       BestEffort
Node-Selectors:  <none>
Tolerations:     node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
                 node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
  Type     Reason     Age                  From               Message
  ----     ------     ----                 ----               -------
  Normal   Scheduled  15m                  default-scheduler  Successfully assigned kube-system/tiller-deploy-54d45574c4-zdt72 to node1
  Normal   Pulling    12m (x4 over 15m)    kubelet            Pulling image "gcr.io/kubernetes-helm/tiller:v2.14.3"
  Warning  Failed     12m (x4 over 14m)    kubelet            Failed to pull image "gcr.io/kubernetes-helm/tiller:v2.14.3": rpc error: code = Unknown desc = Error response from daemon: Get https://gcr.io/v2/: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)
  Warning  Failed     12m (x4 over 14m)    kubelet            Error: ErrImagePull
  Normal   BackOff    5m7s (x33 over 14m)  kubelet            Back-off pulling image "gcr.io/kubernetes-helm/tiller:v2.14.3"
  Warning  Failed     8s (x53 over 14m)    kubelet            Error: ImagePullBackOff
[root@master2 ~]#

获取 gcr.io/kubernetes-helm/tiller:v2.14 镜像失败。

（3）解决方法

修改前：

修改后：

成功：

4.`helm` 命令显示 `no repositories to show` 的错误

（1）报错

（2）原因分析

没有添加任何 Helm 仓库。

（3）解决方法

添加一个 Helm 仓库，可以使用以下命令添加官方的 Helm 仓库：

helm repo add stable https://kubernetes.oss-cn-hangzhou.aliyuncs.com/charts

helm repo add stable https://charts.helm.sh/stable

5.Helm安装报错

（1）报错

（2）原因分析

ali的非最新版本，有的是手动改，有的是用shell改，根本原因还是chart源没有实时更新以匹配k8s版本。

（3）解决方法

更换stable repo源，这里使用的是azure的：

helm repo add stable http://mirror.azure.cn/kubernetes/charts/

成功：

6.git命令报错

（1）报错

当服务器git clone远程仓库的时候出现-bash: git: 未找到命令

（2）原因分析

需要安装git

（3）解决方法

安装git

yum install -y git

再执行git clone

7.CentOS 7 下git clone配置使用

（1）报错

（2）原因分析

未认证授权

（3）解决方法

①检查git是否安装和配置用户名和邮箱

git --version

git config --global user.name “你的名称”
git config --global user.email “你的邮箱”
git config --global user.password “xxxxx密码”

查看配置

git config --list

②检查是否已安装ssh key

$ cd ~/.ssh
$ ls

检查是否已经存在 id_rsa.pub 或 id_dsa.pub 文件，如果文件已经存在，那么你可以跳过步骤2，直接进入步骤3

③ 创建一个ssh key

$ ssh-keygen -t rsa

一路回车，执行完后再检查就发现已经有了 id_rsa.pub 或 id_dsa.pub文件

④添加ssh key到github上

使用cat命令查看id_rsa.pub文件内容，并复制下来

$ cat id_rsa.pub

登录github账户，点击右上角头像 - setting - SSH and GPG keys - New SSH key

测试 SSH key

ssh -T git@github.com

⑤git clone@git

git clone git@github.com:helm/helm-2to3.git

成功：

8.签名密钥(signing keys)和认证密钥(authentication keys)的区别

（1）问题

登录github账户，点击右上角头像 - setting - SSH and GPG keys - New SSH key，出现Key type选项，共有2个：

Authentication key 和Signing Key

（2）分析

The difference between signing keys and authentication keys is that :
•	signing keys can be used to sign Git commits
•	authentication keys can be used to access repositories.
•	If you add a key as only one type, then it can be used only for that purpose, but the same key may be added for both.

翻译为：

1.	签名密钥用于签名 Git 提交(commit)和标签(tag)，用于验证提交者身份。
2.	认证密钥用于访问仓库(repository)，实现免密码 git 操作。
如果只添加一种类型的密钥，那么它只能用于对应的用途:
•	只添加签名密钥,可以用于签名提交,但不能用于 SSH 访问
•	只添加认证密钥,可以用于 SSH 访问,但不能用于签名提交
•	但是,同一个密钥可以同时添加为两种类型,既可用于签名提交,也可用于 SSH 访问。

（3）小结

1.	签名密钥用于验证 Git 操作的身份
2.	认证密钥用于访问 Git 仓库和免密码操作
3.	同一把密钥可以同时用作签名密钥和认证密钥
4.	添加密钥类型决定了它可以用于的用途

9.make build 报错

（1）报错

（2）原因分析

未安装go

（3）解决方法

安装go

yum install -y go

成功：

10.查看helm的plugin路径

（1）问题

无法确认helm安装插件位置

 helm plugin install <your_path>/helm-2to3

（2）分析

helm命令查询

（3）解决方法

#helm2命令
helm home
/root/.helm

#helm3命令
helm3 env
……
HELM_PLUGINS="/root/.local/share/helm/plugins"
……

Helm2命令查询

Helm3命令查询

11.go 语言 proxy.golang.org timeout 无法访问

（1）报错

（2）原因分析

go包管理网址无法访问，默认使用的是proxy.golang.org，在国内无法访问

（3）解决方法

换一个国内能访问的代理地址：https://goproxy.cn

go env -w GOPROXY=https://goproxy.cn

查看go环境

成功：

12.Go mod问题

（1）报错

（2）原因分析

这个通常是因为 Go 的版本不同导致的，

（3）解决方法

在使用 Go 1.13 以上的版本，通过 GOSUMDB 的环境变量调整就可以了。

export GOSUMDB=off
go mod download

四、总结

HELM有点类似于 Ubuntu 中的 APT 或 CentOS 中的 YUM。

Charts是创建 Kubernetes 应用实例的信息集合，也就是一个 helm 的程序包，它包含了运行一个 k8s 应用所有需要的镜像、依赖关系和资源定义等，必要时还会包含 Service 资源定义，它类似于 yum 的 rpm 文件。

HELM v3版本与v2版本的架构变化

1. 最大的改动就是移除了 Tiller 组件，所有功能都通过 Helm CLI 与 ApiServer 直接交互。
2. release在v3版本中可以实现不同的namespace空间中重用；
3. 可以将chart推入到docker仓库中。

HELM3特性：

一、新的功能
1.版本以新格式存储
2.没有群集内（tiller）组件
3.Helm 3包括对新版Helm图表的支持（图表v2）
4.Helm 3还支持库图表-图表主要用作其他图表的资源。
5.用于在OCI注册表中存储Helm图表的实验支持（例如Docker Distribution）可以进行试。
6.现在在升级Kubernetes资源时将应用3向战略合并补丁。
7.现在可以根据JSON模式验证图表提供的值
8.为了使Helm更安全，可用和健壮，已进行了许多小的改进。

二、 Helm3的内部实现已从 Helm2发生了很大变化，使其与 Helm2不兼容
该版本主要变化如下
1. 最明显的变化是 Tiller的删除
2. Release 不再是全局资源，而是存储在各自命名空间内
3. Values 支持 JSON Schema校验器，自动检查所有输入的变量格式
4. 移除了用于本地临时搭建 Chart Repository 的 helm serve 命令。
5. helm install 不再默认生成一个 Release 的名称，除非指定了 --generate-name。
6. Helm CLI 个别更名,但旧的命令当前仍能使用。
  （1） helm delete更名为 helm uninstall
  （2） helm inspect更名为 helm show
  （3） helm fetch更名为 helm pull