Kubernetes Helm 基础操作
meaauf 0 评论 云原生 7 阅读

Kubernetes Helm 基础操作

_

一、Helm简介

1. Helm概述

Helm是Kubernetes的官方包管理工具，而Helm Charts是由Helm打包而成的应用安装包，等同于k8s生态的软件安装载体，类似于Ubuntu的deb包、CentOS的rpm包。单个Chart内部封装了部署业务应用所需的全套YAML资源，包含Pod、Deployment、Service、ConfigMap等各类Kubernetes资源清单。

Helm Charts是Kubernetes生态的重要子项目，目前托管于GitHub平台，旨在为Kubernetes提供标准化的包管理能力，助力用户高效管理集群内的各类应用集合。借助Helm Charts，用户可以轻松完成Kubernetes应用的定义、安装、升级和迭代操作，且Chart支持自定义创建、版本管理、共享与发布，复用性极强。该项目最新版本由CNCF云原生计算基金会负责维护，凭借稳定可靠的能力被谷歌、微软、Bitnami等众多大型企业广泛使用，是云原生部署的核心工具之一。

Helm官网地址：https://helm.sh/zh/docs/
Helm GitHub地址：https://github.com/helm

2. Helm的作用

在Kubernetes集群中部署一套完整可用的应用，通常需要多种资源对象协同工作。以WordPress应用为例，部署过程中需要依赖Deployment、Service、Secret、PV、PVC等多种资源。同时WordPress数据依赖MariaDB数据库，必须保证数据库服务就绪后应用才能正常启动。由于应用所需资源数量多、配置分散，如果单纯依靠kubectl逐条管理和维护，操作繁琐且不便于统一维护与迭代。

为了解决上述问题，Kubernetes引用Helm工具，能够有效地解决传统部署方式的痛点：

  • 实现各类分散的Kubernetes资源文件的统一管理、集中配置和版本更新；

  • 支持应用模板的打包分发与复用，适配多环境快速部署；

  • 将一整套关联的集群资源统一封装为软件包，实现应用整体化管理。

3. Helm核心优势

  1. 管理复杂应用（Manage Complexity）：Helm Chart能够适配各类复杂业务应用的部署需求，支持应用可重复、幂等性安装，同时能够统一整合应用配套服务，实现复杂k8s应用集合的规范化管理。

  2. 便携升级（Easy Updates）：支持应用镜像实时升级，可以自定义Webhook联动更新机制，高效解决传统镜像升级流程繁琐、操作低效的问题，适配团队快速迭代需求。

  3. 企业内部共享（Simple Sharing）：Helm Chart支持版本管控与快速共享，企业可搭建私有Helm仓库，实现应用模版内部复用，同时规避从官方源拉取镜像速度慢且不稳定的问题。

  4. 版本回滚（Rollbacks）：Helm会记录每一次应用部署的Release版本，当应用更新异常时，可以一键快速回退至历史正常版本，保障业务稳定运行。

4. Helm核心概念

核心概念

说明

Chart

Helm的打包单元，包含应用的所有Kubernetes资源定义（Deployment、Service等）和配置模板

Repository

存储和分发Chart的仓库（类似软件源），支持公共仓库和私有仓库

Release

Chart在集群中的运行实例，每个Release有唯一名称和版本号

Values

通过“values.yaml”文件动态配置Chart参数，支持多环境覆盖（开发/生产）

Templates

使用Go模板语言生成的动态YAML文件，通过“{{ .Values.key }}”引用配置参数

Dependency

Chart的子依赖项（如数据库、消息队列），在“Chart.yaml”中声明并自动解析

Hooks

生命周期钩子，在Release的特定阶段（如安装前、升级后）执行自定义任务（如数据库迁移）

Versioning

Chart版本遵循语义化版本（SemVer），支持版本回滚和升级

TillerServer

Helm v2架构的组件，Tiller为Helm服务端组件，负责接收Helm客户端请求，与Kubernetes API Server交互，依据Chart模板生成Release，并统一管理应用的部署、升级与生命

5. Helm架构流程图

下图是搭载Tiller组件的Helm v2架构，Helmv3架构已经移除了Tiller服务端，客户端可以直接和Kubernetes APIServer通信。所有模板渲染、集群资源部署操作均由Helm客户端独立完成，并依托Secret、标签等k8s原生资源维护Release部署状态。

  1. Helm：本地命令行客户端根据，基于Go开发。

    • 功能1：手动编写、创建各类应用的Chart文件，例如WordPress、Nginx、MySQL应用模版；

    • 功能2：将Chart文件打包为TarBall格式的Chart安装包；

    • 通信方式：通过gRPC协议与Tiller服务端交互，可执行拉取仓库Chart、查询、更新应用Release等操作。

  2. REPOSITORY：用于集中存储所有打包完成的Chart压缩包（TarBall），Helm客户端可从仓库拉取所需应用模板。

  3. Tiller：Helm v2专属服务端组件，部署在Kubernetes集群内部；

    • 接收Helm客户端通过gRPC发送的各类指令；

    • 内部封装Kubernetes客户端库，通过REST/JSON调用Kubernetes APIServer；

    • 核心能力：执行安装Chart、删除应用Release、更新Release等操作；

    • 数据存储：自身无独立数据库，所有Release信息保存在集群原生ConfigMap中。

  4. Kubernetes：承载最终业务应用资源，Tiller通过REST接口向集群下发资源清单，完成应用部署、删除等生命周期管理。

6. Chart概述

Helm的软件包格式为Chart，Chart本质是一套标准化文件集合，用于定义和描述一组互相关联的Kubernetes集群资源。可以从Helm仓库中拉取指定Chart包，查看文件结构。

[Step1] 从仓库中拉取WordPress的Chart包到本地目录，将其解压缩后查看文件内容。

root@k8s-master:~# helm pull azure/wordpress
root@k8s-master:~# tar zxf wordpress-9.0.3.tgz
root@k8s-master:~# ls wordpress

  • Chart.yaml：Chart包的核心元数据文件，记录Release名称、版本、应用版本、描述等基础信息。

  • README.md：Chart的使用说明（可选文件），使用说明文档，包含部署访问步骤、废弃提示、账号获取、迁移指引等操作提示。

  • values.yaml：默认配置参数文件，包含存储大小、存储类、账号密码、镜像地址等可自定义参数。

  • values.schema.json：values参数校验规则文件，约束配置参数的数据类型，避免部署时传入非法参数。

  • templates：k8s资源模板目录，内部包含Deployment、Service等YAML模板，部署时Helm结合values参数渲染生成真实集群资源。

  • requirements.yaml/requirements.lock：旧版Helm依赖管理文件，requirements.yaml声明当前Chart依赖的子Chart。requirements.lock文件锁定依赖Chart固定版本，保证环境一致性。

二、Helm基本操作

1. Helm安装

如果无法正常下载，可以访问我的百度云链接下载。

Helm组件包链接: https://pan.baidu.com/s/17D0-lkxhbtPGSVlgSBo55w?pwd=41jr 提取码: 41jr

[Step1] 从Helm官方下载地址，获取适用于64位Linux系统的Helm压缩安装包。

root@k8s-master:~# wget https://get.helm.sh/helm-v4.1.3-linux-amd64.tar.gz

[Step2] 将Helm压缩包解压缩，将解压出来的二进制程序移动到系统全局命令目录

root@k8s-master:~# tar xf helm-v4.1.3-linux-amd64.tar.gz
root@k8s-master:~# mv linux-amd64/helm /usr/local/bin/helm

[Step3] 生成适配Bash终端的Helm命令自动补全脚本，将脚内容重定向到系统自动补全配置目录，实现Helm命令行自动补全。

root@k8s-master:~# helm completion bash > /etc/bash_completion.d/helm

[Step4] 验证：查看Helm的版本信息，如果能够正常输出则表示Helm安装成功。

root@k8s-master:~# helm version

2. 添加仓库

[Step1] Helm官方仓库海外访问速率较低，实际部署场景中可选用自建私有仓库，或世纪互联运营的微软中国Azure开源镜像站作为替代源，提升Chart拉取速度。

root@k8s-master:~# helm repo add azure http://mirror.azure.cn/kubernetes/charts/

  • helm repo add：向本地Helm客户端新增一个Chart仓库源。

  • azure：自定义仓库名称

[Step2] 验证：查看本地Helm客户端已添加的仓库列表，可以看到上述我们添加的仓库源。

root@k8s-master:~# helm repo list

[Step3] 和Docker Hub功能相似，Helm配套提供Helm Hub平台，支持应用模板检索、在线安装，可以检索线上公共Hub的开源Chart应用包。

root@k8s-master:~# helm search hub mysql

[Step4] 搜索本地已添加仓库缓存的Chart应用包。

root@k8s-master:~# helm search repo mysql

3. Helm安装与管理WordPress

[Step1] 搜索本地已添加仓库缓存中的WordPress Chart应用包。

root@k8s-master:~# helm search repo wordpress

[Step2] WordPress Chart默认会调用集群存储类，自动创建PV和PVC资源实现数据持久化。如果集群未配置默认存储类，则需要提前完成存储类配置，否则无法正常部署该应用。执行查询命令可查看集群内所有存储类，若终端输出内容，代表集群已创建存储类。当前集群部署了基于NFS供给器的nfs-client存储类，具备持久化存储能力，但并未将其配置为集群默认存储类。若要正常部署WordPress应用，有两种处理方案，要么将nfs-client存储类设置为集群默认存储类，要么在安装WordPress Chart时使用values参数手动指定存储类。这里将nfs-client设置为默认存储类。

root@k8s-master:~# kubectl patch storageclass nfs-client -p '{"metadata":{"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'
root@k8s-master:~# kubectl get storageclasses.storage.k8s.io

[Step3] 安装WordPress，手动指定存储类为nfs-client，执行安装操作后，Helm会自动解析Chart模板，批量创建PVC、Service、Deployment等Kubernetes资源对象。

root@k8s-master:~# helm install wordpress azure/wordpress

[Step4] 验证：查看当前命名空间下所有已部署完成的Release，能够看到上述部署的WordPress。

root@k8s-master:~# helm list

[Step5] 验证：查看PVC和PV资源可以看到WordPress应用和MariaDB数据库对应的PVC均已绑定nfs-client存储类，状态正常。

root@k8s-worker1:~# kubectl get pv,pvc

文章标签
#kubernetes
许可协议
本文采用 署名-非商业性使用-相同方式共享 4.0 国际 许可协议，转载请注明出处。
Kubernetes NetworkPolicy与Pod流量隔离 2026-10-29
Kubernetes QoS服务质量与资源配额管理 2026-10-29

评论区