Helm本质就是让k8s的应用管理（Deployment、Service等）可配置，能动态生成。通过动态生成K8S资源清单文（deployment.yaml、service.yaml）。然后kubectl自动调用K8S资源部署。
Helm 让部署和管理 Kubernetes 应用从"手写一堆配置文件"变成了"管理一个可配置的软件包"，极大地提升了效率和可靠性。
一、Helm概述
helm通过打包的方式，支持发布的版本管理和控制，很大程度上简化了Kubernetes应用的部署和管理。
简单来说，就是：让不懂k8s的人，直接通过helm安装，将一个个配好的资源对象的Yaml文件放在一起进行统一配置部署，实现目标环境的搭建。
1.1、Helm 组件及相关术语
Helm是官方提供类似于YUM的包管理，是部署环境的流程封装，Helm有三个重要的概念：chart、release和Repository
-
Helm：Helm 是一个命令行下的客户端工具。主要用于 Kubernetes 应用程序 Chart 的创建、打包、发布以及创建和管理本地和远程的 Chart 仓库。
-
Tiller：Tiller 是 Helm 的服务端，部署在 Kubernetes 集群中。Tiller 用于接收 Helm 的请求，并根据 Chart 生成 Kubernetes 的部署文件（ Helm 称为 Release ），然后提交给 Kubernetes 创建应用。Tiller 还提供了 Release 的升级、删除、回滚等一系列功能。
-
Chart：Helm 的软件包，采用 TAR 格式。类似于 APT 的 DEB 包或者 YUM 的 RPM 包，其包含了一组定义 Kubernetes 资源相关的 YAML 文件。Chart有特定的文件目录结构，如果开发者想自定义一个新的 Chart，只需要使用Helm create命令生成一个目录结构即可进行开发。
-
Repoistory：Helm 的软件仓库，Repository 本质上是一个 Web 服务器，该服务器保存了一系列的 Chart 软件包以供用户下载，并且提供了一个该 Repository 的 Chart 包的清单文件以供查询。Helm 可以同时管理多个不同的 Repository， 官方仓库的地址是https://hub.helm.sh。
-
Release：使用 helm install 命令在 Kubernetes 集群中部署的 Chart 称为 Release。
1.2、Helm工作原理
1、Chart Install 过程：
-
Helm从指定的目录或者tgz文件中解析出Chart结构信息
-
Helm将指定的Chart结构和Values信息通过gRPC传递给Tiller
-
Tiller根据Chart和Values生成一个Release
-
Tiller将Release发送给Kubernetes用于生成Release
2、Chart Update过程：
-
Helm从指定的目录或者tgz文件中解析出Chart结构信息
-
Helm将要更新的Release的名称和Chart结构，Values信息传递给Tiller
-
Tiller生成Release并更新指定名称的Release的History
-
Tiller将Release发送给Kubernetes用于更新Release
3、Chart Rollback过程：
-
Helm将要回滚的Release的名称传递给Tiller
-
Tiller根据Release的名称查找History
-
Tiller从History中获取上一个Release
-
Tiller将上一个Release发送给Kubernetes用于替换当前Release
二、Helm部署
Helm由命令helm工具和服务端tiller组成。helm的GitHub地址：https://github.com/helm/helm
2.1、安装方式
bash
[root@k8s-master01 ~]# mkdir helm
[root@k8s-master01 helm]# wget https://get.helm.sh/helm-v3.14.0-linux-amd64.tar.gz
[root@k8s-master01 helm]# tar -zxvf helm-v3.14.0-linux-amd64.tar.gz
[root@k8s-master01 helm]# cd linux-amd64/
[root@k8s-master01 linux-amd64]# cp helm /usr/local/bin/
[root@k8s-master01 linux-amd64]# echo "source <(helm completion bash)" >> ~/.bashrc
[root@k8s-master01 linux-amd64]# source ~/.bashrc2.2、chart库配置
做完上述设置后即可使用helm search搜索官方helm hub chart库
bash
helm search hub nginx添加第三方Chart库
bash
helm repo add aliyun https://kubernetes.oss-cn-hangzhou.aliyuncs.com/charts
helm repo add bitnami https://charts.bitnami.com/bitnami查看Chart库
bash
helm repo list从仓库中查找指定chart的名字
bash
helm search repo nginx
2.3、Helm命令
| 命令字 | 中文释义 | 作用 |
|---|---|---|
| completion | 完成 | 生成特定Shell的自动补全脚本 |
| create | 创建 | 使用给定的名称创建新图表 |
| dependency | 依赖 | 管理图表的依赖关系 |
| env | 环境 | Helm客户端环境信息 |
| get | 获取 | 下载已命名发布的扩展信息 |
| help | 帮助 | 关于任何命令的帮助 |
| history | 历史 | 获取发布历史记录 |
| install | 安装 | 安装图表 |
| lint | 检查 | 检查图表可能存在的问题 |
| list | 列表 | 列出发布 |
| package | 打包 | 将图表目录打包成图表存档 |
| plugin | 插件 | 安装、列出或卸载Helm插件 |
| pull | 拉取 | 从存储库下载图表，并可选在本地目录中解包 |
| push | 推送 | 将图表推送到远程存储库 |
| registry | 注册表 | 登录或注销注册表 |
| repo | 仓库 | 添加、列出、删除、更新和索引图表存储库 |
| rollback | 回滚 | 将发布回滚到先前版本 |
| search | 搜索 | 在图表中搜索关键字 |
| show | 显示 | 显示图表的信息 |
| status | 状态 | 显示指定发布的状态 |
| template | 模板 | 本地渲染模板 |
| test | 测试 | 运行发布的测试 |
| uninstall | 卸载 | 卸载发布 |
| upgrade | 升级 | 升级发布 |
| verify | 验证 | 验证给定路径的图表已签名并且有效 |
| version | 版本 | 打印客户端版本信息 |
创建新图表 （自己创建模板时只有默认一个nginx模板）
拉取镜像并解压
cd到图表中安装图表
先暴漏端口
定义名称安装chart
查看端口号并访问
查看版本
修改添加三个副本重新发布
历史查看
版本回滚
三、蓝绿发布和金丝雀发布
1、蓝绿发布（风险大 几乎不用）
在Kubernetes中，蓝绿发布（Blue-Green Deployment） 是一种部署策略，通过同时维护两个完全独立的生产环境（"蓝"和"绿"），在验证新版本（绿）后，一次性将流量从旧版本（蓝）切换到新版本，若发现问题则立即回退。其核心特点是零停机时间 和快速回滚。
蓝绿发布的核心原理
-
双环境共存：
-
蓝环境（Blue）：当前生产环境，处理所有用户流量。
-
绿环境（Green）：新版本环境，部署完成后处于待命状态。
-
-
流量切换：
- 通过更新负载均衡规则或Service选择器，将所有流量从蓝环境切换到绿环境。
-
快速回滚：
- 若绿环境异常，只需将流量重新指向蓝环境即可恢复。（没有过度）
2、金丝雀发布
在Kubernetes中，金丝雀发布（Canary Release） 是一种渐进式部署策略，目的是将新版本应用逐步暴露给一小部分用户或流量，通过持续监控确保其稳定性后，再逐步扩大范围直至完全替换旧版本。这种策略的名称来源于"矿井中的金丝雀"------早期矿工用金丝雀来检测有毒气体，如果金丝雀存活，说明环境安全。
金丝雀发布的核心原理
-
小范围验证：
-
先部署新版本（金丝雀版本）到生产环境，但仅允许少量用户或流量访问它（例如5%的请求）。
-
大部分流量仍由旧版本处理，确保用户整体体验不受影响。
-
-
监控与观察：
-
监控新版本的性能指标（如错误率、延迟、CPU/内存使用率等）。
-
如果新版本表现稳定，逐步增加其流量比例；如果发现问题，立即回滚。
-
-
逐步替换：
-
最终将100%流量切换到新版本，完成平滑升级。
-
降低风险：
- 避免一次性全量发布导致全局故障，尤其适用于关键业务场景。
-
快速反馈：
- 通过真实流量验证新版本，比测试环境更可靠。
-
无缝回滚：
- 发现问题时，只需将流量切回旧版本，无需重新部署
-
金丝雀发布的典型实现方式
1. 基于Deployment副本数的金丝雀发布
原理
通过调整新旧版本Pod的副本数比例，利用Kubernetes Service的负载均衡能力，按比例分配流量到新旧版本。
2.部署金丝雀版本：
bash
# deployment-v2.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: myapp-v2
spec:
replicas: 1 # 初始副本数为1（占10%流量）
selector:
matchLabels:
app: myapp
version: v2
template:
metadata:
labels:
app: myapp
version: v2
spec:
containers:
- name: myapp
image: myapp:v23.逐步调整副本比例：
-
若v2运行正常，逐步增加其副本数，同时减少v1的副本数：
kubectl scale deployment myapp-v2 --replicas=3 # 占25%流量（3/(9+3)=25%） kubectl scale deployment myapp-v1 --replicas=9 # 保持旧版本可用 -
最终将v1副本数降为0，完成全量切换
优缺点
-
优点：无需额外工具，完全依赖Kubernetes原生资源。
-
缺点：流量分配不够精确（依赖负载均衡策略），需手动调整副本数。
2. 基于Nginx Ingress控制器的金丝雀发布
原理
通过Ingress的注解（Annotation）按权重分流流量，将特定比例的请求定向到新版本。
bash
nginx.ingress.kubernetes.io/canary: "true"
nginx.ingress.kubernetes.io/canary-weight: "10" # 10%流量到v2调整流量权重：
-
修改
canary-weight注解值，逐步增加新版本流量：kubectl annotate ingress/myapp-canary \ nginx.ingress.kubernetes.io/canary-weight="50" # 50%流量到v2 -
最终删除旧版本Ingress，完成发布。
优缺点
-
优点：流量控制精确，无需Service Mesh。
-
缺点：依赖Nginx Ingress控制器功能。
3. 基于Istio服务网格的金丝雀发布
原理
通过VirtualService和DestinationRule定义流量路由规则，按权重分配请求到不同版本。
逐步调整权重：
-
修改
weight值，逐步将流量切换到v2：weight: 50 # 50%流量到v2 -
最终将v1权重设为0，完成全量切换。
4. 基于Flagger的自动化金丝雀发布
原理
集成Prometheus监控，自动化渐进式发布：根据预设指标（如错误率、延迟）自动调整流量或回滚。
逐步调整权重：
-
修改
weight值，逐步将流量切换到v2：
*weight: 50 # 50%流量到v2- 最终将v1权重设为0，完成全量切换。
优缺点
-
优点：支持基于请求头、Cookie等高级路由规则，流量控制精准。
-
缺点：需引入Istio服务网格，架构复杂度高。
总结
| 方法 | 适用场景 | 核心优势 | 局限性 |
|---|---|---|---|
| Deployment副本数 | 简单场景，无需精确流量控制 | 无需额外工具 | 流量分配不精确，需手动调整 |
| Nginx Ingress | 需要按权重分流的HTTP服务 | 精确流量控制，配置简单 | 依赖Ingress控制器功能 |
| Istio服务网格 | 复杂路由需求（如基于请求头） | 高级流量控制，精准灵活 | 需引入Istio，复杂度高 |
| Flagger自动化工具 | 需要全自动化监控和回滚的关键业务 | 自动化渐进发布，安全可靠 | 依赖Prometheus和Flagger组件 |