首页 > 其他分享 >K8s 灰度发布实战:通过 Ingress 注解轻松实现流量分割与渐进式发布

K8s 灰度发布实战:通过 Ingress 注解轻松实现流量分割与渐进式发布

时间:2025-01-21 11:33:50浏览次数:1  
标签:Ingress app ingress canary v1 灰度 K8s my

在现代微服务架构中,应用的更新和发布是一个高频且关键的操作。如何在不影响用户体验的前提下,安全、平稳地将新版本应用推送到生产环境,是每个开发者和运维团队必须面对的挑战。灰度发布(Gray Release)作为一种渐进式发布策略,能够有效降低发布风险,而 Kubernetes 的 Ingress 注解功能为我们提供了一种简单而强大的实现方式。

本文将带你深入浅出地了解如何通过 Ingress 注解 在 Kubernetes 中实现灰度发布,并逐步掌握流量分割、权重控制等核心技巧。无论你是 Kubernetes 新手还是资深用户,都能从本文中获得实用的知识和操作指南。


什么是灰度发布?

灰度发布,也称为金丝雀发布(Canary Release),是一种渐进式的应用发布策略。它的核心思想是:将新版本应用逐步推送给一小部分用户,观察其运行状态,确认无误后再逐步扩大范围,最终完成全量发布

相比于全量发布,灰度发布具有以下优势:

  1. 降低风险:通过小范围验证,避免因新版本问题导致全局故障。
  2. 快速回滚:如果新版本出现问题,可以快速切换回旧版本。
  3. 用户体验优化:逐步发布可以减少对用户的影响。

Kubernetes 中的灰度发布实现方式

在 Kubernetes 中,灰度发布可以通过多种方式实现,例如:

  • Deployment + Service:手动控制流量切换。
  • Istio:通过服务网格实现高级流量管理。
  • Ingress 注解:通过 Nginx Ingress Controller 的注解功能实现流量分割。

本文将重点介绍 Ingress 注解 的实现方式,因为它简单易用,且无需引入额外的组件。


通过 Ingress 注解实现灰度发布

Nginx Ingress Controller 提供了丰富的注解(Annotations),可以轻松实现灰度发布。以下是具体步骤:

1. 部署新旧版本应用

首先,我们需要部署两个版本的应用程序:

  • 旧版本(v1):当前正在运行的生产版本。
  • 新版本(v2):待发布的新版本。

1.1 创建 v1 版本 Deployment 和 Service

# v1 版本 Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-v1
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: my-app
        version: v1
    spec:
      containers:
      - name: my-app
        image: my-app:v1
        ports:
        - containerPort: 80

# v1 版本 Service
apiVersion: v1
kind: Service
metadata:
  name: my-app-v1
spec:
  selector:
    app: my-app
    version: v1
  ports:
  - port: 80
    targetPort: 80

1.2 创建 v2 版本 Deployment 和 Service

# v2 版本 Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-v2
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: my-app
        version: v2
    spec:
      containers:
      - name: my-app
        image: my-app:v2
        ports:
        - containerPort: 80

# v2 版本 Service
apiVersion: v1
kind: Service
metadata:
  name: my-app-v2
spec:
  selector:
    app: my-app
    version: v2
  ports:
  - port: 80
    targetPort: 80

2. 配置 Ingress 实现灰度发布

通过 Nginx Ingress Controller 的 canary 注解,我们可以轻松实现流量分割。

2.1 创建 Ingress 资源

以下是一个示例配置:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-app-ingress
  annotations:
    nginx.ingress.kubernetes.io/canary: "true"  # 启用灰度发布
    nginx.ingress.kubernetes.io/canary-weight: "10"  # 10% 流量到新版本
spec:
  rules:
  - host: my-app.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: my-app-v2  # 新版本服务
            port:
              number: 80
  - host: my-app.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: my-app-v1  # 旧版本服务
            port:
              number: 80

2.2 关键注解说明

  • nginx.ingress.kubernetes.io/canary: "true":启用灰度发布功能。
  • nginx.ingress.kubernetes.io/canary-weight: "10":将 10% 的流量分配到新版本(v2),剩余 90% 的流量继续使用旧版本(v1)。

3. 逐步调整流量权重

在灰度发布过程中,可以逐步增加新版本的流量比例。例如:

  • 初始阶段:10% 流量到 v2。
  • 验证通过后:将权重调整为 50%。
  • 最终阶段:将权重调整为 100%,完成全量发布。

只需修改 canary-weight 注解的值即可:

nginx.ingress.kubernetes.io/canary-weight: "50"  # 50% 流量到新版本

4. 监控与回滚

在灰度发布过程中,务必监控新版本的运行状态,包括:

  • 应用日志:检查是否有错误或异常。
  • 性能指标:如响应时间、错误率等。
  • 用户反馈:收集用户的使用体验。

如果发现问题,可以通过调整 canary-weight 注解将流量切回旧版本:

nginx.ingress.kubernetes.io/canary-weight: "0"  # 所有流量切回旧版本

灰度发布的进阶用法

除了基于权重的流量分割,Nginx Ingress Controller 还支持以下灰度发布策略:

1. 基于请求头的流量分割

通过 nginx.ingress.kubernetes.io/canary-by-header 注解,将特定请求头的流量路由到新版本。

示例配置

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-app-ingress
  annotations:
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-by-header: "X-Canary"
    nginx.ingress.kubernetes.io/canary-by-header-value: "true"
spec:
  rules:
  - host: my-app.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: my-app-v2
            port:
              number: 80
  - host: my-app.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: my-app-v1
            port:
              number: 80

说明

  • 当请求头中包含 X-Canary: true 时,流量会被路由到新版本(v2)。
  • 其他请求继续使用旧版本(v1)。

通过 nginx.ingress.kubernetes.io/canary-by-cookie 注解,将特定 Cookie 的流量路由到新版本。

示例配置

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-app-ingress
  annotations:
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-by-cookie: "canary"
spec:
  rules:
  - host: my-app.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: my-app-v2
            port:
              number: 80
  - host: my-app.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: my-app-v1
            port:
              number: 80

说明

  • 当请求中包含 canary=true 的 Cookie 时,流量会被路由到新版本(v2)。
  • 其他请求继续使用旧版本(v1)。

3. 组合使用

可以同时使用权重、请求头和 Cookie 实现更复杂的灰度发布策略。

示例配置

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-app-ingress
  annotations:
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-weight: "10"
    nginx.ingress.kubernetes.io/canary-by-header: "X-Canary"
    nginx.ingress.kubernetes.io/canary-by-header-value: "true"
    nginx.ingress.kubernetes.io/canary-by-cookie: "canary"
spec:
  rules:
  - host: my-app.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: my-app-v2
            port:
              number: 80
  - host: my-app.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: my-app-v1
            port:
              number: 80

说明

  • 10% 的流量会被分配到新版本(v2)。
  • 如果请求头中包含 X-Canary: true 或 Cookie 中包含 canary=true,流量也会被路由到新版本。

总结

通过 Kubernetes 的 Ingress 注解,我们可以轻松实现灰度发布,逐步将新版本应用推送给用户,降低发布风险。无论是基于权重的流量分割,还是基于请求头或 Cookie 的精细化控制,Nginx Ingress Controller 都提供了强大的支持。

灰度发布不仅是技术上的优化,更是对用户体验的尊重。希望本文能帮助你掌握这一重要技能,让你的发布过程更加平稳、可靠!


立即尝试:在你的 Kubernetes 集群中部署一个灰度发布示例,感受渐进式发布的魅力吧!如果你有任何问题或想法,欢迎在评论区留言讨论!

标签:Ingress,app,ingress,canary,v1,灰度,K8s,my
From: https://www.cnblogs.com/ydswin/p/18683278

相关文章

  • 折腾笔记[8]-使用rust去除灰度图的畸变
    摘要使用rust的image库,实现去畸变算法从而去除灰度图的畸变.UsetheimagelibraryofRust;manuallyimplementthedistortionremovalmethodtoremovethedistortionofthegrayscaleimage.关键词rust;image;关键信息[package]name="exp65-rust-ziglang-slambo......
  • 【K8S系列】K8s 领域深度剖析:年度技术、工具与实战总结 (思维导图-java架构)
    创建一个关于Kubernetes(简称K8s)领域的深度剖析年度总结的思维导图,特别是针对Java架构师的需求,可以帮助梳理和理解过去一年中重要的技术进展、工具以及实战经验。下面是一个基于文本的思维导图结构建议,你可以根据这个结构使用任何思维导图软件来创建你的图形化版本。Kuberne......
  • 云原生周刊:K8s 生产环境架构设计及成本分析
    开源项目推荐KubeZoneNetKubeZoneNet旨在帮助监控和优化Kubernetes集群中的跨可用区(Cross-Zone)网络流量。这个项目提供了一种简便的方式来跟踪和分析Kubernetes集群中跨不同可用区的通信,帮助用户优化集群的网络架构、提高资源利用效率并减少网络延迟。通过实时监控和数据分......
  • K8s日志采集终极指南:Logtail + CRD实现多环境精准采集
    需求背景需求:k8s的应用日志解决方案,不同项目组的日志要采集到不同的logstore,并且只采集指定环境的日志(dev/test/prd)方案:logtail使用daemonset方式通过crd来自定义日志采集1.部署helmv3helm:https://github.com/helm/helm/releaseswgethttps://get.helm.sh/helm......
  • K8s中Java应用OOM崩溃?一招搞定Dump文件抓取与告警!
    背景:公司新项目在进行容器化工作,有开发提出他们的java应用存在OOM的情况,通过配置参数-XX:+HeapDumpOnOutOfMemoryError-XX:HeapDumpPath=/dumps/oom可以将jvm信息dump下来,但是在K8s中出现OOM会直接重启容器,无法查看/获取dump文件。并且dump的文件通常比较大(开发估计2G左......
  • ingress-nginx代理tcp使其能外部访问mysql
    一、helm部署mysql主从复制helmrepoaddbitnamihttps://charts.bitnami.com/bitnamihelmrepoupdate helmpullbitnami/mysql 解压后编辑values.yaml文件,修改如下(storageclass已设置默认类)117##@paramarchitectureMySQLarchitecture(`standalone`or`re......
  • k8s资源限制
    k8s资源限制管理在k8s中,资源限制是保证集群稳定性和高效运行的关键。资源限制不仅帮助管理节点资源的分配,还能有效地控制不同容器、Pod和命名空间的资源使用。本文将介绍三种常用的资源限制方式:容器资源限制(Resources)、资源配额(ResourceQuota)和限制范围(LimitRange)。1.容器......
  • K8S实现发布和回滚三种方案对比
    蓝绿部署、灰度发布、金丝雀发布和A/B测试的K8S实现方案1.蓝绿部署特点:蓝绿部署的核心思想是同时部署两个版本的应用(蓝环境和绿环境),但在某一时刻只有一个环境对外提供服务,另一环境处于待命状态,准备随时切换。缺点:一套环境空跑,资源浪费。K8S实现蓝绿发布方案:基于控制......
  • k8s的名称空间
    1.什么是名称空间?通过工作中的这段时间,复习一下k8s的名称空间,在K8s中,名称空间是用于隔离集群资源的机制。Kubernetes集群中的一些资源支持名称空间,而一些资源不支持名称空间。那些支持名称空间的资源被称为局部资源,而不支持名称空间的资源则是全局资源。如何判定资源是否支......
  • k8s的五大组件
    Kubernetes核心组件及其功能Kubernetes(K8s)是一个强大的容器编排平台,能够自动化容器化应用程序的部署、扩展和管理。其架构由多个组件协作完成,以下是Kubernetes的五大核心组件及其功能。1.APIServer(kube-apiserver)作用:Kubernetes的所有请求都会通过APIServer,它是集......