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

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 
3）为chart输入值进行json schema验证。
4）可以给helm charts添加test了，通过helm test 就能针对部署的应用跑一些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  --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         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（2to3方式）

（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 /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  --delete-v2-releases

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

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

helm3 2to3 cleanup

4.部署HELM3（单独安装）

（1）部署


1、安装 helm 
//下载二进制 Helm client 安装包
https://github.com/helm/helm/tags
 
tar -zxvf helm-v3.6.0-linux-amd64.tar.gz
mv linux-amd64/helm /usr/local/bin/helm
helm version
 
//命令补全
source <(helm completion bash)
 
2、使用 helm 安装 Chart
//添加常用的 chart 仓库，
helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo add stable http://mirror.azure.cn/kubernetes/charts
helm repo add aliyun https://kubernetes.oss-cn-hangzhou.aliyuncs.com/charts
helm repo add incubator https://charts.helm.sh/incubator
 
//更新 charts 列表
helm repo update          
helm repo list
 
//查看 stable 仓库可用的 charts 列表
helm search repo stable
 
//删除 incubator 仓库
helm repo remove incubator
 
//查看 chart 信息
helm show chart stable/mysql     #查看指定 chart 的基本信息
 
helm show all stable/mysql		 #获取指定 chart 的所有信息
 
//安装 chart
helm install my-redis bitnami/redis [-n default]   #指定 release 的名字为 my-redis，-n 指定部署到 k8s 的 namespace
 
helm install bitnami/redis --generate-name    #不指定 release 的名字时，需使用 –generate-name 随机生成一个名字
 
//查看所有 release
helm ls 
helm list
 
//查看指定的 release 状态
helm status my-redis               
 
//删除指定的 release
helm uninstall my-redis

（2）Helm 自定义模板


charts 除了可以在 repo 中下载，还可以自己自定义，创建完成后通过 helm 部署到 k8s。
 
//拉取 chart
mkdir /opt/helm
cd /opt/helm
 
helm pull stable/mysql
 
ls
mysql-1.6.9.tgz
 
tar xf mysql-1.6.9.tgz
 
yum install -y tree
 
tree mysql
mysql
├── Chart.yaml
├── README.md
├── templates
│   ├── configurationFiles-configmap.yaml
│   ├── deployment.yaml
│   ├── _helpers.tpl
│   ├── initializationFiles-configmap.yaml
│   ├── NOTES.txt
│   ├── pvc.yaml
│   ├── secrets.yaml
│   ├── serviceaccount.yaml
│   ├── servicemonitor.yaml
│   ├── service.yaml
│   ├── ingress.yaml
│   └── tests
│       ├── test-configmap.yaml
│       └── test.yaml
└── values.yaml
 
可以看到，一个 chart 包就是一个文件夹的集合，文件夹名称就是 chart 包的名称。
 
#chart 是包含至少两项内容的helm软件包：
（1）软件包自描述文件 Chart.yaml，这个文件必须有 name 和 version（chart版本） 的定义
（2）一个或多个模板，其中包含 Kubernetes 清单文件：
●NOTES.txt：chart 的“帮助文本”，在用户运行 helm install 时显示给用户
●deployment.yaml：创建 deployment 的资源清单文件
●service.yaml：为 deployment 创建 service 的资源清单文件
●ingress.yaml: 创建 ingress 对象的资源清单文件
●_helpers.tpl：放置模板助手的地方，可以在整个 chart 中重复使用
 
//创建自定义的 chart
helm create nginx
 
tree nginx
nginx
├── charts
├── Chart.yaml
├── templates
│   ├── deployment.yaml
│   ├── _helpers.tpl
│   ├── hpa.yaml
│   ├── ingress.yaml
│   ├── NOTES.txt
│   ├── serviceaccount.yaml
│   ├── service.yaml
│   └── tests
│       └── test-connection.yaml
└── values.yaml
 
cat nginx/templates/deployment.yaml
#在 templates 目录下 yaml 文件模板中的变量（go template语法）的值默认是在 nginx/values.yaml 中定义的，只需要修改 nginx/values.yaml 的内容，也就完成了 templates 目录下 yaml 文件的配置。
比如在 deployment.yaml 中定义的容器镜像：
image: "{{ .Values.image.repository }}:{{ .Values.image.tag | default .Chart.AppVersion }}"
 
cat nginx/values.yaml | grep repository
  repository: nginx
#以上变量值是在 create chart 的时候就自动生成的默认值，你可以根据实际情况进行修改。
 
//修改 chart
vim nginx/Chart.yaml
apiVersion: v2
name: nginx                     #chart名字
description: A Helm chart for Kubernetes
type: application               #chart类型，application或library
version: 0.1.0                  #chart版本
appVersion: 1.16.0              #application部署版本
 
 
vim nginx/values.yaml
replicaCount: 1
 
image:
  repository: nginx
  pullPolicy: IfNotPresent
  tag: "latest"                #设置镜像标签
 
imagePullSecrets: []
nameOverride: ""
fullnameOverride: ""
 
serviceAccount:
  create: true
  annotations: {}
  name: ""
 
podAnnotations: {}
 
podSecurityContext: {}
  # fsGroup: 2000
 
securityContext: {}
  # capabilities:
  #   drop:
  #   - ALL
  # readOnlyRootFilesystem: true
  # runAsNonRoot: true
  # runAsUser: 1000
 
service:
  type: ClusterIP
  port: 80
 
ingress:
  enabled: true                 #开启 ingress
  className: ""
  annotations: {}
    # kubernetes.io/ingress.class: nginx
    # kubernetes.io/tls-acme: "true"
  hosts:
    - host: www.david.com         #指定ingress域名
      paths:
        - path: /
          pathType: Prefix      #指定ingress路径类型
  tls: []
  #  - secretName: chart-example-tls
  #    hosts:
  #      - chart-example.local
 
resources:
  limits:
    cpu: 100m
    memory: 128Mi
  requests:
    cpu: 100m
    memory: 128Mi
 
autoscaling:
  enabled: false
  minReplicas: 1
  maxReplicas: 100
  targetCPUUtilizationPercentage: 80
  # targetMemoryUtilizationPercentage: 80
 
nodeSelector: {}
 
tolerations: []
 
affinity: {}
 
//打包 chart
helm lint nginx        #检查依赖和模版配置是否正确
 
helm package nginx     #打包 chart，会在当前目录下生成压缩包 nginx-0.1.0.tgz
 
//部署 chart
helm install nginx ./nginx --dry-run --debug    #使用 --dry-run 参数验证 Chart 的配置，并不执行安装
 
helm install nginx ./nginx -n default           #部署 chart，release 版本默认为 1
或者
helm install nginx ./nginx-0.1.0.tgz
 
#可根据不同的配置来 install，默认是 values.yaml
helm install nginx ./nginx -f ./nginx/values-prod.yaml
 
helm ls
NAME 	NAMESPACE	REVISION	UPDATED                                	STATUS  	CHART      	APP VERSION
nginx           	default  	1       	2023-10-10 09:58:45.891472283 +0800 CST	deployed	nginx-0.1.0 	1.16.0     
 
kubectl get pod,svc
NAME                         READY   STATUS    RESTARTS   AGE
pod/nginx-7d9c8bf85c-dwf9b        1/1     Running   0          34s
 
NAME                    TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
service/kubernetes                  ClusterIP   10.96.0.1               443/TCP    92d
service/nginx                       ClusterIP   10.96.155.244           80/TCP     34s
 
#部署 ingress
wget https://gitee.com/mirrors/ingress-nginx/raw/nginx-0.30.0/deploy/static/mandatory.yaml
wget https://gitee.com/mirrors/ingress-nginx/raw/nginx-0.30.0/deploy/static/provider/baremetal/service-nodeport.yaml
 
kubectl apply -f mandatory.yaml
kubectl apply -f service-nodeport.yaml
 
kubectl get pod,svc -n ingress-nginx
NAME                                            READY   STATUS    RESTARTS   AGE
pod/nginx-ingress-controller-54b86f8f7b-ltltd   1/1     Running   0          50s
 
NAME                    TYPE       CLUSTER-IP     EXTERNAL-IP   PORT(S)                      AGE
service/ingress-nginx   NodePort   10.96.127.18           80:30912/TCP,443:31732/TCP   16s
 
kubectl get ingress
NAME                CLASS    HOSTS          ADDRESS        PORTS   AGE
nginx      www.david.com   10.96.127.18   80      10m
 
vim /etc/hosts
.....
 192.168.204.182   www.david.com
 
curl http://www.david.com:31732
 
 
//修改为 NodePort 访问后，升级
vim nginx/values.yaml
service:
  type: NodePort
  port: 80
  nodePort: 30080
 
ingress:
  enabled: false
 
vim nginx/templates/service.yaml
apiVersion: v1
kind: Service
metadata:
  name: {{ include "nginx.fullname" . }}
  labels:
    {{- include "nginx.labels" . | nindent 4 }}
spec:
  type: {{ .Values.service.type }}
  ports:
    - port: {{ .Values.service.port }}
      targetPort: http
      protocol: TCP
      name: http
      nodePort: {{ .Values.service.nodePort }}              #指定 nodePort
  selector:
    {{- include "nginx.selectorLabels" . | nindent 4 }}
 
升级 release，release 版本加 1
helm upgrade nginx nginx 
 
kubectl get svc
NAME            TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE
kubernetes                  ClusterIP   10.96.0.1               443/TCP        92d
nginx                       NodePort    10.96.155.244           80:30080/TCP   21m
 
curl 192.168.204.182:30080
 
 
 
//回滚
#根据 release 版本回滚
helm history nginx              #查看 release 版本历史
REVISION	UPDATED                 	STATUS    	CHART      	APP VERSION	DESCRIPTION     
1       	Tue Oct 10 09:58:45 2023	superseded	nginx-0.1.0	1.16.0     	Install complete
2       	Tue Oct 10 10:19:33 2023	deployed  	nginx-0.1.0	1.16.0     	Upgrade complete
 
 
helm rollback nginx 1           #回滚 release 到版本1
 
helm history nginx           #nginx release 已经回滚到版本 1
REVISION	UPDATED                 	STATUS    	CHART      	APP VERSION	DESCRIPTION     
1       	Tue Oct 10 09:58:45 2023	superseded	nginx-0.1.0	1.16.0     	Install complete
2       	Tue Oct 10 10:19:33 2023	superseded	nginx-0.1.0	1.16.0     	Upgrade complete
3       	Tue Oct 10 10:24:39 2023	deployed  	nginx-0.1.0	1.16.0     	Rollback to 1   
 
#通常情况下，在配置好 templates 目录下的 kubernetes 清单文件后，后续维护一般只需要修改 Chart.yaml 和 values.yaml 即可。
 
 
//在命令行使用 --set 指定参数来部署（install,upgrade）release
#注：此参数值会覆盖掉在 values.yaml 中的值，如需了解其它的预定义变量参数，可查看 helm 官方文档。
helm upgrade nginx nginx --set image.tag='1.15'

（3）Helm 仓库

helm 可以使用 harbor 作为本地仓库，将自定义的 chart 推送至 harbor 仓库。


//安装 harbor
#上传 harbor-offline-installer-v1.9.1.tgz 和 docker-compose 文件到 /opt 目录
cd /opt
cp docker-compose /usr/local/bin/
chmod +x /usr/local/bin/docker-compose
 
tar zxf harbor-offline-installer-v1.9.1.tgz
cd harbor/
 
vim harbor.yml
hostname: 192.168.204.30
harbor_admin_password: Harbor12345     #admin用户初始密码
data_volume: /data                     #数据存储路径，自动创建
chart:
  absolute_url: enabled                #在chart中启用绝对url
log:
  level: info
  local:
    rotate_count: 50
    rotate_size: 200M
    location: /var/log/harbor          #日志路径
 
#安装带有 Clair service 和 chart 仓库服务的 Harbor
./install.sh --with-clair --with-chartmuseum
 
//安装 push 插件
#在线安装
helm plugin install https://github.com/chartmuseum/helm-push
 
#离线安装
wget https://github.com/chartmuseum/helm-push/releases/download/v0.8.1/helm-push_0.8.1_linux_amd64.tar.gz
 
mkdir ~/.local/share/helm/plugins/helm-push
tar -zxvf helm-push_0.8.1_linux_amd64.tar.gz -C ~/.local/share/helm/plugins/helm-push
 
helm repo ls
 
#登录 Harbor WEB UI 界面，创建一个新项目
浏览器访问：http://192.168.204.30 ，默认的管理员用户名和密码是 admin/Harbor12345
点击 “+新建项目” 按钮
填写项目名称为 “chart_repo”，访问级别勾选 “公开”，点击 “确定” 按钮，创建新项目
 
#添加仓库
helm repo add harbor http://192.168.204.30/chartrepo/chart_repo --username=admin --password=Harbor12345
#注：这里的 repo 的地址是/chartrepo/<项目名称>，Harbor 中每个项目是分开的 repo。如果不提供项目名称， 则默认使用 library 这个项目。
 
#推送 chart 到 harbor 中
cd /opt/helm
helm push nginx harbor
 
#查看 chart_repo 项目中的 Helm Charts

二、实验

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（2to3方式）

（1）下载helm3最新版本

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

确认helm版本

（2）安装helm-2to3插件

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

（3）更新repo源

查看repo源

3.部署HELM3（单独安装）

（1）部署

①安装 helm

命令补全

②使用 helm 安装 Chart

添加常用的 chart 仓库

更新 charts 列表

查看 stable 仓库可用的 charts 列表

删除 incubator 仓库

查看 chart 信息：

查看指定 chart 的基本信息

获取指定 chart 的所有信息

安装 chart

指定 release 的名字为 my-redis，-n 指定部署到 k8s 的 namespace

不指定 release 的名字时，需使用 –generate-name 随机生成一个名字

查看所有 release

查看指定的 release 状态

删除指定的 release

（2）Helm 自定义模板

①拉取 chart

解压

安装

查看结构


可以看到，一个 chart 包就是一个文件夹的集合，文件夹名称就是 chart 包的名称。
 
#chart 是包含至少两项内容的helm软件包：
（1）软件包自描述文件 Chart.yaml，这个文件必须有 name 和 version（chart版本） 的定义
（2）一个或多个模板，其中包含 Kubernetes 清单文件：
●NOTES.txt：chart 的“帮助文本”，在用户运行 helm install 时显示给用户
●deployment.yaml：创建 deployment 的资源清单文件
●service.yaml：为 deployment 创建 service 的资源清单文件
●ingress.yaml: 创建 ingress 对象的资源清单文件
●_helpers.tpl：放置模板助手的地方，可以在整个 chart 中重复使用

②创建自定义的 chart

在 templates 目录下 yaml 文件模板中的变量（go template语法）的值默认是在 nginx/values.yaml 中定义的，只需要修改 nginx/values.yaml 的内容，也就完成了 templates 目录下 yaml 文件的配置。

比如在 deployment.yaml 中定义的容器镜像：

以下变量值是在 create chart 的时候就自动生成的默认值，你可以根据实际情况进行修改。

修改 chart

设置镜像标签

开启 ingress、指定ingress域名、指定ingress路径类型

③ 打包 chart

检查依赖和模版配置是否正确

打包 chart，会在当前目录下生成压缩包 nginx-0.1.0.tgz

④部署 chart

使用 --dry-run 参数验证 Chart 的配置，并不执行安装

部署 chart，release 版本默认为 1

查看信息

⑤ 部署 ingress

下载

创建资源

查看信息

修改地址

测试

⑥修改为 NodePort 访问后，升级

修改

指定 nodePort

添加

⑦ 升级 release，release 版本加 1

查看svc

测试

⑧ 回滚

查看 release 版本历史

回滚 release 到版本1

nginx release 已经回滚到版本 1

（3）Helm 仓库

helm 可以使用 harbor 作为本地仓库，将自定义的 chart 推送至 harbor 仓库。
①上传 harbor-offline-installer-v1.9.1.tgz 和 docker-compose 文件到 /opt 目录

添加docker-compose命令

安装 harbor

在chart中启用绝对url

数据库存储路径，自动创建

②安装带有 Clair service 和 chart 仓库服务的 Harbor

③ 离线安装 push 插件

④查看

⑤登录 Harbor WEB UI 界面

⑥ 创建一个新项目

⑦添加仓库

注：这里的 repo 的地址是/chartrepo/<项目名称>，Harbor 中每个项目是分开的 repo。如果不提供项目名称，则默认使用 library 这个项目。

⑧推送 chart 到 harbor 中

⑨ 查看 chart_repo 项目中的 Helm Charts

三、问题

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:  
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 /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

13.使用 --dry-run 参数验证 Chart 的配置报错

（1）报错

（2）原因分析

service “nginx”已存在

Deployment "nginx" 已存在

（3）解决方法

查看service

删除service

查看deployment

删除deployment

成功：

13.新增Harbor服务器出现网络异常

（1）报错

重启机器后，网络异常报：Failed to start LSB: Bring up/down networking

重启网络服务


#重启网络：注意CentOS6需要使用service network restart命令
[root@localhost ~]# systemctl restart network
Job for network.service failed because the control process exited with error code. See "systemctl status network.service" and "journalctl -xe" for details.
 
 
#执行'systemctl status network.service'进一步排查
[root@localhost ~]# systemctl status network.service
● network.service - LSB: Bring up/down networking
   Loaded: loaded (/etc/rc.d/init.d/network; bad; vendor preset: disabled)
   Active: failed (Result: exit-code) since 二 2023-10-10 11:05:55 CST; 3s ago
     Docs: man:systemd-sysv-generator(8)
  Process: 2513 ExecStart=/etc/rc.d/init.d/network start (code=exited, status=1/FAILURE)
 
10月 10 11:05:55 localhost.localdomain network[2513]: RTNETLINK answers: File exists
10月 10 11:05:55 localhost.localdomain network[2513]: RTNETLINK answers: File exists
10月 10 11:05:55 localhost.localdomain network[2513]: RTNETLINK answers: File exists
10月 10 11:05:55 localhost.localdomain network[2513]: RTNETLINK answers: File exists
10月 10 11:05:55 localhost.localdomain network[2513]: RTNETLINK answers: File exists
10月 10 11:05:55 localhost.localdomain network[2513]: RTNETLINK answers: File exists
10月 10 11:05:55 localhost.localdomain systemd[1]: network.service: control process exited, code=exited...s=1
10月 10 11:05:55 localhost.localdomain systemd[1]: Failed to start LSB: Bring up/down networking.
10月 10 11:05:55 localhost.localdomain systemd[1]: Unit network.service entered failed state.
10月 10 11:05:55 localhost.localdomain systemd[1]: network.service failed.
Hint: Some lines were ellipsized, use -l to show in full.

（2）原因分析

未禁用NetworkManager与防火墙

（3）解决方法

禁用NetworkManager


#关闭NetworkManager服务,重启机器后会失效
[root@localhost ~]# systemctl stop NetworkManager
 
#永久关闭NetworkManager服务,重启机器后不会失效
[root@localhost ~]# systemctl disable NetworkManager

关闭防火墙


# 查看防火墙状态
[root@localhost ~]# firewall-cmd --state
running			---运行中，即开启状态
 
# 关闭防火墙
[root@localhost ~]# systemctl stop firewalld
 
# 查看是否关闭成功
[root@localhost ~]# firewall-cmd --state
not running   	---不在运行中，即关闭状态

关闭selinux


#查看selinux状态
[root@localhost ~]# getenforce
Enforcing		---表示开启状态
 
# 临时关闭
[root@localhost ~]# setenforce 0		---立即生效，重启后失效
 
# 永久关闭，修改selinux配置文件。	---重启后生效
[root@localhost ~]# vim /etc/selinux/config
...
# 将SELINUX的值修改为disabled
SELINUX=disabled
...
 
#后者一句命令实现
[root@localhost ~]# sed -i 's/SELINUX=enforcing/SELINUX=disabled/g' /etc/selinux/config
 
 
# 关闭后再次查看是否关闭成功
[root@localhost ~]# getenforce
Disabled		---表示关闭状态

重启机器&重启网络


#重启机器
[root@localhost ~]# reboot
...
 
# 再次重启网络,无报错
[root@localhost ~]# systemctl restart network
 
# 查看网络是否重启成功
[root@localhost ~]# ip a
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: ens33:  mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 00:0c:29:18:e8:df brd ff:ff:ff:ff:ff:ff
    inet 192.168.204.30/24 brd 192.168.204.255 scope global ens33
       valid_lft forever preferred_lft forever
    inet6 fe80::20c:29ff:fe18:e8df/64 scope link 
       valid_lft forever preferred_lft forever
...

14.安装Harbor报错

（1）报错

（2）原因分析

需要安装docker(17.06.0)以上版本

(3) 解决方法

安装docker

成功：

四、总结

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

相关阅读:
java计算机毕业设计红色主题旅游网站MyBatis+系统+LW文档+源码+调试部署
 玩转 CMS
pool = multiprocessing.Pool()报错：module object has no attribute Pool
RecyclerView的item布局预览显示是一行两块运行后显示了一行一块，怎么回事
 深入Linux内核理解epoll事件轮询机制
 机器学习——机器学习概述
 MySQL内核查询优化规则
 【Redis】Redis Cluster-集群故障转移
 vite打包流程和原理
 拥塞控制计算机网络
原文地址：https://blog.csdn.net/cronaldo91/article/details/133578560