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

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 ~/.bashrc

1.2.2 Chart 仓库配置

默认官方仓库访问较慢，可配置国内镜像及主流第三方仓库，提升下载速度：

# 搜索官方Hub仓库Chart
helm search hub nginx

# 添加第三方仓库（阿里云、Bitnami）
helm repo add aliyun  https://kubernetes.oss-cn-hangzhou.aliyuncs.com/charts 
helm repo add bitnami https://charts.bitnami.com/bitnami

# 查看已添加仓库
helm repo list

# 从本地仓库搜索指定Chart
helm search repo nginx

1.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 nginx
Creating 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.yaml
3 directories, 10 files

目录文件解析：

• 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
  - web
home: 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]# ls
nginx-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.yaml 
532 service:
533   type: ClusterIP
539   ports:
540     http: 80
541     https: 443

# 3. 安装部署Chart
[root@k8s-master01 nginx]# helm install nginx-server .
NAME: nginx-server
LAST DEPLOYED: Sat Feb  3 15:57:33 2024
NAMESPACE: 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-server 

1.6.2 应用回滚

若升级后应用异常，可基于历史版本快速回滚：

# 回滚到1号历史版本
[root@k8s-master01 nginx]# helm rollback nginx-server 1

# 验证回滚结果
[root@k8s-master01 nginx]# kubectl get pod

1.6.3 应用卸载

# 卸载指定Release应用
[root@k8s-master01 nginx]# helm uninstall nginx-server

二、K8S 灰度发布策略（蓝绿&金丝雀）

2.1 蓝绿发布

蓝绿发布（Blue-Green Deployment） 是K8s零停机部署策略，核心是同时维护两套完全独立的生产环境：蓝环境（旧版本，在线服务） 、绿环境（新版本，待命验证）。新版本验证无误后，一次性全量切换流量，异常则秒级回滚旧版本。核心特点：零停机、回滚简单、版本无残留风险。

2.1.1 核心原理

1. 双环境共存：蓝环境承载正式用户流量，绿环境部署新版本，完成初始化与自测；

2. 一次性流量切换：验证绿环境稳定后，将所有流量从蓝环境切换至绿环境；

3. 极速回滚：绿环境出现故障，立即切回蓝环境流量，业务无感知恢复。

2.1.2 常用实现方式

方式一：Service标签选择器切换（原生无依赖）

利用K8s Service的标签选择器特性，通过修改标签匹配规则实现流量切换，无需任何额外组件，简单高效。

步骤1：部署蓝环境（旧版本v1）

# deployment-blue.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-blue
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
      version: blue
  template:
    metadata:
      labels:
        app: myapp
        version: blue
    spec:
      containers:
      - name: myapp
        image: janakiramm/myapp:v1
        imagePullPolicy: IfNotPresent
---
# service.yaml
apiVersion: v1
kind: Service
metadata:
  name: myapp-service
spec:
  type: NodePort
  selector:
    app: myapp
    version: blue  # 初始流量指向蓝环境
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080

步骤2：部署绿环境（新版本v2）

# deployment-green.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-green
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
      version: green
  template:
    metadata:
      labels:
        app: myapp
        version: green
    spec:
      containers:
      - name: myapp
        image: janakiramm/myapp:v2
        imagePullPolicy: IfNotPresent

步骤3：切换流量至绿环境

kubectl patch service myapp-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.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: myapp-ingress
spec:
  rules:
  - http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: myapp-blue-svc
            port:
              number: 80

步骤3：验证绿环境正常后，更新Ingress指向绿环境：

# ingress-green.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: myapp-ingress
spec:
  rules:
  - http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: myapp-green-svc
            port:
              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 核心原理

1. 小范围灰度：新旧版本集群共存，仅少量流量访问新版本，核心业务由旧版本承载；

2. 监控验证：持续监控新版本错误率、延迟、资源占用等指标，判断稳定性；

3. 渐进迭代：稳定则逐步提升新版本流量占比，异常则立即切断流量回滚，最终完成全量升级。

2.2.2 K8s使用金丝雀发布的价值

• 风险极低：避免全量发布导致的集群故障，适配核心生产业务；

• 真实场景验证：基于生产真实流量测试，比测试环境更贴合业务场景；

• 回滚无成本：异常时仅需调整流量比例，无需重新部署应用。

2.2.3 常用实现方式

方式一：Deployment副本数灰度（原生无依赖）

通过调整新旧版本Pod副本数量比例，利用K8s Service默认负载均衡机制实现流量灰度，无需额外组件。

步骤1：部署旧版本v1（主力服务）

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-v1
spec:
  replicas: 9
  selector:
    matchLabels:
      app: myapp
      version: v1
  template:
    metadata:
      labels:
        app: myapp
        version: v1
    spec:
      containers:
      - name: myapp
        image: janakiramm/myapp:v1
---
apiVersion: v1
kind: Service
metadata:
  name: myapp-service1
spec:
  selector:
    app: myapp
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80

步骤2：部署金丝雀版本v2（少量副本）

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-v2
spec:
  replicas: 1  # 初始10%流量灰度
  selector:
    matchLabels:
      app: myapp
      version: v2
  template:
    metadata:
      labels:
        app: myapp
        version: v2
    spec:
      containers:
      - name: myapp
        image: janakiramm/myapp:v2

步骤3：渐进扩容：v2稳定后，逐步增加v2副本、减少v1副本，直至完全替换：

kubectl scale deployment myapp-v2 --replicas=3
kubectl scale deployment myapp-v1 --replicas=6

优缺点：零组件依赖、操作简单；缺点是流量分配基于负载均衡策略，精度较低。

方式二：Nginx Ingress权重灰度

通过Ingress注解精准配置流量权重，按百分比分配请求到新旧版本，流量控制精度高，适配web业务。

步骤1：分别部署v1、v2版本Deployment及独立Service；

步骤2：配置主Ingress和金丝雀Ingress，设置灰度权重：

# 主Ingress（承载90%流量）
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: nginx-ingress
spec:
  ingressClassName: nginx
  rules:
  - host: all.jx.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: myapp-v1
            port:
              number: 80
---
# 金丝雀Ingress（承载10%流量）
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: myapp-canary
  annotations:
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-weight: "10"
spec:
  ingressClassName: nginx
  rules:
  - host: all.jx.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: myapp-v2
            port:
              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/v1alpha3
kind: DestinationRule
metadata:
  name: myapp
spec:
  host: myapp
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2

步骤3：配置流量权重分配，实现90%旧版本、10%新版本灰度：

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: myapp
spec:
  hosts:
  - myapp
  http:
  - route:
    - destination:
        host: myapp
        subset: v1
      weight: 90
    - destination:
        host: myapp
        subset: v2
      weight: 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 生成）