当前位置：首页 > news >正文

kubernetes的包管理器Helm介绍和架构说明

news 2026/6/5 3:00:20

包管理器

*.rpm: 打包文件，rpm yum,dnf 包仓库工具
*.deb: dpkg apt 包仓库工具

Nginx 源码部署软件,ansible playbook

1)download nginx.tar.gz
2) tar xvf
3 安装依赖的相关包，gcc make libxx
4) cd nginx; configure --prefix=/apps/nginx --xxx && make && make install
5) useradd nginx
6) chown -R nginx:nginx /apps/nginx
7) nginx.service

k8s 部署应用

写一堆yaml,wordpress+mysql
1）wordpress
configmap
deployment:requests/limits
pvc/pv/sc
service:
ingress

kubectl apply -f
helm

2）mysql
configmap
statefulset
pvc/pv/sc
headless service:clusterIP

A项目：wordpress+mysql nsa
B项目：wordpress+mysql nsb
C项目：wordpress+mysql nsc

wordpress

k8s包(Chart)管理器：helm

app.tar.gz
app.tgz

Kubernetes 包管理器 Helm

Helm 说明和部署

Helm 说明

Helm 介绍

传统的软件管理机制
传统的软件安装基于编译安装方式非常繁琐，所以会使用包管理方式简化软件安装的过程
包管理器：

deb，dpkg
rpm, rpm

程序包仓库：维护有仓库内部各程序文件元数据，其中包含了包依赖关系
前端工具：客户端

yum, dnf, ...
apt-get, ...

将应用服务部署到 Kubernetes 集群的传统流程

拉取源代码
打包编译
Dockerfile构建容器的镜像
上传到镜像仓库Harbor
准备一堆相关部署资源清单的 yaml 文件(如:deployment、statefulset、service、ingress、
RABC、configmap、secret、PVC等)
kubectl apply 部署

传统方式部署引发的问题

随着资源引用的增多，需要维护大量的yaml文件
微服务场景下，每个微服务所需配置差别不大，但是众多的微服务的yaml文件无法高效复用
无法将相关yaml文件做为一个整体管理，并实现应用级别的升级和回滚等功能
无法根据一套yaml文件来创建多个环境，需要手动进行修改，尤其是微服务众多的情况，效率低下
例如: 部署的环境都分为开发、预生产、生产环境，在开发这套环境部署完了，后面再部署到预生产和生产环境，还需要重新复制出两套配置文件，并手动修改才能完成

Kubernetes 的软件管理器 Helm 介绍

Kubernetes也提供了类似于包管理机制 Helm
Helm （船舵，掌舵）是一个用于简化和管理 Kubernetes 应用部署的包管理器。
Helm 可以将部署应用所需要的所有配置清单文件YAML打包至一个Chart的包文件中，并使用一套资源
实现定制发布到多套环境
Helm 允许用户进行定义、安装和升级 Kubernetes 应用程序的资源，称为 Helm Charts。
Helm 不是 Kubernetes 官方提供的工具，但它是由 Kubernetes 社区维护和支持的。
Helm 在社区中得到了广泛的支持和采用，并成为 Kubernetes 生态系统中流行的部署工具之一。
Helm 是CNCF在2020年已经毕业的项目
https://www.cncf.io/projects/helm/

Helm 官网

https://helm.sh/
https://github.com/helm/helm

Helm 文档

https://helm.sh/zh/docs/
https://helm.sh/zh/docs/intro/quickstart/

Helm 重要特性

将各种资源YAML文件按照分类进行打包，基于包的方式安装，更加方便
提供template功能，可以基于同一套template文件，但对于不同环境可以赋予不同的值从而实现
的灵活部署
提供版本管理功能，比如，安装，删除，升级，回滚等

Helm 的历史

2015 年：Deis 团队开发了 Helm 1.0，最初称为 Kubernetes Deployment Manager。
2016 年：Helm 1.0 与 Kubernetes 项目合并，并更名為 Helm 2.0。Helm 2.0 引入了 Tiller 服务器，它用于管理 Helm 圖表。
2018 年：Helm 2.0 成为 CNCF 毕业項目。
2019 年：Helm 3.0 发布，刪除了 Tiller 服务器，并引入了新的功能，例如 Chart templating 和Chart hooks。
2020 年：Helm 3.0 成为 CNCF 毕业项目

Helm 相关概念
Helm：Helm的客户端工具，负责和 API Server 通信
Helm 和 kubectl 类似，也是Kubernetes API Server的命令行客户端工具支持kubeconfig认证文件
需要事先从仓库或本地加载到要使用目标Chart，并基于Chart完成应用管理Chart可缓存于Helm本
地主机上
支持仓库管理和包管理的各类常用操作，例如Chart仓库的增、删、改、查，以及Chart包的制作、
发布、搜索、下载等

Chart：图表，打包文件，将所有相关的资源清单文件YAML的打包文件
https://helm.sh/
https://github.com/helm/helm
https://helm.sh/zh/docs/
https://helm.sh/zh/docs/intro/quickstart/Chart 是一种打包格式，文件后缀为tar.gz或者 tgz，代表着可由Helm管理的有着特定格式的程序
包，类似于RPM，DEB包格式

Chart 包含了应用所需的资源相关的各种yaml/json配置清单文件，比如：deployment,service等
清单文件，但不包含容器的镜像
Chart 可以使用默认配置，或者定制用户自已的配置进行安装应用
Chart 中的资源配置文件通常以模板(go template)形式定义，在部署时，用户可通过向模板参数赋
值实现定制化安装的目的
Chart 中各模板参数通常也有默认值，这些默认值定义在Chart包里一个名为values.yml的文件中

Release：表示基于chart部署的一个实例。通过chart部署的应用都会生成一个唯一的Release,即使
同一个chart部署多次也会产生多个Release.将这些release应用部署完成后，也会记录部署的一个
版本，维护了一个release版本状态,基于此可以实现版本回滚等操作

Repository：chart包存放的仓库，Harbar可以实现，类似于APT和YUM仓库

Helm 版本

Helm-v2z

C/S 架构:

Client : helm 命令行程序 client，通过gRPC协议和Tiller通信
Server: 称为Tiller, 以Operator形式部署Kubernetes 集群内，表现为相应的一个Pod，还需要做RBAC的授权

Tiller Server
Tiller Server是一个部署在Kubernetes集群内部的 server，其与 Helm client、Kubernetes API server进行交互。

Tiller server 主要负责如下：

监听来自 Helm client 的请求
通过 chart 及其配置构建一次发布安装 chart 到Kubernetes集群，并跟踪随后的发布
通过与Kubernetes交互升级或卸载 chart

权限管理：
Helm 客户端配置 kubeconfig 文件，以便能够与 Kubernetes API 服务器通信。这个配置通常在~/.kube/config 文件中。加载认证配置文件的机制同kubectl
Tiller 服务端需要在其运行的命名空间中具有足够的权限来管理 Kubernetes 资源。

这通常通过创建一个服务账户（ServiceAccount）并绑定适当的角色（例如 ClusterRole 和ClusterRoleBinding）来实现。

Helm-v3

2019年11月发布Helm-v3版本

Helm 3 的变化
Tiller 服务器端被废弃
仅保留helm客户端，helm 通过 kubeconfig 认证到 API Server ，加载认证配置文件的机制同kubectl

Helm 3 的 Release 可以在不同名称空间重用，每个名称空间名称唯一即可,而Helm 2 中，Release的名称在整个 Kubernetes 集群中必须是唯一的。虽然 Helm 2 支持将 Release 安装到不同的命名
空间中，但它们的名称仍然不能重复
支持将Chart 推送至Docker 镜像仓库
支持更强大的 Chart templating 语法，包括 Go 模板和新的 templating 函数。
这使得 Helm 3 更灵活，可以用于更复杂的部署场景

Helm 3 默认使用secrets来存储发行信息，提供了更高的安全性。
Helm 2 默认使用configmaps存储发行信息。

自动创建名称空间
在不存在的命名空间中创建Release时，Helm 2可以自动创建名称空间。
Helm 3遵循其他Kubermetes对象的行为，如果命名空间不存在则返回错误。
Helm 3 可以通过 --create-namespace 选项当名称空间不存在时自动创建
不再需要requirements.yaml,依赖关系是直接在 Chart.yaml中定义。

命令变化
删除 release 命令变化
helm delete RELEASE_NAME --purge => helm uninstall RELEASE_NAME
查看 chart 信息命令变化
helm inspect RELEASE_NAME => helm show RELEASE_NAME
拉取 chart包命令变化
helm fetch CHART_NAME => helm pull CHART_NAME
生成release的随机名
helm-v3 必须指定release名，如果想使用随机名，必须通过--genrate-name 选项实现，helm-v2可以自动生成随机名
helo install ./mychart --generate-name

Chart 仓库
Chart 仓库：用于实现Chart包的集中存储和分发,类似于Docker仓库Harbor
Chart 仓库：