目录
一、理论
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版本的架构变化文章来源:https://www.toymoban.com/news/detail-727836.html
1. 最大的改动就是移除了 Tiller 组件,所有功能都通过 Helm CLI 与 ApiServer 直接交互。
2. release在v3版本中可以实现不同的namespace空间中重用;
3. 可以将chart推入到docker仓库中。
HELM3特性:文章来源地址https://www.toymoban.com/news/detail-727836.html
一、新的功能
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
到了这里,关于云原生Kubernetes:简化K8S应用部署工具Helm的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!