ASP.NET Core on K8S深入学习(14)Ingress灰度发布

简介: 本文介绍了Nginx Ingress提供的三种灰度发布(canary)的方式,然后介绍了如何使用Nginx Ingress并进行配置实现ASP.NET Core WebAPI应用服务的灰度发布实践,最后对比三种方式的优先级及限制,希望对你有所帮助。

本篇已加入《.NET Core on K8S学习实践系列文章索引》,可以点击查看更多容器化技术相关系列文章。

之前一篇介绍了Ingress的基本概念和Nginx Ingress的基本配置和使用,本篇继续Ingress的使用,来看看如何使用Ingress实现灰度发布(金丝雀发布)。

一、准备工作

1.1 WebAPI项目准备

首先,我们还是准备两个版本的ASP.NET Core WebAPI项目,具体项目代码参见这里

他们之间的差别在于一个接口的返回JSON数据,比如V1.0版本中返回的是Version: 1.0,而V1.1版本中返回的是Version:1.1。

    [Route("api/[controller]")]
    [ApiController]
    public class HomeController : ControllerBase
    {
        // GET api/home
        [HttpGet]
        public ActionResult<IEnumerable<string>> Get()
        {
            return new string[] {
                "Hello, welcome to EDC's demo. Version: 1.0"
            };
        }
    }

运行结果为:

(2)将此项目各个版本根据Dockerfile打成镜像,分别是xilife/canary-api-demo:1.0,1.1。

(3)将本地镜像push到远程镜像仓库,这里我传送到了docker hub的一个公共仓库里边:

docker push xilife/canary-api-demo:1.0
docker push xilife/canary-api-demo:1.1

1.2 WebAPI项目部署

其次,我们将这两个WebAPI项目部署到K8s集群中,还是通过熟悉的yaml文件来将其部署为Service:

(1)V1.0版本(假设为线上版本)

apiVersion: apps/v1
kind: Deployment
metadata:
  name: canary-api-demo
  namespace: xdp-poc
  labels:
    name: canary-api-demo
spec:
  replicas: 2
  selector:
    matchLabels:
      name: canary-api-demo
  template:
    metadata:
      labels:
        name: canary-api-demo
    spec:
      containers:
      - name: canary-api-demo
        image: xilife/canary-api-demo:1.0
        ports:
        - containerPort: 80
        imagePullPolicy: IfNotPresent

---

kind: Service
apiVersion: v1
metadata:
  name: canary-api-svc
  namespace: xdp-poc
spec:
  type: NodePort
  ports:
    - port: 80
      targetPort: 80
  selector:
    name: canary-api-demo

(2)V1.1版本(假设为灰度版本)

apiVersion: apps/v1
kind: Deployment
metadata:
  name: canary-api-demo-gray
  namespace: xdp-poc
  labels:
    name: canary-api-demo-gray
spec:
  replicas: 2
  selector:
    matchLabels:
      name: canary-api-demo-gray
  template:
    metadata:
      labels:
        name: canary-api-demo-gray
    spec:
      containers:
      - name: canary-api-demo-gray
        image: xilife/canary-api-demo:1.1
        ports:
        - containerPort: 80
        imagePullPolicy: IfNotPresent

---

kind: Service
apiVersion: v1
metadata:
  name: canary-api-svc-gray
  namespace: xdp-poc
spec:
  type: NodePort
  ports:
    - port: 80
      targetPort: 80
  selector:
    name: canary-api-demo-gray

将这两个应用部署至K8s集群:

kubectl apply -f deploy-canary-api-svc.yml
kubectl apply -f deploy-canary-api-gray-svc.yml

二、Ingress灰度发布应用

Ingress-Nginx 支持配置 Ingress Annotations 来实现不同场景下的灰度发布和测试,可以满足金丝雀发布、蓝绿部署与 A/B 测试等业务场景。

因此我们准备两个版本的Ingress的yml文件,它提供了两种方式:

一是基于用户请求的流量切分,具体又包括了基于Request Header的流量切分与基于Cookie的流量切分两种方式;如下图所示:

二是基于服务权重的流量切分;如下图所示:

2.1 基于Request Header的流量切分方式

根据Request Header的流量切分方式的约定,适用于灰度发布及A/B测试。当 Request Header 设置为 always时,请求将会被一直发送到 Canary 版本;当 Request Header 设置为 never时,请求不会被发送到 Canary 入口;对于任何其他 Header 值,将忽略 Header,并通过优先级将请求与其他金丝雀规则进行优先级的比较。

为1.0版本准备一个Ingress,让它先工作着:

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: nginx-ingress
  namespace: xdp-poc
  annotations:
    kubernetes.io/ingress.class: "nginx"
    nginx.ingress.kubernetes.io/rewrite-target: /api/$2
spec:
  rules:
  - host: portal.k8s.xi-life.cn
    http:
      paths:
      - path: /api(/|$)(.*)
        backend:
          serviceName: canary-api-svc
          servicePort: 80

应用至K8s集群:

kubectl apply -f ingress-nginx.yaml

再为1.1版本准备一个Ingress,让它作为灰度版本的入口逐步替换原v1版本的流量接入:

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: nginx-ingress-gray
  namespace: xdp-poc
  annotations:
    kubernetes.io/ingress.class: "nginx"
    nginx.ingress.kubernetes.io/rewrite-target: /api/$2
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-by-header: "canary"
    nginx.ingress.kubernetes.io/canary-by-header-value: "true"
spec:
  rules:
  - host: portal.k8s.xi-life.cn
    http:
      paths:
      - path: /api(/|$)(.*)
        backend:
          serviceName: canary-api-svc-gray
          servicePort: 80

应用至K8s集群:

kubectl apply -f ingress-nginx.yaml

快速验证:

2.2 基于Cookie的流量切分方式

根据基于 Cookie 的流量切分方式的约定,当 Cookie 值设置为 always时,它将被路由到 Canary 入口;当 Cookie 值设置为 never时,请求不会被发送到 Canary 入口;对于任何其他值,将忽略 Cookie 并将请求与其他金丝雀规则进行优先级的比较。

为灰度版本准备Ingress:

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: nginx-ingress-gray
  namespace: xdp-poc
  annotations:
    kubernetes.io/ingress.class: "nginx"
    nginx.ingress.kubernetes.io/proxy-body-size: "100m"
    nginx.ingress.kubernetes.io/limit-rps: '10'
    nginx.ingress.kubernetes.io/rewrite-target: /api/$2
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-by-cookie: "xdp-v2-cookie"
spec:
  rules:
  - host: portal.k8s.xi-life.cn
    http:
      paths:
      - path: /api(/|$)(.*)
        backend:
          serviceName: canary-api-svc-gray
          servicePort: 80

应用至K8s集群:

kubectl apply -f ingress-nginx-gray.yaml

快速验证:

(1)未添加Cookie

(2)为要访问的域名添加一个Cookie

(3)再次请求验证

2.3 基于服务权重的流量切分方式 

根据基于服务权重的流量切分方式的约定,适用于蓝绿部署,权重范围 0 - 100 按百分比将请求路由到 Canary Ingress 中指定的服务。权重为 0 意味着该金丝雀规则不会向 Canary 入口的服务发送任何请求。权重为 100 意味着所有请求都将被发送到 Canary 入口。

为灰度版本准备Ingress:

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: nginx-ingress-gray
  namespace: xdp-poc
  annotations:
    kubernetes.io/ingress.class: "nginx"
    nginx.ingress.kubernetes.io/proxy-body-size: "100m"
    nginx.ingress.kubernetes.io/limit-rps: '10'
    nginx.ingress.kubernetes.io/rewrite-target: /api/$2
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-weight: "50"
spec:
  rules:
  - host: portal.k8s.xi-life.cn
    http:
      paths:
      - path: /api(/|$)(.*)
        backend:
          serviceName: canary-api-svc-gray
          servicePort: 80

应用至K8s集群:

kubectl apply -f ingress-nginx-gray.yaml

快速验证:这里我直接通过浏览器来测试,需要注意的是这里的50%是一个近似分布值,可能实际中不会太精确。

三、三种方式的对比

Nginx Ingress提供的三种灰度发布的方式的优先级顺序为:

canary-by-header -> canary-by-cookie -> canary-weight

已知限制:

(1)Ingress-Nginx是在0.21.0版本中才引入的Canary功能,因此建议确保版本在0.22.0及之后(据说0.21.0版本的基于Cookie方式有点问题);

(2)目前每个Ingress规则中最多只能应用一个canary入口

四、小结

本文介绍了Nginx Ingress提供的三种灰度发布(canary)的方式,然后介绍了如何使用Nginx Ingress并进行配置实现ASP.NET Core WebAPI应用服务的灰度发布实践,最后对比三种方式的优先级及限制,希望对你有所帮助。

此外,我也有录制一个10min+的小视频介绍蓝绿发布和金丝雀发布的基本概念,视频入口点击这里

参考资料

(1)JadePeng,《K8s基于Nginx Ingress实现灰度发布

(2)我的小碗汤,《Nginx Ingress实现灰度和金丝雀发布

(3)梁宽,《再也不踩坑的K8s实战指南

(4)WangT,《K8s基于Nginx Ingress进行蓝绿部署/金丝雀发布

(5)linus.lin,《一文明白蓝绿部署、滚动部署、灰度发布、金丝雀发布

相关实践学习
通过Ingress进行灰度发布
本场景您将运行一个简单的应用,部署一个新的应用用于新的发布,并通过Ingress能力实现灰度发布。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
目录
相关文章
|
1月前
|
Java 物联网 C#
C#/.NET/.NET Core学习路线集合,学习不迷路!
C#/.NET/.NET Core学习路线集合,学习不迷路!
|
2月前
|
存储 Kubernetes 持续交付
k8s学习
【10月更文挑战第1天】
111 4
|
2月前
|
存储 Kubernetes 调度
|
2月前
|
Kubernetes API 调度
k8s学习--pod的所有状态详解(图例展示)
k8s学习--pod的所有状态详解(图例展示)
250 1
|
2月前
|
开发框架 缓存 算法
开源且实用的C#/.NET编程技巧练习宝库(学习,工作,实践干货)
开源且实用的C#/.NET编程技巧练习宝库(学习,工作,实践干货)
|
2月前
|
Kubernetes 固态存储 调度
k8s学习--如何控制pod调度的位置
k8s学习--如何控制pod调度的位置
|
Kubernetes 容器
《基于Kubernetes的互联网Ingress实践》电子版地址
基于Kubernetes的互联网Ingress实践
132 0
《基于Kubernetes的互联网Ingress实践》电子版地址
|
2天前
|
Prometheus Kubernetes 监控
OpenAI故障复盘 - 阿里云容器服务与可观测产品如何保障大规模K8s集群稳定性
聚焦近日OpenAI的大规模K8s集群故障,介绍阿里云容器服务与可观测团队在大规模K8s场景下我们的建设与沉淀。以及分享对类似故障问题的应对方案:包括在K8s和Prometheus的高可用架构设计方面、事前事后的稳定性保障体系方面。
|
5天前
|
Kubernetes 网络协议 应用服务中间件
Kubernetes Ingress:灵活的集群外部网络访问的利器
《Kubernetes Ingress:集群外部访问的利器-打造灵活的集群网络》介绍了如何通过Ingress实现Kubernetes集群的外部访问。前提条件是已拥有Kubernetes集群并安装了kubectl工具。文章详细讲解了Ingress的基本组成(Ingress Controller和资源对象),选择合适的版本,以及具体的安装步骤,如下载配置文件、部署Nginx Ingress Controller等。此外,还提供了常见问题的解决方案,例如镜像下载失败的应对措施。最后,通过部署示例应用展示了Ingress的实际使用方法。
21 2
|
17天前
|
存储 Kubernetes 关系型数据库
阿里云ACK备份中心,K8s集群业务应用数据的一站式灾备方案
本文源自2024云栖大会苏雅诗的演讲,探讨了K8s集群业务为何需要灾备及其重要性。文中强调了集群与业务高可用配置对稳定性的重要性,并指出人为误操作等风险,建议实施周期性和特定情况下的灾备措施。针对容器化业务,提出了灾备的新特性与需求,包括工作负载为核心、云资源信息的备份,以及有状态应用的数据保护。介绍了ACK推出的备份中心解决方案,支持命名空间、标签、资源类型等维度的备份,并具备存储卷数据保护功能,能够满足GitOps流程企业的特定需求。此外,还详细描述了备份中心的使用流程、控制台展示、灾备难点及解决方案等内容,展示了备份中心如何有效应对K8s集群资源和存储卷数据的灾备挑战。