今天是元宵,祝大家元宵节快乐!
在日常的工作中,我们会经常对应用进行发版升级,在互联网公司尤为频繁,主要是为了满足快速的业务发展。我们经常用到的发布方式有滚动更新、蓝绿发布、灰度发布。
这里主要给大家分享如果通过ingress-nginx controller实现灰度发布。
本文大纲如下。
ingress-nginx是Kubernetes官方推荐的ingress controller,它是基于nginx实现的,增加了一组用于实现额外功能的Lua插件。
为了实现灰度发布,ingress-nginx通过定义annotation来实现不同场景的灰度发布,其支持的规则如下:
nginx.ingress.kubernetes.io/canary-by-header
:基于 Request Header 的流量切分,适用于灰度发布以及 A/B 测试。当 Request Header 设置为 always
时,请求将会被一直发送到 Canary 版本;当 Request Header 设置为 never
时,请求不会被发送到 Canary 入口;对于任何其他 Header 值,将忽略 Header,并通过优先级将请求与其他金丝雀规则进行优先级的比较。nginx.ingress.kubernetes.io/canary-by-header-value
:要匹配的 Request Header 的值,用于通知 Ingress 将请求路由到 Canary Ingress 中指定的服务。当 Request Header 设置为此值时,它将被路由到 Canary 入口。该规则允许用户自定义 Request Header 的值,必须与上一个 annotation (即:canary-by-header)一起使用。nginx.ingress.kubernetes.io/canary-weight
:基于服务权重的流量切分,适用于蓝绿部署,权重范围 0 - 100 按百分比将请求路由到 Canary Ingress 中指定的服务。权重为 0 意味着该金丝雀规则不会向 Canary 入口的服务发送任何请求。权重为 100 意味着所有请求都将被发送到 Canary 入口。nginx.ingress.kubernetes.io/canary-by-cookie
:基于 Cookie 的流量切分,适用于灰度发布与 A/B 测试。用于通知 Ingress 将请求路由到 Canary Ingress 中指定的服务的cookie。当 cookie 值设置为 always
时,它将被路由到 Canary 入口;当 cookie 值设置为 never
时,请求不会被发送到 Canary 入口;对于任何其他值,将忽略 cookie 并将请求与其他金丝雀规则进行优先级的比较。我们也是通过上面的annotation来实现灰度发布,其思路如下:
上面介绍了ingress-nginx实现灰度发布的方法以及咱们自己的实现思路,这里来探讨一下灰度发布有哪些发布场景。
假如在生产上已经运行了A应用对外提供服务,此时开发修复了一些Bug,需要发布A2版本将其上线,但是我们又不希望直接的将所有流量接入到新的A2版本,而是希望将10%的流量进入到A2中,待A2稳定后,才会将所有流量接入进来,再下线原来的A版本。
image.png
要实现这种,只需要在canary的ingress中添加如下annotation。
nginx.ingress.kubernetes.io/canary: "true"
nginx.ingress.kubernetes.io/canary-weight: "10"
其中nginx.ingress.kubernetes.io/canary
表示开启canary,nginx.ingress.kubernetes.io/canary-weight
表示我们设置的权重大小。
基于权重的发布场景比较粗糙,它是所有用户中的20%,无法限制具体的用户。
我们有时候会有这样的需求,比如我们有广东、北京、四川这三个地区的用户,并且已经有A版本的应用为这三个地区提供服务,由于更新了需求,我们需要发布A2应用,但是我们不想所有地区都访问A2应用,而是希望只有四川的用户可以访问,待四川地区反馈没问题后,才开放其他地区。
image.png
对于这种我们需要在canary的ingress中添加如下annotation。
nginx.ingress.kubernetes.io/canary: "true"
nginx.ingress.kubernetes.io/canary-by-header: "region"
nginx.ingress.kubernetes.io/canary-by-header-value: "sichuan"
主要就是上面两种发布场景,下面会针对这两种场景分别进行实验。
我这里准备了两个镜像,一个是稳定stable版本,一个是灰度canary版本。
由于两个场景只有在ingress处的配置不一致,其他都一样的,所以这里先将两个版本的应用都部署好。
(1)stable版本
apiVersion: apps/v1
kind: Deployment
metadata:
name: app-server-stable
spec:
selector:
matchLabels:
app: go-test
version: stable
replicas: 1
template:
metadata:
labels:
app: go-test
version: stable
spec:
containers:
- name: app-server
image: registry.cn-hangzhou.aliyuncs.com/rookieops/go-test:v1
imagePullPolicy: IfNotPresent
ports:
- name: http
containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
name: app-server-stable-svc
spec:
selector:
app: go-test
version: stable
ports:
- name: http
port: 8080
访问效果如下:
# curl 10.97.112.137:8080
{"data":"hello world","version":"v1"}
(2)canary版本
apiVersion: apps/v1
kind: Deployment
metadata:
name: app-server-canary
spec:
selector:
matchLabels:
app: go-test
version: canary
replicas: 1
template:
metadata:
labels:
app: go-test
version: canary
spec:
containers:
- name: app-server
image: registry.cn-hangzhou.aliyuncs.com/rookieops/go-test:v2
imagePullPolicy: IfNotPresent
ports:
- name: http
containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
name: app-server-canary-svc
spec:
selector:
app: go-test
version: canary
ports:
- name: http
port: 8080
访问效果如下:
# curl 10.110.178.174:8080
{"data":"hello SB","version":"v2"}
上面已经将应用部署好了,下面将针对权重和用户请求两个场景进行测试。
(1)配置stable版本的ingress
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
name: app-server-stable-ingress
annotations:
kubernetes.io/ingress.class: "nginx"
spec:
rules:
- host: joker.coolops.cn
http:
paths:
- path:
backend:
serviceName: app-server-stable-svc
servicePort: 8080
(2)配置canary版本的ingress
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
name: app-server-canary-ingress
annotations:
kubernetes.io/ingress.class: "nginx"
nginx.ingress.kubernetes.io/canary: "true"
nginx.ingress.kubernetes.io/canary-weight: "10"
spec:
rules:
- host: joker.coolops.cn
http:
paths:
- path:
backend:
serviceName: app-server-canary-svc
servicePort: 8080
然后我们通过访问测试,效果如下:
# curl joker.coolops.cn
{"data":"hello world","version":"v1"}
# curl joker.coolops.cn
{"data":"hello world","version":"v1"}
# curl joker.coolops.cn
{"data":"hello world","version":"v1"}
# curl joker.coolops.cn
{"data":"hello world","version":"v1"}
# curl joker.coolops.cn
{"data":"hello world","version":"v1"}
# curl joker.coolops.cn
{"data":"hello world","version":"v1"}
# curl joker.coolops.cn
{"data":"hello world","version":"v1"}
# curl joker.coolops.cn
{"data":"hello world","version":"v1"}
# curl joker.coolops.cn
{"data":"hello SB","version":"v2"}
# curl joker.coolops.cn
{"data":"hello world","version":"v1"}
# curl joker.coolops.cn
{"data":"hello world","version":"v1"}
# curl joker.coolops.cn
{"data":"hello world","version":"v1"}
基本保持在9:1
的比例。
(1)配置stable版本的ingress
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
name: app-server-stable-ingress
annotations:
kubernetes.io/ingress.class: "nginx"
spec:
rules:
- host: joker.coolops.cn
http:
paths:
- path:
backend:
serviceName: app-server-stable-svc
servicePort: 8080
(2)配置canary版本的ingress
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
name: app-server-canary-ingress
annotations:
kubernetes.io/ingress.class: "nginx"
nginx.ingress.kubernetes.io/canary: "true"
nginx.ingress.kubernetes.io/canary-by-header: "region"
nginx.ingress.kubernetes.io/canary-by-header-value: "sichuan"
spec:
rules:
- host: joker.coolops.cn
http:
paths:
- path:
backend:
serviceName: app-server-canary-svc
servicePort: 8080
当我们访问的时候不带header,则只会访问stable版本应用,如下:
# curl joker.coolops.cn
{"data":"hello world","version":"v1"}
# curl joker.coolops.cn
{"data":"hello world","version":"v1"}
如果我们在访问的时候带上region: sichuan
的header,则只会访问到canary版本应用,如下:
# curl joker.coolops.cn -H "region: sichuan"
{"data":"hello SB","version":"v2"}
# curl joker.coolops.cn -H "region: sichuan"
{"data":"hello SB","version":"v2"}
实现是不是很简单?
我们现在来想另外一个问题,上面的所有操作都是手动的,我们应该如何进行自动化?应该怎样来设计流水线?
下面来说说我个人的想法。
首先来捋捋过程:
整个过程很简单,但是对于已经部署好的<span style="font-size: 15px;">deployment
是不允许直接修改<span style="font-size: 15px;">labels
标签的。这时候是不是可以在canary版本测试i完成后直接更新stable版本的镜像?当然这种情况会存在滚动更新的一个过程。
那我们流水线可以这样设计,如下:
这样设计存在一个问题,那就是无法确定等待的时间,如果等待的时间很长,不仅很耗资源,也可能自动超时退出。
那我们是不是可以将其拆分为两条流水线?流程如下:
我比较倾向第二种,这种方式流水线跑完了就退出,不会占用额外的资源。
在开发流水线之前,我们需要先定义好命名标准,这样在操作的时候更加方便。
1 . 流水线名字格式如下:
a . <APP_NAME>-stable
b . <APP_NAME>-canary
2 . deployment的名字格式如下:
a . <APP_NAME>-stable
b . <APP_NAME>-canary
3 . service的名字格式如下:
a . <APP_NAME>-stable-svc
b . <APP_NAME>-canary-svc
4 . ingress的名字格式如下:
a . <APP_NAME>-stable-ingress
b . <APP_NAME>-canary-ingress
标准定义好之后,在实现的时候就简单多了。
代码位置:https://gitee.com/coolops/gary-devops.git
我定义了两个Jenkinsfile,一个叫canary.Jenkinsfile,一个叫stable.Jenkinsfile,他们分别用来部署canary和stable版本。
然后我们会创建两条流水线,如下:
其中joker-gary-devops-canary
是用来部署canary版本,另外一个是用来部署stable版本。
现在在集群里运行着stable版本,如下:
# curl -H "Host: joker.coolops.cn" http://192.168.100.61
{"data":"hello world!","version":"v1"}
我们修改了需求,更改了代码,变动如下:
package main
import (
"net/http"
"github.com/gin-gonic/gin"
)
func main() {
g := gin.Default()
g.GET("/", func(c *gin.Context) {
c.JSON(http.StatusOK, gin.H{
"version": "v1",
"data": "hello Joker!",
})
})
_ = g.Run(":8080")
}
首先发布canary流水线,待流水线发布完成,可以在集群中看到canary版本的pod以及ingress等,如下:
# kubectl get po| grep canary
gray-devops-canary-59c88846dc-j2vlc 1/1 Running 0 55s
# kubectl get svc| grep canary
gray-devops-canary-svc ClusterIP 10.233.18.235 <none> 8080/TCP 3h14m
# kubectl get ingress| grep canary
gray-devops-canary-ingress joker.coolops.cn 192.168.100.61 80 63s
查看一下canary-ingress的内容,看是否是我们需要的,如下:
# kubectl get ingress gray-devops-canary-ingress -o yaml
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
annotations:
kubernetes.io/ingress.class: nginx
nginx.ingress.kubernetes.io/canary: "true"
nginx.ingress.kubernetes.io/canary-weight: "10"
creationTimestamp: "2022-02-15T05:43:32Z"
generation: 1
name: gray-devops-canary-ingress
namespace: default
resourceVersion: "412247041"
selfLink: /apis/extensions/v1beta1/namespaces/default/ingresses/gray-devops-canary-ingress
uid: fe13b38d-1f6f-45fb-8d89-504b4b8288ea
spec:
rules:
- host: joker.coolops.cn
http:
paths:
- backend:
serviceName: gray-devops-canary-svc
servicePort: 8080
status:
loadBalancer:
ingress:
- ip: 192.168.100.61
可以发现跟我们预设的一样。
访问测试也没问题,如下:
# curl -H "Host: joker.coolops.cn" http://192.168.100.61
{"data":"hello Joker!","version":"v1"}[root@master ~]# curl -H "Host: joker.coolops.cn" http://192.168.100.61
{"data":"hello world!","version":"v1"}[root@master ~]# curl -H "Host: joker.coolops.cn" http://192.168.100.61
{"data":"hello world!","version":"v1"}[root@master ~]# curl -H "Host: joker.coolops.cn" http://192.168.100.61
{"data":"hello world!","version":"v1"}[root@master ~]# curl -H "Host: joker.coolops.cn" http://192.168.100.61
{"data":"hello world!","version":"v1"}[root@master ~]# curl -H "Host: joker.coolops.cn" http://192.168.100.61
{"data":"hello world!","version":"v1"}[root@master ~]# curl -H "Host: joker.coolops.cn" http://192.168.100.61
{"data":"hello world!","version":"v1"}[root@master ~]# curl -H "Host: joker.coolops.cn" http://192.168.100.61
{"data":"hello world!","version":"v1"}[root@master ~]# curl -H "Host: joker.coolops.cn" http://192.168.100.61
{"data":"hello world!","version":"v1"}[root@master ~]# curl -H "Host: joker.coolops.cn" http://192.168.100.61
{"data":"hello world!","version":"v1"}[root@master ~]# curl -H "Host: joker.coolops.cn" http://192.168.100.61
{"data":"hello Joker!","version":"v1"}[root@master ~]# curl -H "Host: joker.coolops.cn" http://192.168.100.61
{"data":"hello world!","version":"v1"}
现在就可以发布stable版本了,运行stable版本的流水线。发布完成后,集群里就只有stable版本的应用了,如下:
# kubectl get po | grep gray
gray-devops-stable-7f977bb6cf-8jzgt 1/1 Running 0 35s
# kubectl get ingress | grep gray
gray-devops-stable-ingress joker.coolops.cn 192.168.100.61 80 111m
通过域名访问也是符合预期的。
# curl -H "Host: joker.coolops.cn" http://192.168.100.61
{"data":"hello Joker!","version":"v1"}
到此基本实现了自己的想法。
说明:Jenkinsfile中涉及的用户名和密码都保存在Jenkins的凭据中,插件需要安装kubernetes deploy插件,到插件中心搜索就行。
上面我们基本实现了灰度发布的过程,也只是仅仅将手动的变成了自动。但是你有没有发现什么问题?
首先需要切换流水线进行发布,其次是发布控制方面也不是很友好,比如要增加canary版本的节点,就需要我们手动去做。
其实我更推荐使用argo-rollouts结合argocd进行灰度发布,argo-rollouts自定义了一套CRD用于控制发布流程,可以省去很多手动操作过程,argocd是基于gitops实现的一套软件,便于我们进行CD控制,也提供了UI面板进行操作。不过要用这套就需要更改现有的发布方式以及应用模板,不复杂,但是存在一定的风险,需要进行一定程度的测试。
本文由哈喽比特于2年以前收录,如有侵权请联系我们。
文章来源:https://mp.weixin.qq.com/s/mIg0D_FEbYuqXEshCI7Psw
京东创始人刘强东和其妻子章泽天最近成为了互联网舆论关注的焦点。有关他们“移民美国”和在美国购买豪宅的传言在互联网上广泛传播。然而,京东官方通过微博发言人发布的消息澄清了这些传言,称这些言论纯属虚假信息和蓄意捏造。
日前,据博主“@超能数码君老周”爆料,国内三大运营商中国移动、中国电信和中国联通预计将集体采购百万台规模的华为Mate60系列手机。
据报道,荷兰半导体设备公司ASML正看到美国对华遏制政策的负面影响。阿斯麦(ASML)CEO彼得·温宁克在一档电视节目中分享了他对中国大陆问题以及该公司面临的出口管制和保护主义的看法。彼得曾在多个场合表达了他对出口管制以及中荷经济关系的担忧。
今年早些时候,抖音悄然上线了一款名为“青桃”的 App,Slogan 为“看见你的热爱”,根据应用介绍可知,“青桃”是一个属于年轻人的兴趣知识视频平台,由抖音官方出品的中长视频关联版本,整体风格有些类似B站。
日前,威马汽车首席数据官梅松林转发了一份“世界各国地区拥车率排行榜”,同时,他发文表示:中国汽车普及率低于非洲国家尼日利亚,每百户家庭仅17户有车。意大利世界排名第一,每十户中九户有车。
近日,一项新的研究发现,维生素 C 和 E 等抗氧化剂会激活一种机制,刺激癌症肿瘤中新血管的生长,帮助它们生长和扩散。
据媒体援引消息人士报道,苹果公司正在测试使用3D打印技术来生产其智能手表的钢质底盘。消息传出后,3D系统一度大涨超10%,不过截至周三收盘,该股涨幅回落至2%以内。
9月2日,坐拥千万粉丝的网红主播“秀才”账号被封禁,在社交媒体平台上引发热议。平台相关负责人表示,“秀才”账号违反平台相关规定,已封禁。据知情人士透露,秀才近期被举报存在违法行为,这可能是他被封禁的部分原因。据悉,“秀才”年龄39岁,是安徽省亳州市蒙城县人,抖音网红,粉丝数量超1200万。他曾被称为“中老年...
9月3日消息,亚马逊的一些股东,包括持有该公司股票的一家养老基金,日前对亚马逊、其创始人贝索斯和其董事会提起诉讼,指控他们在为 Project Kuiper 卫星星座项目购买发射服务时“违反了信义义务”。
据消息,为推广自家应用,苹果现推出了一个名为“Apps by Apple”的网站,展示了苹果为旗下产品(如 iPhone、iPad、Apple Watch、Mac 和 Apple TV)开发的各种应用程序。
特斯拉本周在美国大幅下调Model S和X售价,引发了该公司一些最坚定支持者的不满。知名特斯拉多头、未来基金(Future Fund)管理合伙人加里·布莱克发帖称,降价是一种“短期麻醉剂”,会让潜在客户等待进一步降价。
据外媒9月2日报道,荷兰半导体设备制造商阿斯麦称,尽管荷兰政府颁布的半导体设备出口管制新规9月正式生效,但该公司已获得在2023年底以前向中国运送受限制芯片制造机器的许可。
近日,根据美国证券交易委员会的文件显示,苹果卫星服务提供商 Globalstar 近期向马斯克旗下的 SpaceX 支付 6400 万美元(约 4.65 亿元人民币)。用于在 2023-2025 年期间,发射卫星,进一步扩展苹果 iPhone 系列的 SOS 卫星服务。
据报道,马斯克旗下社交平台𝕏(推特)日前调整了隐私政策,允许 𝕏 使用用户发布的信息来训练其人工智能(AI)模型。新的隐私政策将于 9 月 29 日生效。新政策规定,𝕏可能会使用所收集到的平台信息和公开可用的信息,来帮助训练 𝕏 的机器学习或人工智能模型。
9月2日,荣耀CEO赵明在采访中谈及华为手机回归时表示,替老同事们高兴,觉得手机行业,由于华为的回归,让竞争充满了更多的可能性和更多的魅力,对行业来说也是件好事。
《自然》30日发表的一篇论文报道了一个名为Swift的人工智能(AI)系统,该系统驾驶无人机的能力可在真实世界中一对一冠军赛里战胜人类对手。
近日,非营利组织纽约真菌学会(NYMS)发出警告,表示亚马逊为代表的电商平台上,充斥着各种AI生成的蘑菇觅食科普书籍,其中存在诸多错误。
社交媒体平台𝕏(原推特)新隐私政策提到:“在您同意的情况下,我们可能出于安全、安保和身份识别目的收集和使用您的生物识别信息。”
2023年德国柏林消费电子展上,各大企业都带来了最新的理念和产品,而高端化、本土化的中国产品正在不断吸引欧洲等国际市场的目光。
罗永浩日前在直播中吐槽苹果即将推出的 iPhone 新品,具体内容为:“以我对我‘子公司’的了解,我认为 iPhone 15 跟 iPhone 14 不会有什么区别的,除了序(列)号变了,这个‘不要脸’的东西,这个‘臭厨子’。