K8S-Helm与灰度发布学习笔记
一、Helm 核心知识与实操
1.1 Helm概述
Helm 是 Kubernetes 的包管理工具，类似 Linux 的 YUM、APT，核心作用是简化K8s应用部署与配置管理。通过打包、版本管理、动态生成K8s资源YAML清单，替代手动编写、维护大量Deployment、Service、PVC等资源文件，解决多环境重复部署、配置繁琐、版本难管控的问题。
Helm 本质是让K8s应用配置可配置、可模板化，通过模板+变量动态生成资源清单，再调用kubectl完成集群部署，同时支持应用的升级、回滚、卸载、版本追踪全生命周期管理。
1.1.1 Helm 组件及核心术语
Helm 核心包含三大核心概念：chart、release、repository，配套客户端与服务端组件协同工作：
Helm（客户端）：命令行工具，负责Chart的创建、打包、发布、仓库管理，是用户操作的入口。
Tiller（服务端）：部署在K8s集群中，接收客户端请求，根据Chart生成Release部署资源，负责应用升级、删除、回滚等核心逻辑。
Chart：Helm的软件包（TAR格式），包含一套标准化的K8s资源YAML模板文件，拥有固定目录结构，可自定义开发。
Repository（仓库）：远程Web仓库，存储各类Chart包及清单，支持多仓库管理，常用阿里云、Bitnami等第三方仓库。
Release：通过
helm install部署到K8s集群的Chart实例，是集群中实际运行的应用版本。
1.1.2 Helm工作原理
1、Chart Install 安装过程
Helm 解析本地目录或tgz格式的Chart包结构信息；
将Chart结构与自定义Values变量信息传递给Tiller；
Tiller根据模板和变量生成Release版本；
Tiller推送Release至K8s，完成资源创建与应用部署。
2、Chart Update 升级过程
Helm 解析待更新的Chart资源信息；
向Tiller传递待更新的Release名称、Chart结构和新Values配置；
Tiller生成新Release，更新版本历史记录；
推送新Release至K8s，完成应用滚动升级。
3、Chart Rollback 回滚过程
Helm 向Tiller传递需要回滚的Release名称；
Tiller查询该Release的历史版本记录；
提取上一个稳定版本的Release资源；
推送旧版本Release至K8s，替换当前异常版本，实现快速回滚。
1.2 Helm 部署配置
1.2.1 Helm 客户端安装
以下为Linux环境快速安装Helm v3版本的完整命令：
[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 ~/.bashrc1.2.2 Chart 仓库配置
默认官方仓库访问较慢，可配置国内镜像及主流第三方仓库，提升下载速度：
# 搜索官方Hub仓库Charthelm search hub nginx# 添加第三方仓库（阿里云、Bitnami）helm repoaddaliyun https://kubernetes.oss-cn-hangzhou.aliyuncs.com/charts helm repoaddbitnami https://charts.bitnami.com/bitnami# 查看已添加仓库helm repo list# 从本地仓库搜索指定Charthelm search repo nginx1.3 Helm 常用命令大全
涵盖仓库管理、Chart操作、应用部署、版本管理等核心命令：
| 命令字 | 中文释义 | 作用 |
|---|---|---|
| completion | 自动补全 | 生成特定Shell的自动补全脚本 |
| create | 创建 | 创建全新的自定义Chart模板目录 |
| dependency | 依赖管理 | 管理Chart的依赖包 |
| env | 环境查看 | 查看Helm客户端环境信息 |
| get | 信息获取 | 查看已部署Release的详细信息 |
| history | 历史记录 | 查询应用的部署、升级、回滚历史版本 |
| install | 安装部署 | 通过Chart部署应用到K8s集群 |
| lint | 语法检查 | 检测Chart模板文件的语法及配置问题 |
| list | 列表查看 | 列出集群中所有已部署的Release |
| package | 打包 | 将本地Chart目录打包为tgz格式安装包 |
| pull | 拉取 | 从远程仓库下载Chart包到本地 |
| repo | 仓库管理 | 仓库的添加、删除、更新、列表查询 |
| rollback | 回滚 | 将应用回滚到指定历史版本 |
| search | 搜索 | 模糊搜索仓库中的Chart包 |
| show | 展示 | 查看Chart的详细配置、说明信息 |
| status | 状态查看 | 查看指定Release的运行状态 |
| template | 模板渲染 | 本地预览渲染后的K8s资源YAML |
| uninstall | 卸载 | 卸载集群中已部署的Release应用 |
| upgrade | 升级 | 更新Chart配置，升级集群应用版本 |
| version | 版本查看 | 查看当前Helm客户端版本 |
1.4 Helm Chart 深度详解
1.4.1 Chart 标准目录结构
通过helm create nginx可快速生成标准化Chart目录，各文件分工明确，适配各类K8s应用部署：
[root@k8s-master01 helm]# helm create nginxCreating nginx[root@k8s-master01 nginx]# tree.├── charts ├── Chart.yaml ├── templates │ ├── deployment.yaml │ ├── _helpers.tpl │ ├── hpa.yaml │ ├── ingress.yaml │ ├── NOTES.txt │ ├── serviceaccount.yaml │ ├── service.yaml │ └── tests │ └── test-connection.yaml └── values.yaml3directories,10files目录文件解析：
charts：存放当前Chart依赖的其他子Chart包文件
Chart.yaml：Chart核心描述文件，定义包名、版本、适配K8s版本等元数据（必填）
templates：K8s资源模板目录，存放所有动态渲染的YAML模板
templates/deployment.yaml：应用部署控制器模板
templates/service.yaml：服务暴露模板
templates/ingress.yaml：域名路由访问模板
templates/hpa.yaml：应用弹性扩缩容配置模板
templates/_helpers.tpl：公共变量、方法模板，可被其他文件引用
templates/NOTES.txt：应用部署成功后的提示说明文案
values.yaml：全局变量配置文件，为模板提供自定义参数，是动态配置的核心
1.4.2 Chart.yaml 核心配置字段
该文件是Chart的唯一标识，部分字段为必填项，所有版本遵循语义化版本2.0规范：
apiVersion:v1# Chart API版本，固定v1（必填）name:nginx# Chart包名称（必填）version:1.2.3# Chart包版本号（必填）kubeVersion:>=1.20.0# 适配的K8s最低版本（可选）type:application# Chart类型（可选）description:nginx服务# 项目描述（可选）keywords:# 项目关键字（可选）-nginx-webhome:https://nginx.org# 项目官网（可选）sources:# 源码地址（可选）maintainers:# 维护者信息（可选）engine:gotpl# 模板引擎（默认gotpl，可选）appVersion:1.25.3# 应用自身版本（可选）deprecated:false# 是否废弃该Chart（可选）annotations:{}# 自定义元数据（可选）核心规则：Chart包最终命名格式为名称-版本号.tgz，如nginx-1.2.3.tgz，Helm v3 严格通过名称+版本唯一标识Chart包。
1.5 Helm 实战部署案例（Nginx）
通过远程仓库Chart包，快速部署Nginx应用，支持自定义配置：
# 1. 拉取指定版本Nginx Chart包[root@k8s-master01 nginx-helm]# helm pull bitnami/nginx --version 15.3.5[root@k8s-master01 nginx-helm]# lsnginx-15.3.5.tgz# 2. 解压Chart包并自定义配置[root@k8s-master01 nginx-helm]# tar xf nginx-15.3.5.tgz[root@k8s-master01 nginx-helm]# cd nginx# 可修改values.yaml，自定义服务类型、端口、副本数等配置[root@k8s-master01 nginx]# vim values.yaml532service:533type: ClusterIP539ports:540http:80541https:443# 3. 安装部署Chart[root@k8s-master01 nginx]# helm install nginx-server .NAME: nginx-server LAST DEPLOYED: Sat Feb315:57:332024NAMESPACE: default STATUS: deployed REVISION:1# 4. 查看部署资源[root@k8s-master01 nginx]# kubectl get deployments.apps[root@k8s-master01 nginx]# kubectl get pod[root@k8s-master01 nginx]# kubectl get svc# 5. 测试访问服务[root@k8s-master01 nginx]# curl 10.10.127.16访问成功后会返回Nginx默认欢迎页面，代表基于Helm的应用部署完成。
1.6 Helm 应用升级、回滚与卸载
1.6.1 应用升级
修改values.yaml配置（如调整副本数replicaCount: 3），执行升级命令：
# 执行升级[root@k8s-master01 nginx]# helm upgrade nginx-server .# 查看升级后Pod状态[root@k8s-master01 nginx]# kubectl get pod# 查看版本变更历史[root@k8s-master01 nginx]# helm history nginx-server1.6.2 应用回滚
若升级后应用异常，可基于历史版本快速回滚：
# 回滚到1号历史版本[root@k8s-master01 nginx]# helm rollback nginx-server 1# 验证回滚结果[root@k8s-master01 nginx]# kubectl get pod1.6.3 应用卸载
# 卸载指定Release应用[root@k8s-master01 nginx]# helm uninstall nginx-server二、K8S 灰度发布策略（蓝绿&金丝雀）
2.1 蓝绿发布
蓝绿发布（Blue-Green Deployment）是K8s零停机部署策略，核心是同时维护两套完全独立的生产环境：蓝环境（旧版本，在线服务）、绿环境（新版本，待命验证）。新版本验证无误后，一次性全量切换流量，异常则秒级回滚旧版本。核心特点：零停机、回滚简单、版本无残留风险。
2.1.1 核心原理
双环境共存：蓝环境承载正式用户流量，绿环境部署新版本，完成初始化与自测；
一次性流量切换：验证绿环境稳定后，将所有流量从蓝环境切换至绿环境；
极速回滚：绿环境出现故障，立即切回蓝环境流量，业务无感知恢复。
2.1.2 常用实现方式
方式一：Service标签选择器切换（原生无依赖）
利用K8s Service的标签选择器特性，通过修改标签匹配规则实现流量切换，无需任何额外组件，简单高效。
步骤1：部署蓝环境（旧版本v1）
# deployment-blue.yamlapiVersion:apps/v1kind:Deploymentmetadata:name:myapp-bluespec:replicas:3selector:matchLabels:app:myappversion:bluetemplate:metadata:labels:app:myappversion:bluespec:containers:-name:myappimage:janakiramm/myapp:v1imagePullPolicy:IfNotPresent---# service.yamlapiVersion:v1kind:Servicemetadata:name:myapp-servicespec:type:NodePortselector:app:myappversion:blue# 初始流量指向蓝环境ports:-protocol:TCPport:80targetPort:8080步骤2：部署绿环境（新版本v2）
# deployment-green.yamlapiVersion:apps/v1kind:Deploymentmetadata:name:myapp-greenspec:replicas:3selector:matchLabels:app:myappversion:greentemplate:metadata:labels:app:myappversion:greenspec:containers:-name:myappimage:janakiramm/myapp:v2imagePullPolicy:IfNotPresent步骤3：切换流量至绿环境
kubectl patchservicemyapp-service-p'{"spec":{"selector":{"version":"green"}}}'步骤4：验证与收尾：绿环境稳定运行后，删除蓝环境Deployment；若异常，重新将Service标签切回blue即可回滚。
优缺点：优点是原生支持、零组件依赖、操作简单；缺点是需手动切换，无小流量预验证过程。
方式二：Ingress控制器流量切换
适用于HTTP/HTTPS业务，通过更新Ingress路由规则，将域名流量从蓝环境Service切换至绿环境Service，支持复杂路由配置。
步骤1：分别部署蓝、绿环境的Deployment和独立Service（myapp-blue-svc、myapp-green-svc）；
步骤2：初始Ingress规则指向蓝环境：
# ingress-blue.yamlapiVersion:networking.k8s.io/v1kind:Ingressmetadata:name:myapp-ingressspec:rules:-http:paths:-path:/pathType:Prefixbackend:service:name:myapp-blue-svcport:number:80步骤3：验证绿环境正常后，更新Ingress指向绿环境：
# ingress-green.yamlapiVersion:networking.k8s.io/v1kind:Ingressmetadata:name:myapp-ingressspec:rules:-http:paths:-path:/pathType:Prefixbackend:service:name:myapp-green-svcport:number:80步骤4：应用配置完成流量切换：kubectl apply -f ingress-green.yaml
优缺点：优点是适配web业务、支持复杂路由；缺点是依赖Ingress控制器更新，切换速度受组件影响。
2.1.3 蓝绿发布方式对比
| 方法 | 适用场景 | 核心优势 | 局限性 |
|---|---|---|---|
| Service标签切换 | 简单业务场景，快速发布切换 | 无需额外组件，原生支持、操作极简 | 手动操作，无小流量预验证 |
| Ingress控制器切换 | HTTP/HTTPS web服务，需精细路由 | 路由配置灵活，适配域名访问场景 | 依赖Ingress控制器，切换有轻微延迟 |
2.1.4 蓝绿发布最佳实践
确保新旧版本数据库兼容，避免流量切换后数据异常；
有状态业务需做好会话保持，防止用户登录态丢失；
切换前后监控错误率、延迟、资源使用率等核心指标；
流量切换前完成绿环境自动化冒烟测试、API测试。
2.2 金丝雀发布
金丝雀发布（Canary Release）是渐进式灰度发布策略，源于“矿井金丝雀检测毒气”原理。核心是将新版本（金丝雀版本）小范围上线，仅分配少量用户/流量验证稳定性，无异常后逐步扩容流量，最终完全替换旧版本，最大限度降低全量发布风险。
2.2.1 核心原理
小范围灰度：新旧版本集群共存，仅少量流量访问新版本，核心业务由旧版本承载；
监控验证：持续监控新版本错误率、延迟、资源占用等指标，判断稳定性；
渐进迭代：稳定则逐步提升新版本流量占比，异常则立即切断流量回滚，最终完成全量升级。
2.2.2 K8s使用金丝雀发布的价值
风险极低：避免全量发布导致的集群故障，适配核心生产业务；
真实场景验证：基于生产真实流量测试，比测试环境更贴合业务场景；
回滚无成本：异常时仅需调整流量比例，无需重新部署应用。
2.2.3 常用实现方式
方式一：Deployment副本数灰度（原生无依赖）
通过调整新旧版本Pod副本数量比例，利用K8s Service默认负载均衡机制实现流量灰度，无需额外组件。
步骤1：部署旧版本v1（主力服务）
apiVersion:apps/v1kind:Deploymentmetadata:name:myapp-v1spec:replicas:9selector:matchLabels:app:myappversion:v1template:metadata:labels:app:myappversion:v1spec:containers:-name:myappimage:janakiramm/myapp:v1---apiVersion:v1kind:Servicemetadata:name:myapp-service1spec:selector:app:myappports:-protocol:TCPport:80targetPort:80步骤2：部署金丝雀版本v2（少量副本）
apiVersion:apps/v1kind:Deploymentmetadata:name:myapp-v2spec:replicas:1# 初始10%流量灰度selector:matchLabels:app:myappversion:v2template:metadata:labels:app:myappversion:v2spec:containers:-name:myappimage:janakiramm/myapp:v2步骤3：渐进扩容：v2稳定后，逐步增加v2副本、减少v1副本，直至完全替换：
kubectl scale deployment myapp-v2--replicas=3kubectl scale deployment myapp-v1--replicas=6优缺点：零组件依赖、操作简单；缺点是流量分配基于负载均衡策略，精度较低。
方式二：Nginx Ingress权重灰度
通过Ingress注解精准配置流量权重，按百分比分配请求到新旧版本，流量控制精度高，适配web业务。
步骤1：分别部署v1、v2版本Deployment及独立Service；
步骤2：配置主Ingress和金丝雀Ingress，设置灰度权重：
# 主Ingress（承载90%流量）apiVersion:networking.k8s.io/v1kind:Ingressmetadata:name:nginx-ingressspec:ingressClassName:nginxrules:-host:all.jx.comhttp:paths:-path:/pathType:Prefixbackend:service:name:myapp-v1port:number:80---# 金丝雀Ingress（承载10%流量）apiVersion:networking.k8s.io/v1kind:Ingressmetadata:name:myapp-canaryannotations:nginx.ingress.kubernetes.io/canary:"true"nginx.ingress.kubernetes.io/canary-weight:"10"spec:ingressClassName:nginxrules:-host:all.jx.comhttp:paths:-path:/pathType:Prefixbackend:service:name:myapp-v2port:number:80步骤3：动态调整灰度权重，逐步放量：
kubectl annotate ingress/myapp-canary nginx.ingress.kubernetes.io/canary-weight="50"优缺点：流量精准可控、配置简单；缺点是仅支持HTTP业务，依赖Nginx Ingress组件。
方式三：Istio服务网格灰度
通过Istio的DestinationRule和VirtualService实现精准流量权重分配，支持基于请求头、Cookie的高级灰度策略，适配复杂微服务场景。
步骤1：部署v1、v2版本应用，统一Service入口；
步骤2：配置DestinationRule定义版本子集：
apiVersion:networking.istio.io/v1alpha3kind:DestinationRulemetadata:name:myappspec:host:myappsubsets:-name:v1labels:version:v1-name:v2labels:version:v2步骤3：配置流量权重分配，实现90%旧版本、10%新版本灰度：
apiVersion:networking.istio.io/v1alpha3kind:VirtualServicemetadata:name:myappspec:hosts:-myapphttp:-route:-destination:host:myappsubset:v1weight:90-destination:host:myappsubset:v2weight:10步骤4：逐步调整weight权重，直至100%流量切换到v2版本。
优缺点：流量控制精准、支持高级灰度策略；缺点是需部署Istio服务网格，架构复杂度较高。
2.2.4 金丝雀发布方式对比
| 方法 | 适用场景 | 核心优势 | 局限性 |
|---|---|---|---|
| Deployment副本数灰度 | 简单场景，无需精准流量控制 | 原生支持、零组件依赖、运维简单 | 流量分配不精准，需手动调整副本 |
| Nginx Ingress灰度 | HTTP web服务，需固定权重分流 | 流量精准、配置轻量化 | 仅支持HTTP协议，依赖Ingress组件 |
| Istio服务网格灰度 | 微服务复杂场景，需精细化灰度 | 支持权重、请求头、Cookie等多维灰度 | 架构复杂，需维护Istio组件 |
2.2.5 金丝雀发布最佳实践
核心指标监控：重点监控请求成功率、响应延迟、CPU/内存使用率、业务自定义指标；
配置自动回滚阈值：如新版本错误率超1%，立即切断灰度流量；
结合A/B测试：可根据用户地域、设备、用户等级定向灰度；
灰度周期循序渐进：从小权重（5%/10%）开始，观察无异常后逐步放量。
2.3 蓝绿发布 vs 金丝雀发布 核心区别
| 特性 | 蓝绿发布 | 金丝雀发布 |
|---|---|---|
| 环境部署 | 两套完整独立环境（蓝/绿） | 新旧版本共存同一集群环境 |
| 流量切换方式 | 一次性全量切换 | 逐步、渐进式迁移流量 |
| 资源消耗 | 高，需双倍资源部署两套环境 | 低，仅需少量新版本副本 |
| 回滚速度 | 极快，秒级流量切换 | 较快，调整流量权重即可 |
| 适用场景 | 版本改动大、需完整验证的关键业务 | 迭代频繁、需小范围风险验证的业务 |
2.4 灰度发布整体总结
蓝绿发布侧重快速切换、极速回滚、版本彻底替换，适合重大版本更新；金丝雀发布侧重风险可控、渐进迭代、真实流量验证，适合日常迭代更新。实际生产中，可根据业务重要程度、版本改动幅度，灵活选择适配的发布策略，核心目标是降低上线风险、保障业务连续性。
（注：文档部分内容可能由 AI 生成）
