K8S-Helm与灰度发布学习笔记

张

张建站

2026/5/15 1:13:07

10分钟阅读

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部署资源负责应用升级、删除、回滚等核心逻辑。ChartHelm的软件包TAR格式包含一套标准化的K8s资源YAML模板文件拥有固定目录结构可自定义开发。Repository仓库远程Web仓库存储各类Chart包及清单支持多仓库管理常用阿里云、Bitnami等第三方仓库。Release通过helm install部署到K8s集群的Chart实例是集群中实际运行的应用版本。1.1.2 Helm工作原理1、Chart Install 安装过程Helm 解析本地目录或tgz格式的Chart包结构信息将Chart结构与自定义Values变量信息传递给TillerTiller根据模板和变量生成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版本的完整命令[rootk8s-master01 ~]# mkdir helm[rootk8s-master01 helm]# wget https://get.helm.sh/helm-v3.14.0-linux-amd64.tar.gz[rootk8s-master01 helm]# tar -zxvf helm-v3.14.0-linux-amd64.tar.gz[rootk8s-master01 helm]# cd linux-amd64/[rootk8s-master01 linux-amd64]# cp helm /usr/local/bin/[rootk8s-master01 linux-amd64]# echo source (helm completion bash) ~/.bashrc[rootk8s-master01 linux-amd64]# source ~/.bashrc1.2.2 Chart 仓库配置默认官方仓库访问较慢可配置国内镜像及主流第三方仓库提升下载速度# 搜索官方Hub仓库Charthelm search hub nginx# 添加第三方仓库阿里云、Bitnamihelm 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列表查看列出集群中所有已部署的Releasepackage打包将本地Chart目录打包为tgz格式安装包pull拉取从远程仓库下载Chart包到本地repo仓库管理仓库的添加、删除、更新、列表查询rollback回滚将应用回滚到指定历史版本search搜索模糊搜索仓库中的Chart包show展示查看Chart的详细配置、说明信息status状态查看查看指定Release的运行状态template模板渲染本地预览渲染后的K8s资源YAMLuninstall卸载卸载集群中已部署的Release应用upgrade升级更新Chart配置升级集群应用版本version版本查看查看当前Helm客户端版本1.4 Helm Chart 深度详解1.4.1 Chart 标准目录结构通过helm create nginx可快速生成标准化Chart目录各文件分工明确适配各类K8s应用部署[rootk8s-master01 helm]# helm create nginxCreating nginx[rootk8s-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.yamlChart核心描述文件定义包名、版本、适配K8s版本等元数据必填templatesK8s资源模板目录存放所有动态渲染的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.tgzHelm v3 严格通过名称版本唯一标识Chart包。1.5 Helm 实战部署案例Nginx通过远程仓库Chart包快速部署Nginx应用支持自定义配置# 1. 拉取指定版本Nginx Chart包[rootk8s-master01 nginx-helm]# helm pull bitnami/nginx --version 15.3.5[rootk8s-master01 nginx-helm]# lsnginx-15.3.5.tgz# 2. 解压Chart包并自定义配置[rootk8s-master01 nginx-helm]# tar xf nginx-15.3.5.tgz[rootk8s-master01 nginx-helm]# cd nginx# 可修改values.yaml自定义服务类型、端口、副本数等配置[rootk8s-master01 nginx]# vim values.yaml532service:533type: ClusterIP539ports:540http:80541https:443# 3. 安装部署Chart[rootk8s-master01 nginx]# helm install nginx-server .NAME: nginx-server LAST DEPLOYED: Sat Feb315:57:332024NAMESPACE: default STATUS: deployed REVISION:1# 4. 查看部署资源[rootk8s-master01 nginx]# kubectl get deployments.apps[rootk8s-master01 nginx]# kubectl get pod[rootk8s-master01 nginx]# kubectl get svc# 5. 测试访问服务[rootk8s-master01 nginx]# curl 10.10.127.16访问成功后会返回Nginx默认欢迎页面代表基于Helm的应用部署完成。1.6 Helm 应用升级、回滚与卸载1.6.1 应用升级修改values.yaml配置如调整副本数replicaCount: 3执行升级命令# 执行升级[rootk8s-master01 nginx]# helm upgrade nginx-server .# 查看升级后Pod状态[rootk8s-master01 nginx]# kubectl get pod# 查看版本变更历史[rootk8s-master01 nginx]# helm history nginx-server1.6.2 应用回滚若升级后应用异常可基于历史版本快速回滚# 回滚到1号历史版本[rootk8s-master01 nginx]# helm rollback nginx-server 1# 验证回滚结果[rootk8s-master01 nginx]# kubectl get pod1.6.3 应用卸载# 卸载指定Release应用[rootk8s-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和独立Servicemyapp-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--replicas3kubectl scale deployment myapp-v1--replicas6优缺点零组件依赖、操作简单缺点是流量分配基于负载均衡策略精度较低。方式二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:truenginx.ingress.kubernetes.io/canary-weight:10spec: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-weight50优缺点流量精准可控、配置简单缺点是仅支持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 生成