Langchain系列文章目录

01-玩转LangChain：从模型调用到Prompt模板与输出解析的完整指南
02-玩转 LangChain Memory 模块：四种记忆类型详解及应用场景全覆盖
03-全面掌握 LangChain：从核心链条构建到动态任务分配的实战指南
04-玩转 LangChain：从文档加载到高效问答系统构建的全程实战
05-玩转 LangChain：深度评估问答系统的三种高效方法（示例生成、手动评估与LLM辅助评估）
06-从 0 到 1 掌握 LangChain Agents：自定义工具 + LLM 打造智能工作流！
07-【深度解析】从GPT-1到GPT-4：ChatGPT背后的核心原理全揭秘
08-【万字长文】MCP深度解析：打通AI与世界的“USB-C”，模型上下文协议原理、实践与未来

Python系列文章目录

PyTorch系列文章目录

机器学习系列文章目录

深度学习系列文章目录

Java系列文章目录

JavaScript系列文章目录

Python系列文章目录

Go语言系列文章目录

Docker系列文章目录

01-【Docker-Day 1】告别部署噩梦：为什么说 Docker 是每个开发者的必备技能？
02-【Docker-Day 2】从零开始：手把手教你在 Windows、macOS 和 Linux 上安装 Docker
03-【Docker-Day 3】深入浅出：彻底搞懂 Docker 的三大核心基石——镜像、容器与仓库
04-【Docker-Day 4】从创建到删除：一文精通 Docker 容器核心操作命令
05-【Docker-Day 5】玩转 Docker 镜像：search, pull, tag, rmi 四大金刚命令详解
06-【Docker-Day 6】从零到一：精通 Dockerfile 核心指令 (FROM, WORKDIR, COPY, RUN)
07-【Docker-Day 7】揭秘 Dockerfile 启动指令：CMD、ENTRYPOINT、ENV、ARG 与 EXPOSE 详解
08-【Docker-Day 8】高手进阶：构建更小、更快、更安全的 Docker 镜像
09-【Docker-Day 9】实战终极指南：手把手教你将 Node.js 应用容器化
10-【Docker-Day 10】容器的“持久化”记忆：深入解析 Docker 数据卷 (Volume)
11-【Docker-Day 11】Docker 绑定挂载 (Bind Mount) 实战：本地代码如何与容器实时同步？
12-【Docker-Day 12】揭秘容器网络：深入理解 Docker Bridge 模式与端口映射
13-【Docker-Day 13】超越默认Bridge：精通Docker Host、None与自定义网络模式
14-【Docker-Day 14】Docker Compose深度解析
15-【Docker-Day 15】一键部署 WordPress！Docker Compose 实战终极指南
16-【Docker-Day 16】告别单机时代：为什么 Docker Compose 不够用，而你需要 Kubernetes？
17-【Docker-Day 17】K8s 架构全解析：深入理解 Kubernetes 的大脑 (Master) 与四肢 (Node)
18-【Docker-Day 18】告别选择困难症：一文掌握 Minikube、kind、k3d，轻松搭建你的第一个 K8s 集群
19-【Docker-Day 19】万物皆 YAML：掌握 Kubernetes 声明式 API 的艺术
20-【Docker-Day 20】揭秘 Kubernetes 的原子单位：深入理解 Pod
21-【Docker-Day 21】Pod的守护神：ReplicaSet与ReplicationController，轻松实现应用高可用
22-【K8s-Day 22】深入解析 Kubernetes Deployment：现代应用部署的基石与滚动更新的艺术
23-【K8s-Day 23】从 Pod 的“失联”到 Service 的“牵线”：深入理解 ClusterIP 核心原理
24-【Docker-Day 24】K8s网络解密：深入NodePort与LoadBalancer，让你的应用走出集群
25-【Docker-Day 25】深入理解 Kubernetes Namespace：实现多租户与环境隔离的利器
26-【Docker-Day 26】K8s实战演练：从零开始部署一个完整的前后端分离Web应用
27-【K8s-Day 27】应用的“体检医生”：深入解析 Kubernetes 健康检查探针 (Probe)
28-【Docker-Day 28】K8s 核心配置管理：解密 ConfigMap，告别硬编码！
29-【Docker-Day 29】K8s 安全第一课：揭秘敏感信息管理器 Secret
30-【Docker-Day 30】解密 K8s 的“硬盘”：深入理解 PersistentVolume (PV) 与 PersistentVolumeClaim (PVC)
31-【Docker-Day 31】告别手动创建 PV！一文搞懂 Kubernetes StorageClass 工作原理与实战
32-【K8s-Day 32】StatefulSet 深度解析：为你的数据库和有状态应用保驾护航
33-【Docker-Day 33】掌握 K8s 任务调度：DaemonSet、Job、CronJob 实战指南
34-【Docker-Day 34】Kubernetes Ingress 详解：从小白到精通的 K8s 流量路由指南
35-【Docker-Day 35】实战部署 Nginx Ingress Controller：集群流量入口的终极指南
36-【Docker-Day 36】K8s网络解密：CNI接口如何为Pod分配IP地址？
37-【Docker-Day 37】K8s 网络“防火墙”：NetworkPolicy 深度解析与实战
38-【Docker-Day 38】Kubernetes 核心调度：深入解析资源请求 (Requests) 与限制 (Limits) 的奥秘
39-【Docker-Day 39】揭秘 Kubernetes 高级调度：从 nodeSelector 到亲和性与污点的实战指南
40-【Docker-Day 40】K8s 核心组件 HPA 深度实践：从原理到配置，实现智能扩缩容
41-【Docker-Day 41】解密 Kubernetes 权限管理：RBAC 核心概念（Role, ClusterRole）与实战演练
42-【Docker-Day 42】K8s 安全基石：掌握 ServiceAccount，精细化控制 Pod 权限
43-【Docker-Day 43】告别繁琐 YAML：K8s 包管理器 Helm 入门指南

文章目录

摘要

在 Kubernetes 的世界里，我们通过编写 YAML 文件来定义和部署应用。对于一个简单的应用，这或许还能应付。但当应用变得复杂，包含多个 Deployment、Service、ConfigMap、Secret 等资源时，管理成百上千行的 YAML 文件就成了一场噩梦：版本控制困难、配置复用性差、升级回滚操作繁琐。为了解决这一痛点，Helm 应运而生。本文将带你系统入门 Helm，从核心概念到实战操作，让你彻底告别手写和维护大量 YAML 文件的烦恼，像使用 apt 或 yum 一样轻松管理 Kubernetes 应用。

一、为什么需要 Helm？从“手工作坊”到“工业化生产”

在我们深入学习 Helm 之前，首先要理解它解决了什么问题。想象一下，你正在部署一个包含前端、后端、数据库和缓存的微服务应用。

1.1.1 传统 YAML 管理的困境

部署这样一个应用，你可能需要编写以下 YAML 文件：

  • frontend-deployment.yaml
  • frontend-service.yaml
  • backend-deployment.yaml
  • backend-service.yaml
  • database-statefulset.yaml
  • database-service.yaml
  • database-pvc.yaml
  • database-secret.yaml
  • cache-deployment.yaml
  • cache-service.yaml
  • app-configmap.yaml
  • … 还有更多

这些文件散落在项目各处，带来了诸多挑战：

  • 管理复杂性：如何将这些文件作为一个整体进行版本控制和部署？
  • 配置不一致：如果在多个文件中都定义了同一个标签或注解，修改时很容易遗漏，导致不一致。
  • 难以复用：如果你想在测试环境和生产环境部署同一套应用，但使用不同的配置（如副本数、镜像标签、域名等），你可能需要复制粘贴并手动修改大量 YAML，这极易出错。
  • 升级与回滚困难：应用升级意味着要依次 apply 多个新的 YAML 文件。如果升级失败，如何安全、快速地回滚到上一个稳定版本？这是一个非常复杂且高风险的操作。

1.1.2 Helm 的解决方案

Helm 将 Kubernetes 的部署管理从“手工作坊”模式提升到了“工业化生产”模式。它引入了“包”（Package）的概念，将构成一个应用的所有 K8s 资源文件打包在一起，进行统一管理。

  • 打包（Packaging）：将一个应用所需的所有 YAML 文件及配置打包成一个独立的单元，称为 Chart。
  • 配置（Configuring）：在部署时，可以轻松地覆盖 Chart 中的默认配置，无需修改原始 YAML 模板。
  • 版本化（Versioning）：对每一次部署（称为 Release）进行版本记录，实现一键升级和回滚。
  • 共享（Sharing）：可以创建和分享 Chart，或使用社区维护的成千上万个预配置好的 Chart，实现应用的开箱即用。

简单来说，Helm 是 Kubernetes 的包管理器，就像 apt 之于 Ubuntu，yum 之于 CentOS，npm 之于 Node.js。它极大地简化了 K8s 应用的发现、分享和使用。

二、Helm 的三大核心概念

要掌握 Helm，必须理解它的三个核心概念：Chart、Release 和 Repository。

Helm 客户端操作
包含多个
helm install
helm upgrade/rollback
Chart 包
Release 实例
New Release 实例
Repository 仓库

2.1.1 Chart：应用的“蓝图”

Chart 是 Helm 的包格式。它是一个包含了描述一组相关 K8s 资源所需的所有信息的目录。你可以把它想象成一个应用的“安装包”或“设计蓝图”。

一个典型的 Chart 目录结构如下：

my-chart/
├── Chart.yaml          # 包含 Chart 的元数据，如名称、版本、描述等
├── values.yaml         # Chart 的默认配置值
├── templates/          # 存放所有 K8s 资源定义的模板文件 (YAML)
│   ├── deployment.yaml
│   ├── service.yaml
│   └── ...
└── charts/             # 存放该 Chart 依赖的其他 Chart (子 Chart)
  • templates/ 目录：这是 Chart 的核心，存放的是带有 Go 模板语法的 K8s YAML 文件。Helm 会将 values.yaml 中的值渲染到这些模板中，生成最终的 K8s 清单文件。
  • values.yaml 文件：提供了模板的默认值。用户在安装 Chart 时可以提供自己的值来覆盖这些默认值，从而实现高度定制化。

2.1.2 Release：Chart 的运行实例

Release 是一个 Chart 在 Kubernetes 集群中的一个运行实例。当你使用 helm install 命令安装一个 Chart 时，Helm 会创建一个新的 Release。

  • 唯一性：同一个 Chart 可以在同一个集群中被安装多次，每次安装都会创建一个新的 Release，每个 Release 都有一个唯一的名称。例如，你可以用同一个 mysql Chart 安装一个用于开发的 mysql-dev Release 和一个用于测试的 mysql-qa Release。
  • 版本管理：对一个 Release 的所有操作（安装、升级、回滚）都会被 Helm 记录下来。helm history <release-name> 可以查看一个 Release 的所有历史版本，方便追溯和回滚。

2.1.3 Repository：Chart 的“应用商店”

Repository (或 Repo) 是用于存放和分享 Chart 的地方。它本质上是一个 HTTP 服务器，托管了一个 index.yaml 文件和一些打包好的 Chart 文件（.tgz）。

  • 公共仓库：有许多由社区或公司维护的公共仓库，如官方的 artifact hub，以及 Bitnami、Nginx 等提供的仓库，其中包含了大量常用的应用 Chart。
  • 私有仓库：你也可以搭建自己的私有仓库，用于存放公司内部的 Chart，便于团队协作和标准化。

三、Helm 实战入门

理论知识已经足够，现在让我们卷起袖子，开始动手实践。

3.1.1 安装 Helm 客户端

Helm 是一个客户端工具，你需要在能够访问 K8s 集群的机器上安装它。官方推荐使用脚本一键安装：

# 对于 Linux 或 macOS
curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash

安装完成后，验证一下版本：

helm version
# 输出示例: version.BuildInfo{Version:"v3.13.2", GitCommit:"....", GitTreeState:"clean", GoVersion:"go1.21.5"}

注意：我们使用的是 Helm 3。Helm 3 相比 Helm 2 移除了服务端的 Tiller 组件，架构更简单、更安全，已成为当前主流。

3.1.2 添加和管理 Chart 仓库

安装好 Helm 后，默认情况下没有任何仓库。我们需要手动添加。bitnami 是一个非常流行且维护良好的仓库，我们以它为例。

（1） 添加仓库

使用 helm repo add 命令添加一个新的仓库。

# helm repo add <仓库名> <仓库URL>
helm repo add bitnami https://charts.bitnami.com/bitnami
（2） 查看仓库列表

使用 helm repo list 查看已添加的仓库。

helm repo list
# 输出:
# NAME      URL
# bitnami   https://charts.bitnami.com/bitnami
（3） 更新仓库信息

添加仓库后，最好执行一次更新，以获取最新的 Chart 列表。

helm repo update
# 输出:
# Hang tight while we grab the latest from your chart repositories...
# ...Successfully got an update from the "bitnami" chart repository
# Update Complete. ⎈Happy Helming!⎈

3.1.3 查找和安装应用

现在我们的“应用商店”已经准备就绪，可以开始查找并安装应用了。我们来安装一个 Nginx。

（1） 查找 Chart

使用 helm search repo 在所有已配置的仓库中查找 Chart。

helm search repo nginx
# 输出会列出所有包含 "nginx" 关键词的 Chart
# NAME                            CHART VERSION   APP VERSION     DESCRIPTION
# bitnami/nginx                   15.6.3          1.25.3          NGINX Open Source is a web server that can be a...
# bitnami/nginx-ingress-controller 9.9.4           1.9.4           NGINX Ingress Controller is an Ingress controll...
# ...

我们选择 bitnami/nginx。

（2） 安装 Chart

使用 helm install 命令来安装 Chart，创建一个 Release。

# helm install <自定义的Release名称> <Chart名称>
helm install my-nginx bitnami/nginx

# 如果你想指定命名空间，可以加上 -n 参数
# helm install my-nginx bitnami/nginx -n web-apps --create-namespace

Helm 会输出一大段信息，告诉你应用已经部署，并提示你如何访问它。

（3） 查看 Release 状态

使用 helm ls 或 helm list 查看当前命名空间下的所有 Release。

helm ls
# 输出:
# NAME      NAMESPACE   REVISION    UPDATED                                 STATUS      CHART           APP VERSION
# my-nginx  default     1           2023-11-20 15:30:00.123456 +0800 CST    deployed    nginx-15.6.3    1.25.3

STATUS 为 deployed 表示部署成功。

3.1.4 管理已安装的应用（Release）

Helm 的强大之处在于对已部署应用生命周期的管理。

（1） 升级 Release

假设我们想把 Nginx 的副本数从默认的 1 个增加到 3 个。我们可以使用 helm upgrade 命令，并通过 --set 参数覆盖 values.yaml 中的值。

# 使用 --set 参数临时修改配置并升级
helm upgrade my-nginx bitnami/nginx --set replicaCount=3

# 查看历史记录，你会发现 REVISION 变成了 2
helm history my-nginx
（2） 回滚 Release

如果升级后发现应用出现问题，可以轻松回滚到上一个版本。

# 回滚 my-nginx 到第 1 个版本
helm rollback my-nginx 1

# 再次查看历史记录，会看到 REVISION 3 是一个回滚操作
helm history my-nginx
（3） 卸载 Release

当不再需要这个应用时，使用 helm uninstall 可以干净地删除该 Release 创建的所有 K8s 资源。

helm uninstall my-nginx

# 再次查看列表，my-nginx 已经消失了
helm ls

四、创建你的第一个 Chart

消费别人的 Chart 固然方便，但要真正掌握 Helm，还需学会创建自己的 Chart。

4.1.1 使用 helm create 脚手架

Helm 提供了 helm create 命令，可以快速生成一个标准的 Chart 目录结构。

helm create my-first-chart
# 这会创建一个名为 my-first-chart 的目录

进入该目录，你会看到我们之前介绍的标准结构，里面包含了一些示例文件，这是学习的最佳起点。

4.1.2 解析 Chart 目录结构

  • Chart.yaml: 定义 Chart 的基本信息。 
    apiVersion: v2
name: my-first-chart
description: A Helm chart for Kubernetes
type: application
version: 0.1.0 # 这是 Chart 的版本
appVersion: "1.16.0" # 这是你的应用版本
  • values.yaml: 定义所有可配置的参数。helm create 生成的 values.yaml 包含了非常丰富的示例，如 replicaCount, image, service, ingress 等。
  • templates/: 存放所有资源模板。
    • _helpers.tpl: 存放一些可复用的模板片段，称为 “named templates”。
    • deployment.yaml, service.yaml, ingress.yaml: 分别是 Deployment、Service 和 Ingress 的模板，它们会引用 values.yaml 中的值。

4.1.3 打包与验证

在分发你的 Chart 之前，最好先进行检查和打包。

（1） 语法检查 (Linting)

helm lint 命令会检查 Chart 是否遵循了最佳实践和语法规范。

cd my-first-chart
helm lint .
# 如果没有问题，会输出:
# ==> Linting .
# [INFO] Chart.yaml: icon is recommended
# 1 chart(s) linted, 0 chart(s) failed
（2） 打包 Chart

helm package 命令会将整个 Chart 目录打包成一个 .tgz 压缩文件，这个文件就是可以分发和安装的 Chart 包。

helm package .
# 输出: Successfully packaged chart and saved it to: /path/to/my-first-chart-0.1.0.tgz

这个 .tgz 文件就可以上传到你的 Chart Repository，或者直接通过 helm install my-app ./my-first-chart-0.1.0.tgz 进行安装。

五、总结

本文系统地介绍了 Kubernetes 包管理器 Helm，旨在帮助你从繁琐的 YAML 管理中解放出来。通过今天的学习，我们掌握了以下核心内容：

  1. Helm 的价值：解决了原生 Kubernetes YAML 文件管理复杂、配置复用性差、版本控制困难的核心痛点，是实现 K8s 应用标准化部署与管理的关键工具。
  2. 三大核心概念：
    • Chart：应用的打包格式，如同应用的“蓝图”或“安装包”。
    • Release：Chart 在集群中的一个运行实例，每次安装或升级都会产生新的版本。
    • Repository：存放和分享 Chart 的“应用商店”，可以是公共的也可以是私有的。
  3. 核心实战技能：
    • 环境准备：学会了如何安装 Helm 3 客户端，并添加和更新 Chart 仓库。
    • 应用管理：掌握了 helm install, upgrade, rollback, uninstall 等命令，实现了对应用生命周期的完整管理。
  4. 初步创造能力：了解了如何使用 helm create 创建一个标准化的 Chart，并对其进行语法检查（lint）和打包（package），为后续深度定制 Chart 打下了坚实的基础。

掌握 Helm 是每一位 Kubernetes 从业者从入门走向专业的必经之路。在下一篇文章中，我们将深入探讨 Helm Chart 的心脏——模板（Templates）和值（Values），学习如何编写更灵活、更强大的 Chart。

# docker # kubernetes # 容器 # 人工智能 # 操作系统 # 数据结构与算法
Logo
开源鸿蒙跨平台开发者社区

开源鸿蒙跨平台开发社区汇聚开发者与厂商，共建“一次开发，多端部署”的开源生态，致力于降低跨端开发门槛，推动万物智联创新。

更多推荐

cover

开源鸿蒙 Flutter 实战｜搜索功能页面完整实现指南

avatar 开源鸿蒙跨平台开发者社区

【Flutter for OpenHarmony】原生卡片 Widget 集成实战：从零构建待办清单桌面组件

本方案展示了在 Flutter for OpenHarmony 项目中集成原生卡片 Widget 的完整路径。核心思路是通过 Platform Channel 建立 Flutter 与 ArkUI 之间的通信桥梁，让 Flutter 业务层的数据能够流向原生 UI 组件，同时让原生的用户交互能够反馈到 Flutter 逻辑层。这种架构设计的优势在于保持了 Flutter 和 ArkUI 各自的特性

avatar 开源鸿蒙跨平台开发者社区

Flutter 三方库 app_widget 的鸿蒙化适配指南

通过 app_widget 三方库，我们只用 Flutter 代码就能轻松实现鸿蒙原生桌面卡片，是不是超棒？这个库不仅简化了跨平台开发的流程，还让我们能充分利用鸿蒙生态的特性，为用户提供更好的体验。宝子们，赶紧动手试试吧！如果有什么问题，可以去开源鸿蒙跨平台社区提问哦，地址是： https://openharmonycrossplatform.csdn.net ，那里有很多热心的开发者会帮助你哒！

avatar 开源鸿蒙跨平台开发者社区