第26节 helm 教程
❤️💕💕新时代拥抱云原生,云原生具有环境统一、按需付费、即开即用、稳定性强特点。Myblog:http://nsddd.top
helm介绍
提示
使用 Helm
我们可以非常方便的就搭建出来 MongoDB
/ MySQL
副本集群,YAML
文件别人都给我们写好了,直接使用。
helm
的作用就是把许多的资源定义 比如svc
,deployment
,一次性通过全部定义好,放在源里统一管理,这样很容易在其他机器上部署,个人理解这个类似于自动化运维中ansible
中的角色概念,前端项目中的npm
包管理工具,后端项目中的maven
等构建工具一样,类比Ansible
使用角色来整合playbook.yaml
达到复用性。同样的,使用helm
用于整合k8s中的资源对象yaml
文件,实现复用性,同时讲资源文件的参数,和参数值通过temple
和value
进行了分离。
k3s helm
K3s 不需要任何特殊的配置就可以使用 Helm 命令行工具。只要确保你已经按照集群访问一节正确设置了你的 kubeconfig。 K3s 通过 rancher/helm-release CRD 使传统的 Kubernetes 资源清单和 Helm Charts 部署更加容易。
自动部署 Helm charts
在/var/lib/rancher/k3s/server/manifests
中找到的任何 Kubernetes 清单将以类似kubectl apply
的方式自动部署到 K3s。以这种方式部署的 manifests 是作为 AddOn 自定义资源来管理的,可以通过运行kubectl get addon -A
来查看。你会发现打包组件的 AddOns,如 CoreDNS、Local-Storage、Traefik 等。AddOns 是由部署控制器自动创建的,并根据它们在 manifests 目录下的文件名命名。
也可以将 Helm Chart 作为 AddOns 部署。K3s 包括一个Helm Controller,它使用 HelmChart Custom Resource Definition(CRD)管理 Helm Chart。
使用 Helm CRD
HelmChart CRD捕获了大多数你通常会传递给helm
命令行工具的选项。下面是一个例子,说明如何从默认的 Chart 资源库中部署 Grafana,覆盖一些默认的 Chart 值。请注意,HelmChart 资源本身在 kube-system
命名空间,但 Chart 资源将被部署到 monitoring
命名空间。
apiVersion: helm.cattle.io/v1
kind: HelmChart
metadata:
name: grafana
namespace: kube-system
spec:
chart: stable/grafana
targetNamespace: monitoring
set:
adminPassword: "NotVerySafePassword"
valuesContent: |-
image:
tag: master
env:
GF_EXPLORE_ENABLED: true
adminUser: admin
sidecar:
datasources:
enabled: true
HelmChart 字段定义
字段 | 默认值 | 描述 | Helm Argument / Flag Equivalent |
---|---|---|---|
name | N/A | Helm Chart 名称 | NAME |
spec.chart | N/A | 仓库中的 Helm Chart 名称,或完整的 HTTPS URL(.tgz)。 | CHART |
spec.targetNamespace | default | Helm Chart 目标命名空间 | --namespace |
spec.version | N/A | Helm Chart 版本(从版本库安装时使用的版本号) | --version |
spec.repo | N/A | Helm Chart 版本库 URL 地址 | --repo |
spec.helmVersion | v3 | Helm 的版本号,可选值为 v2 和v3 ,默认值为 v3 | N/A |
spec.set | N/A | 覆盖简单的默认 Chart 值。这些值优先于通过 valuesContent 设置的选项。 | --set / --set-string |
spec.jobImage | 指定安装 helm chart 时要使用的镜像。如:rancher/klipper-helm:v0.3.0。 | ||
spec.valuesContent | N/A | 通过 YAML 文件内容覆盖复杂的默认 Chart 值。 | --values |
spec.chartContent | N/A | Base64 编码的 Chart 存档.tgz - 覆盖 spec.chart。 | CHART |
放在/var/lib/rancher/k3s/server/static/
中的内容可以通过 Kubernetes APIServer 从集群内匿名访问。这个 URL 可以使用spec.chart
字段中的特殊变量%{KUBERNETES_API}%
进行模板化。例如,打包后的 Traefik 组件从https://%{KUBERNETES_API}%/static/charts/traefik-1.81.0.tgz
加载其 Chart。
使用 HelmChartConfig 自定义打包的组件
为了允许覆盖作为 HelmCharts(如 Traefik或其他通过helm crd 部署的应用)部署的打包组件的值,从 v1.19.0+k3s1 开始的 K3s 版本支持通过 HelmChartConfig CRD 部署。HelmChartConfig 资源必须与其对应的 HelmChart 的名称和命名空间相匹配,并支持提供额外的 "valuesContent",它作为一个额外的值文件传递给helm
命令。
注意: HelmChart 的
spec.set
值覆盖了 HelmChart 和 HelmChartConfig 的spec.valuesContent
设置。
apiVersion: helm.cattle.io/v1
kind: HelmChartConfig
metadata:
name: grafana
namespace: kube-system
spec:
valuesContent: |-
service:
type: NodePort
如果要自定义打包后的 Traefik 入口配置,你可以创建一个名为/var/lib/rancher/k3s/server/manifests/traefik-config.yaml
的文件,并将其填充为以下内容。
命令速查
helm常用命令:
1、查看服务状态
service httpd status
2、启动服务
service httpd start
3、停止服务
service httpd stop
4、重启服务
service httpd restart
5、重载配置文件
service httpd reload
6、查看端口占用情况
netstat -tunlp
7、查看httpd进程
ps -ef | grep httpd
8、查看httpd版本
httpd -v
9、查看httpd配置文件
httpd -V
10、查看httpd模块
httpd -l
11、查看httpd模块详细信息
httpd -M
12、查看httpd安装路径
httpd -V | grep SERVER_CONFIG_FILE
13、查看httpd错误日志
cat /var/log/httpd/error_log
14、查看httpd访问日志
cat /var/log/httpd/access_log
15、查看httpd配置文件
cat /etc/httpd/conf/httpd.conf
16、查看httpd配置文件中的模块
cat /etc/httpd/conf/httpd.conf | grep LoadModule
17、查看httpd配置文件中的虚拟主机
cat /etc/httpd/conf/httpd.conf | grep VirtualHost
18、查看httpd配置文件中的监听端口
cat /etc/httpd/conf/httpd.conf | grep Listen
heml解决了什么问题?
我们部署应用?
k8s
上的应用对象,都是由特定的资源描述组成, 包括 deployment
、service
等,都保存在各自文件中或者集成到一个配置文件,然后通过 kubectl apply -f
部署
我们部署小的应用程序肯定是没有问题的,但是部署一个复杂的应用管理
yaml
文件,可能就有些麻烦。
我们需要:
- 如何将这些服务作为一个整体管理
- 这些资源文件如何高效复用
- 不支持应用级别的版本管理
helm就能解决这些问题,它就类似于Linux中的yum
包或者apt
包。
提示
Helm 是 Kubernetes 的首选包管理工具。Helm Chart 为 Kubernetes YAML 清单文件提供了模板化语法。通过 Helm,我们可以创建可配置的部署,而不仅仅是使用静态文件。有关创建自己的部署目录的更多信息,请查看Helm 快速入门。
K3s 不需要任何特殊的配置就可以使用 Helm 命令行工具。只要确保你已经按照集群访问一节正确设置了你的 kubeconfig。 K3s 包含了一些额外的功能,通过rancher/helm-release CRD,使传统的 Kubernetes 资源清单和 Helm Charts 部署更加容易。
v2 vs v3
简单来说,Helm就是一个第三方部署k8s应用的工具
helm v3 vs v2特性
另外,常用的Helm版本有v2跟v3,Helm v3区别于v2主要有以下特性:
- 移除了Tiller(from SA to kubeconfig)
- 三方会谈 (Three-way Strategic merge patch)
- 使用Secret作为默认存储
区别对比
1、移除了Tiller(from SA to kubeconfig)
原来Helm v2需要在 Kubernetes 集群中部署Tiller
(Tiller
用于接收 Helm 的请求,并根据 Chart
生成 Kubernetes 的部署文件),Tiller pod
根据自身SA权限部署应用。并且在多租户环境下,为了进行权限管理需要部署多个Tiller
。
在 Helm v3 中,Tiller 被移除了。新的 Helm 客户端会像 kubectl 命令一样,读取本地的 kubeconfig 文件,使用我们在 kubeconfig 中预先定义好的SA权限来进行一系列操作。这样做法即简单,又安全。
2、三方会谈 (Three-way Strategic merge patch)
会兼容通过第三方修改的属性(如通过kubectl edit修改的属性,在helm upgrade时会考虑进去)
3、使用Secret作为默认存储
4、crd-install hook迁移到了crds/路径等
什么是CRD?
CRD(Custom Resource Define) 自定义资源定义,是在k8s高版本(v1.7+)上新增加的新特性,为了提高拓展性,让开发者可以自己去定义k8s资源对象。
实际运行时是以CR(Custom Resourse自定义资源)具体实例进行呈现。
当前已经存在的官方资源:
Pod
:是一种集合了多个应用容器、存储资源、专用IP及支撑容器运行其他配置选项的逻辑组件,是k8s部署单元和原子运行单元,简单来说就是一个运行多个应用程序的单一运行实例,通过共享资源相互联系的应用容器。通俗的讲,pod是一个物理主机或VM主机,pod中的应用容器就是主机上的进程,彼此隔离。ReplicaSet
:定义一组任何时候都处于运行状态的pod副本的稳定集合资源,保证运行指定数量的、完全相同的pod的可用性。ReplicationController
:跟ReplicaSet是一样的,确保在任何时候都有特定数量的 Pod 副本处于运行状态。 换句话说,ReplicationController 确保一个 Pod 或一组同类的 Pod 总是可用的。但是更推荐使用ReplicaSet的Deployment去建立副本。Deployment
:该对象是用来描述pod和ReplicaSet副本的目标状态,并更新他们不符合期望时的状态。StatefulSet
:该资源对象用来管理有状态应用pod的工作负载,支持pod集合的部署和扩容、缩容。DaemonSet
:该对象用来确保全部或者部分节点都运行一个pod副本,就是我们所说的守护进程。Job
:该对象用来执行目标状态的pod副本的一个任务,相当于一个监听任务,实时控制pod副本达到期望状态。CronJob
:这是一个有时间周期的Job。HorizontalPodAutoscaling
:该对象为pod水平自动扩缩,自动更新工作负载资源(Deployment和StatefulSet),目的是自动扩缩工作负载以满足需求。Node
:节点是一个虚拟机或者物理机,节点上运行pod所需的容器。Namespace
:命名空间,是一种机制,将同一集群的资源划分一个相互隔离的组。Service
:就是运行在pod上的提供服务的组件,如微服务组件。Ingress
:是各个服务service相互访问的一个中间路由管理器,可以实现流量控制等。Label
:为每个对象定义标签,用于标签选择器可以高效地查询和监听k8s对象。CustomResourceDefinition
:用于开发者自定义的资源对象。
如何使用CRD:
CRD 资源可以动态注册到集群中,注册完毕后,用户可以通过 kubectl 来创建访问这个自定义的资源对象,类似于操作 Pod 一样。
Helm Controller
Helm Controller实际上就是一个CRD Controller,管理的是HelmChart类型的CRD API
设计原理:
1、Helm-controller
运行在master
节点并list/watch HelmChart CRD
对象
2、CRD onChange
时执行Job
更新
3、Job Container
使用rancher/kilipper-helm
为entrypoint
4、Killper-helm
内置helm cli
,可以安装/升级/删除对应的chart
helm安装
用二进制版本安装
每个Helm 版本都提供了各种操作系统的二进制版本,这些版本可以手动下载和安装。
- 下载 需要的版本
- 解压(
tar -zxvf helm-v3.0.0-linux-amd64.tar.gz
) - 在解压目中找到
helm
程序,移动到需要的目录中(mv linux-amd64/helm /usr/local/bin/helm
)
然后就可以执行客户端程序并 添加稳定仓库: helm help
.
注意 针对Linux AMD64,Helm的自动测试只有在CircleCi构建和发布时才会执行。测试其他操作系统是社区针对系统问题请求Helm的责任。
使用脚本安装
Helm现在有个安装脚本可以自动拉取最新的Helm版本并在 本地安装。
您可以获取这个脚本并在本地执行。它良好的文档会让您在执行之前知道脚本都做了什么。
$ curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3
$ chmod 700 get_helm.sh
$ ./get_helm.sh
root@cubmaster01:/workspces/runtime/ingress-nginx# ./helm.sh
Downloading https://get.helm.sh/helm-v3.10.2-linux-amd64.tar.gz
Verifying checksum... Done.
Preparing to install helm into /usr/local/bin
helm installed into /usr/local/bin/helm
如果想直接执行安装,运行
curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash
配置helm源
使用helm需要配置yaml源,常见的有阿里。微软,和Github上的源
- 阿里云的源 https://apphub.aliyuncs.com
- 微软
azure
的源 http://mirror.azure.cn/kubernetes/charts/
查看所有的源:
helm repo list #查看所以的源
添加指定的源:
helm repo add azure http://mirror.azure.cn/kubernetes/charts/
helm repo add aliyun https://apphub.aliyuncs.com
查看配置的存储库:
helm search repo stable
删除;
helm repo remove aliyun
搜索
它会搜索当前仓库所匹配的所有镜像源:
helm search
快速上手
helm常见用法:
Helm的常见用法,包括搜索Chart、安装Chart、自定义Chart配置、更新或回滚Release、删除Release、创建自定义Chart、搭建私有仓库等
检测版本的安装:
root@VM-4-3-ubuntu:~# helm version
version.BuildInfo{Version:"v3.9.2", GitCommit:"1addefbfe665c350f4daf868a9adc5600cc064fd", GitTreeState:"clean", GoVersion:"go1.17.12"}
和docker一样,搜索可用的包:
helm search repo mysql
helm包拉取
安装chart可以直接使用命令安装,也可以拉取到本地之后安装,也可以直接通过命名行安装
- 本地的Chart压缩包(helm install mysql-1.6.4.tgz)
- 一个Chart目录(helm install mysql/)
- 一个完整的URL(helm install https://example.com/charts/mysql-1.6.4.tgz)
chart包拉取:
helm pull azure/mysql --version=1.6.4
helm install:安装Chart:
这个命令是直接拉取安装,而上面的是可以实现离线安装的~
helm install db azure/mysql --version=1.6.4
拉取的chart包详细信息,通过解压之后查看:
tar -zxvf mysql-1.6.4.tgz
关键文件:
对于下载好的yaml
文件,我们可以修改后使用helm package
重新打包
rm -rf mysql-1.6.4.tgz && helm package mysql/
此时
mysql
会被重新打包成tar
root@VM-4-3-ubuntu:~/helm# ls mysql mysql-1.6.4.tgz
下面我们修改chart中的对应镜像为已经下载好的mysql和busybox镜像:
ansible 192.168.26.82 -m shell -a "docker images | grep mysql"
通过修好的yaml文件创建chart, 使用helm ls
查看当前运行的chart
helm ls
使用helm install
运行Chart
这里我们使用之前的那个mysq chart来安装一个mysql
cd mysql/ && helm install mydb .
查看是否是否运行成功mydb的pod和SVC
kubectl get pods
kubectl get svc
安装一个mysql客户端测试OK:
yum install mariadb -y
mysql -h10.107.17.103 -uroot -ptesting
安装集群镜像
Add repository:
helm repo add redis https://spy86.github.io/redis
Install chart:
helm install my-redis redis/redis --version 0.1.1
使用:
helm repo add bitnami https://charts.bitnami.com/bitnami
helm install my-mongo bitnami/mongodb
# 指定密码和架构
helm install my-mongo bitnami/mongodb --set architecture="replicaset",auth.rootPassword="mongopass"
# 删除
helm ls
helm delete my-mongo
# 查看密码
kubectl get secret my-mongo-mongodb -o json
kubectl get secret my-mongo-mongodb -o yaml > secret.yaml
# 临时运行一个包含 mongo client 的 debian 系统
kubectl run mongodb-client --rm --tty -i --restart='Never' --image docker.io/bitnami/mongodb:4.4.10-debian-10-r20 --command -- bash
# 进去 mongodb
mongo --host "my-mongo-mongodb" -u root -p mongopass
# 也可以转发集群里的端口到宿主机访问 mongodb
kubectl port-forward svc/my-mongo-mongodb 27017:27018
helm 配置安装集群
helm 安装过程中有两种方式传递数据:
-f(或--values)
:使用 YAML 文件覆盖默认配置。可以指定多次,优先使用最右边的文件。--set
:通过命令行的方式对指定项进行覆盖
注意
如果同时使用两种方式,则 --set
中的值会被合并到 -f
中,但是 –set
中的值优先级更高
END 链接
✴️版权声明 © :本书所有内容遵循CC-BY-SA 3.0协议(署名-相同方式共享)©