k8s（十）Helm详解

---

前言

在 Kubernetes（K8s）成为容器编排领域事实标准的今天，如何高效管理复杂应用的部署与生命周期，成为运维和开发团队面临的核心挑战。未使用工具前，部署一个应用需手动编写并执行 Deployment、Service 等多个资源清单文件，步骤繁琐且易出错；随着微服务架构普及，应用组件增多，版本控制、环境一致性、回滚等需求更让管理难度呈指数级上升。

Helm 作为 Kubernetes 官方推荐的包管理器，恰好解决了这一系列痛点。它通过“Chart 打包”将应用的所有资源清单整合为可复用的软件包，结合“Repository 仓库”实现 Chart 的集中存储与分发，再以“Release 实例”管理每次部署的版本，让 K8s 应用的部署、升级、回滚变得标准化、自动化。无论是快速部署开源应用（如 MySQL、Redis），还是自定义企业内部服务模板，Helm 都能大幅提升效率、降低运维成本。

本文基于 Helm3（当前主流版本，移除了 Helm2 中存在安全风险的 Tiller 组件），从核心概念入手，逐步讲解安装配置、仓库管理、自定义 Chart、Harbor 私有仓库集成等实操内容，同时梳理文档中不适合生产环境的配置并给出优化建议，助力读者全面掌握 Helm 并应用于实际工作。

一、Helm 核心概念与价值

1.1 Helm 是什么

未采用 Helm 前，Kubernetes 应用部署需要手动创建 Deployment、Service 等多种资源，操作流程繁琐。特别是在微服务架构下，容器化应用的部署与管理复杂度显著提升。

Helm 作为 Kubernetes 的包管理工具，其功能类似于 Linux 系统中的 YUM 或 APT。它通过打包机制实现应用发布的版本控制，核心功能是动态生成 Kubernetes 资源清单文件（如 deployment.yaml、service.yaml），并自动调用 Kubectl 完成部署，大幅简化了 Kubernetes 应用的部署与管理。

1.2 Helm 三大核心概念

Helm 的核心架构围绕三大关键概念构建，分别对应"应用打包"、“资源存储"和"运行实例”，共同实现应用全生命周期管理：

• Chart：Helm 的应用打包格式，采用 TAR 归档，功能类似 DEB/RPM 等系统软件包。作为 Kubernetes 资源配置模板的集合，它包含定义应用所需资源的 YAML 文件组。

• Repository（仓库）：Chart 的集中存储站点，通过 Web 服务器提供两个核心功能：存储 Chart 包文件、维护可供查询的包清单。Helm 支持配置多个独立仓库源。

• Release：Chart 在集群中的具体部署实例，通过 helm install 创建。同一 Chart 允许多实例部署，每个实例生成唯一的 Release（可视为应用部署版本）。举例来说，部署两个 MySQL 服务只需两次安装同一 Chart，每个实例都将获得独立的 Release 名称和运行环境。

二、Helm3 与 Helm2 的核心区别

Helm2 采用 C/S（客户端-服务端）架构，而 Helm3 移除了服务端组件，架构更简洁、安全，具体差异如下表所示：

对比维度	Helm2	Helm3
架构模式	C/S 架构，包含客户端 helm 和服务端 Tiller	仅客户端架构，无 Tiller 组件
权限控制	Tiller 通常部署在 kube-system 命名空间，需绑定拥有集群全权限的 ServiceAccount，存在权限过大风险	客户端直接读取本地 kubeconfig 文件，使用文件中预定义的权限执行操作，符合 Kubernetes 最小权限原则
操作逻辑	用户通过本地 helm 命令连接 Tiller，由 Tiller 创建/修改/删除 Kubernetes 资源	用户通过 helm 命令直接与 Kubernetes API 交互，操作更直接、安全

Helm 官方网站：https://helm.sh/

三、Helm3 部署与使用流程

3.1 安装 Helm 客户端

3.1.1 下载与安装二进制文件

通过官方 GitHub 仓库下载对应版本的 Helm 客户端安装包，以 Linux 系统为例，操作命令如下：

# 下载指定版本的 Helm 客户端安装包（此处以 v3.6.0 为例）
wget https://github.com/helm/helm/tags  # 进入页面后选择对应版本，如 helm-v3.6.0-linux-amd64.tar.gz
# 解压安装包
tar -zxvf helm-v3.6.0-linux-amd64.tar.gz
# 将 helm 可执行文件移动到系统 PATH 目录
mv linux-amd64/helm /usr/local/bin/
# 验证安装是否成功，查看版本信息
helm version

3.1.2 配置命令补全

为提升操作效率，可配置 Helm 命令的 bash 补全功能：

source <(helm completion bash)

3.2 管理 Chart 仓库

3.2.1 添加常用仓库

Helm 仓库提供各类现成的 Chart 包，可添加公开仓库（如 Bitnami、阿里云仓库）方便后续使用：

# 添加 Bitnami 仓库（常用开源应用 Chart，如 Redis、MySQL）
helm repo add bitnami https://charts.bitnami.com/bitnami
# 添加阿里云仓库（国内仓库，下载速度快）
helm repo add aliyun https://kubernetes.oss-cn-hangzhou.aliyuncs.com/charts
# 添加稳定版仓库（Azure 镜像，包含大量成熟应用 Chart）
helm repo add stable http://mirror.azure.cn/kubernetes/charts
# 添加孵化版仓库（包含未正式发布的实验性 Chart），不建议在生产环境使用
helm repo add incubator https://charts.helm.sh/incubator

3.2.2 仓库基本操作

包括更新仓库索引、查看仓库列表、搜索 Chart、删除仓库等，命令如下：

# 更新仓库索引，确保获取最新的 Chart 信息
helm repo update          
# 查看已添加的仓库列表
helm repo list
# 搜索指定仓库（如 stable）中的可用 Chart
helm search repo stable
# 删除指定仓库（如 incubator，若无需使用实验性 Chart）
helm repo remove incubator

3.3 安装与管理 Release

3.3.1 查看 Chart 信息

在安装 Chart 前，可先查看 Chart 的基本信息或完整配置，避免部署后出现参数不匹配问题：

# 查看指定 Chart（如 stable/mysql）的基本信息（版本、描述、依赖等）
helm show chart stable/mysql     
# 查看指定 Chart 的所有信息（包含 values 配置、模板内容等）
helm show all stable/mysql		

3.3.2 安装 Chart（创建 Release）

安装 Chart 时需指定 Release 名称（或自动生成），并可选择部署的命名空间，命令如下：

# 方式1：指定 Release 名称（my-redis），部署到 default 命名空间
helm install my-redis bitnami/redis -n default   
# 方式2：不指定 Release 名称，使用 --generate-name 随机生成
helm install bitnami/redis --generate-name    

3.3.3 查看与删除 Release

安装后可查看 Release 状态，若需卸载应用则删除对应的 Release：

# 查看所有已部署的 Release
helm ls 
helm list
# 查看指定 Release（如 my-redis）的详细状态（部署时间、Pod 状态、访问方式等）
helm status my-redis               
# 删除指定 Release（如 my-redis），同时删除对应的 Kubernetes 资源
helm uninstall my-redis 

四、Helm 自定义 Chart 与高级操作

4.1 自定义 Chart 基础

4.1.1 理解 Chart 目录结构

Chart 本质是一组按固定结构组织的文件目录，可通过拉取现有 Chart 或创建新 Chart 了解其结构。以拉取 stable/mysql Chart 为例：

# 创建工作目录并进入
mkdir /opt/helm && cd /opt/helm
# 拉取 stable/mysql Chart（需确保已添加 stable 仓库）
helm pull stable/mysql
# 解压 Chart 包（假设解压后目录为 mysql）
tar xf mysql-1.6.9.tgz
# 安装 tree 工具并查看目录结构
yum install -y tree && tree mysql

解压后的 Chart 目录结构如下，核心文件功能已标注：

mysql
├── Chart.yaml          # Chart 自描述文件，必须包含 name（Chart 名称）和 version（Chart 版本）
├── README.md           # Chart 使用说明（如参数配置、部署步骤）
├── templates           # 模板目录，包含 Kubernetes 资源清单模板
│   ├── configurationFiles-configmap.yaml  # 配置文件相关的 ConfigMap 模板
│   ├── deployment.yaml                    # Deployment 资源模板（核心，定义应用运行方式）
│   ├── _helpers.tpl                       # 模板助手，存放可重复使用的模板片段（如变量定义）
│   ├── initializationFiles-configmap.yaml # 初始化文件相关的 ConfigMap 模板
│   ├── NOTES.txt                          # 帮助文本，安装后显示给用户（如访问地址、默认密码）
│   ├── pvc.yaml                           # PersistentVolumeClaim 模板（定义存储需求）
│   ├── secrets.yaml                       # Secret 模板（存储敏感信息，如数据库密码）
│   ├── serviceaccount.yaml                # ServiceAccount 模板（定义应用运行的权限账号）
│   ├── servicemonitor.yaml                # ServiceMonitor 模板（用于 Prometheus 监控）
│   ├── service.yaml                       # Service 模板（定义应用访问方式）
│   ├── ingress.yaml                       # Ingress 模板（定义外部访问规则）
│   └── tests                              # 测试模板目录
│       ├── test-configmap.yaml            # 测试用 ConfigMap
│       └── test.yaml                      # 测试用 Pod 模板（验证应用部署是否成功）
└── values.yaml         # 配置文件，存储模板中使用的变量默认值（可通过此文件快速修改配置）

4.1.2 创建自定义 Chart

使用 helm create 命令可快速生成一个基础 Chart 框架，后续只需修改核心文件即可：

# 创建名为 nginx 的自定义 Chart
helm create nginx
# 查看生成的 Chart 目录结构
tree nginx

生成的 nginx Chart 结构与上述 mysql Chart 类似，包含 Chart.yaml、values.yaml、templates 等核心文件。

4.2 修改与打包自定义 Chart

4.2.1 修改核心配置文件

自定义 Chart 时，主要修改 Chart.yaml（Chart 元信息）和 values.yaml（模板变量配置），无需频繁修改 templates 目录下的模板文件（除非需自定义资源结构）。

（1）修改 Chart.yaml

定义 Chart 的基本信息，如名称、版本、应用版本等：

apiVersion: v2
name: nginx                     # Chart 名称（需唯一）
description: A Helm chart for Kubernetes  # Chart 描述
type: application               # Chart 类型，application（应用类）或 library（库类，供其他 Chart 依赖）
version: 0.1.0                  # Chart 版本（遵循语义化版本，如 0.1.0、1.2.3）
appVersion: 1.16.0              # 应用本身的版本（如 Nginx 版本）

（2）修改 values.yaml

配置模板中使用的变量默认值，如副本数、镜像地址、服务类型、Ingress 规则等：

replicaCount: 1  # 应用副本数，默认 1 个 Podimage:repository: nginx  # 容器镜像仓库地址pullPolicy: IfNotPresent  # 镜像拉取策略（本地有则不拉取）tag: "latest"  # 镜像标签，可改为具体版本（如 1.25.3）imagePullSecrets: []  # 镜像拉取密钥（私有仓库需配置）
nameOverride: ""  # 覆盖 Chart 名称的前缀
fullnameOverride: ""  # 覆盖 Release 的完整名称serviceAccount:create: true  # 是否自动创建 ServiceAccountannotations: {}  # ServiceAccount 的注解name: ""  # ServiceAccount 名称（不填则自动生成）podAnnotations: {}  # Pod 的注解
podSecurityContext: {}  # Pod 的安全上下文（如用户组）
#  fsGroup: 2000securityContext: {}  # 容器的安全上下文（如权限限制）
#  capabilities:
#    drop:
#    - ALL
#  readOnlyRootFilesystem: true
#  runAsNonRoot: true
#  runAsUser: 1000service:type: ClusterIP  # 服务类型（ClusterIP、NodePort、LoadBalancer）port: 80  # 服务暴露的端口ingress:enabled: true  # 是否启用 Ingress（外部访问需开启）className: ""  # Ingress Class（指定使用的 Ingress Controller）annotations: {}  # Ingress 注解（如配置 Nginx Ingress 规则）# kubernetes.io/ingress.class: nginx# kubernetes.io/tls-acme: "true"hosts:- host: www.app.com  # Ingress 绑定的域名（需配置 DNS 或 hosts）paths:- path: /  # 访问路径pathType: Prefix  # 路径匹配类型（Prefix、Exact、ImplementationSpecific）tls: []  # TLS 配置（HTTPS 需配置）#  - secretName: chart-example-tls#    hosts:#      - chart-example.localresources:  # 资源限制与请求（避免应用占用过多资源）limits:cpu: 100m  # CPU 上限memory: 128Mi  # 内存上限requests:cpu: 100m  # CPU 请求（调度时分配的最小资源）memory: 128Mi  # 内存请求autoscaling:  # 自动扩缩容配置（默认关闭）enabled: falseminReplicas: 1  # 最小副本数maxReplicas: 100  # 最大副本数targetCPUUtilizationPercentage: 80  # CPU 使用率阈值（触发扩容）# targetMemoryUtilizationPercentage: 80  # 内存使用率阈值nodeSelector: {}  # 节点选择器（指定应用部署在哪些节点）
tolerations: []  # 污点容忍（允许应用部署在有污点的节点）
affinity: {}  # 节点亲和性/反亲和性（控制 Pod 调度策略）

4.2.2 打包与验证 Chart

修改完成后，需验证 Chart 配置是否正确，再打包为 TAR 格式以便部署或上传到仓库：

# 检查 Chart 的依赖和模板配置是否正确（无报错则配置正常）
helm lint nginx        
# 打包 Chart，当前目录下生成压缩包（如 nginx-0.1.0.tgz，名称格式为“Chart名-版本号.tgz”）
helm package nginx     

4.3 部署、升级与回滚自定义 Chart

4.3.1 部署自定义 Chart

部署前可先“预演”验证配置，再正式部署，避免直接部署出现问题：

# 方式1：预演部署（--dry-run --debug），仅验证配置不实际执行安装
helm install nginx ./nginx --dry-run --debug    
# 方式2：正式部署到 default 命名空间（使用本地 Chart 目录）
helm install nginx ./nginx -n default           
# 方式3：使用打包后的 Chart 文件部署
helm install nginx ./nginx-0.1.0.tgz
# 方式4：使用自定义配置文件部署（values-prod.yaml 覆盖默认 values.yaml）
helm install nginx ./nginx -f ./nginx/values-prod.yaml

部署后可通过 helm ls 和 kubectl get pod,svc 查看部署状态：

# 查看 Release 列表（确认 nginx 已部署）
helm ls
# 查看 Pod 和 Service 状态（确认应用正常运行）
kubectl get pod,svc

4.3.2 配置 Ingress 实现外部访问

若需通过域名访问应用，需部署 Ingress Controller 并配置 Ingress 规则，操作如下：

# 下载 Ingress Controller 部署文件（以 nginx-ingress v0.30.0 为例）
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
# 部署 Ingress Controller
kubectl apply -f mandatory.yaml
kubectl apply -f service-nodeport.yaml
# 查看 Ingress Controller 运行状态（确保 Pod 正常、Service 暴露 NodePort）
kubectl get pod,svc -n ingress-nginx
# 查看 Ingress 规则（确认已绑定域名和服务）
kubectl get ingress
# 配置本地 hosts（将域名解析到 Ingress Controller 所在节点 IP）
vim /etc/hosts
# 添加一行：192.168.10.21 node02 www.kgc.com（IP 替换为实际节点 IP，域名替换为配置的 Ingress 域名）
# 测试外部访问（通过 NodePort 访问，端口从 ingress-nginx Service 中获取，如 30665）
curl http://www.kgc.com:30665

4.3.3 升级 Release

若需修改应用配置（如服务类型改为 NodePort、调整资源限制），可通过 helm upgrade 实现，升级后 Release 版本会自动加 1：

# 1. 修改 values.yaml（如将服务类型改为 NodePort 并指定端口）
vim nginx/values.yaml
service:type: NodePortport: 80nodePort: 30080  # 指定 NodePort（需在集群允许的端口范围内，默认 30000-32767）
ingress:enabled: false  # 若使用 NodePort 访问，可关闭 Ingress# 2. （可选）修改 service.yaml 模板，确保 nodePort 配置生效
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: httpprotocol: TCPname: httpnodePort: {{ .Values.service.nodePort }}  # 新增 nodePort 配置，引用 values 中的变量# 3. 执行升级命令
helm upgrade my-nginx nginx # 4. 验证升级结果（查看 Service 类型和端口是否已修改）
kubectl get svc
# 测试 NodePort 访问
curl 192.168.10.120:30080  # IP 替换为节点 IP，端口替换为配置的 nodePort

4.3.4 回滚 Release

若升级后出现问题，可通过 helm rollback 回滚到之前的 Release 版本：

# 1. 查看 Release 版本历史（获取需回滚的版本号，如版本 1）
helm history my-nginx  

# 2. 回滚到指定版本（如回滚到版本 1）
helm rollback my-nginx 1          # 3. 再次查看历史，确认回滚成功
helm history my-nginx           

版本 3 为回滚后的版本，状态为 deployed，描述为“Rollback to 1”

4.3.5 命令行直接指定参数部署/升级

若只需临时修改少量配置，可通过 --set 参数在命令行直接指定，无需修改 values.yaml（该参数会覆盖 values.yaml 中的默认值）：

# 升级 nginx Release，将镜像标签改为 1.15（覆盖 values.yaml 中的 image.tag）
helm upgrade my-nginx nginx --set image.tag='1.15'

五、Helm 仓库进阶：使用 Harbor 作为本地仓库

Harbor 是 VMware 开源的容器镜像仓库，同时支持存储 Helm Chart。将自定义 Chart 上传到 Harbor，可实现 Chart 的私有化管理与共享。

5.1 安装 Harbor

5.1.1 准备环境与安装文件

Harbor 依赖 Docker 和 Docker Compose，需先确保环境已安装，再上传安装包：

# 1. 上传 Harbor 安装包和 Docker Compose 到 /opt 目录
# （Harbor 安装包示例：harbor-offline-installer-v1.9.1.tgz，Docker Compose 为可执行文件）
cd /opt
# 2. 配置 Docker Compose（若未安装）
cp docker-compose /usr/local/bin/
chmod +x /usr/local/bin/docker-compose
# 3. 解压 Harbor 安装包
tar zxf harbor-offline-installer-v1.9.1.tgz
cd harbor/

5.1.2 修改 Harbor 配置文件

修改 harbor.yml 配置 Harbor 的域名、管理员密码、数据存储路径等：

hostname: 192.168.10.120  # Harbor 服务器 IP 或域名（需确保客户端可访问）
harbor_admin_password: Harbor12345  # 管理员（admin）初始密码
data_volume: /data  # 数据存储路径（自动创建，存储镜像和 Chart 数据）
chart:absolute_url: enabled  # 启用 Chart 的绝对 URL（确保 Chart 可正常下载）
log:level: info  # 日志级别（info、warn、error 等）local:rotate_count: 50  # 日志文件轮转次数rotate_size: 200M  # 单个日志文件大小上限location: /var/log/harbor  # 日志存储路径

5.1.3 安装 Harbor（含 Chart 仓库服务）

执行安装脚本，同时启用 Clair（镜像安全扫描）和 Chartmuseum（Chart 仓库服务）：

# 安装带有 Clair 和 Chartmuseum 的 Harbor
./install.sh --with-clair --with-chartmuseum

5.2 配置 Helm 推送 Chart 到 Harbor

5.2.1 安装 Helm Push 插件

Helm 需安装 Push 插件才能将 Chart 推送到 Harbor，支持在线和离线安装两种方式：

# 方式1：在线安装（需联网）
helm plugin install https://github.com/chartmuseum/helm-push# 方式2：离线安装（无网络环境时使用）
# 下载插件安装包
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 插件列表，包含 push 插件即正常）
helm repo ls  # 插件安装后不影响 repo 列表，仅新增 push 命令

5.2.2 在 Harbor 中创建 Chart 项目

通过 Harbor Web UI 创建公开或私有项目，用于存储 Chart：

1. 浏览器访问 Harbor 地址（如 http://192.168.10.19），使用管理员账号（admin/Harbor12345）登录。
2. 点击“+新建项目”，输入项目名称（如 chart_repo），访问级别勾选“公开”（方便其他用户拉取），点击“确定”。

5.2.3 添加 Harbor 仓库到 Helm

将 Harbor 中的项目作为 Helm 仓库添加到本地，后续可通过该仓库推送/拉取 Chart：

# 添加 Harbor 仓库，格式：helm repo add <仓库名> <Harbor URL>/chartrepo/<项目名> --username=<Harbor 用户名> --password=<Harbor 密码>
helm repo add harbor http://192.168.10.120/chartrepo/chart_repo --username=admin --password=Harbor12345
# 说明：若不指定项目名，默认使用 Harbor 中的 library 项目

5.2.4 推送 Chart 到 Harbor

将自定义的 Chart（如之前创建的 nginx Chart）推送到 Harbor 仓库：

# 进入 Chart 所在目录（如 /opt/helm）
cd /opt/helm
# 推送 Chart 到 Harbor 仓库（仓库名为 harbor，即上一步添加的仓库名）
helm push nginx harbor
# 推送成功后，可在 Harbor Web UI 的 chart_repo 项目中查看已上传的 Chart

总结

本文围绕 Helm3 展开，系统覆盖了从概念理解到落地实践的全流程，核心内容可归纳为以下三点：

1. 核心价值与架构优势
   Helm 通过 Chart（软件包）、Repository（仓库）、Release（实例）三大概念，将 K8s 应用管理从“零散的资源操作”升级为“标准化的包管理”，解决了手动部署的繁琐性与版本失控问题。相比 Helm2，Helm3 移除 Tiller 组件后，直接通过 kubeconfig 权限控制与 K8s API 交互，既简化了架构，又符合 K8s 最小权限原则，安全性与易用性显著提升。

2. 关键实操流程
   从 Helm 客户端安装、仓库管理（添加/更新/搜索成熟仓库如 Bitnami、阿里云），到基于现有 Chart 快速部署应用；再到自定义 Chart（理解目录结构、修改 Chart.yaml 与 values.yaml、打包验证），以及部署后的升级、回滚操作，形成了“部署-管理-迭代”的完整闭环。同时，通过集成 Harbor 私有仓库，实现了自定义 Chart 的私有化存储与团队共享，满足企业级场景需求。

3. 生产环境优化建议
   文档中部分配置（如使用 incubator 实验性仓库、旧版本 Ingress Controller 与 Harbor）存在稳定性或安全性隐患，生产环境需优先选择成熟仓库（Bitnami）、最新稳定版组件（nginx-ingress v1.0+、Harbor v2.10+），并简化自定义 Chart 结构（删除冗余模板），确保部署的可靠性与可维护性。

掌握 Helm 不仅是掌握一个工具，更是建立 K8s 应用的标准化管理思维。无论是快速交付开源组件，还是沉淀企业内部服务模板，Helm 都是提升 K8s 运维效率的核心利器，建议在实践中结合具体业务场景，进一步探索 Chart 模板复用、多环境配置隔离等高级用法，最大化其价值。