目录

一、理论

1.HELM

​编辑

2.部署HELM2

3.部署HELM3(2to3方式)

4.部署HELM3(单独安装)

二、实验

1.部署 HELM2

2.部署HELM3(2to3方式)

3.部署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问题

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

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

14.安装Harbor报错

四、总结


一、理论

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(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 <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

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       <none>        443/TCP    92d
service/nginx                       ClusterIP   10.96.155.244   <none>        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   <none>        80:30912/TCP,443:31732/TCP   16s

kubectl get ingress
NAME                CLASS    HOSTS          ADDRESS        PORTS   AGE
nginx   <none>   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       <none>        443/TCP        92d
nginx                       NodePort    10.96.155.244   <none>        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 的地址是<Harbor URL>/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 的地址是<Harbor URL>/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:  <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

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: <LOOPBACK,UP,LOWER_UP> 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: <BROADCAST,MULTICAST,UP,LOWER_UP> 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
Logo

K8S/Kubernetes社区为您提供最前沿的新闻资讯和知识内容

更多推荐