基于K8S的灰度发布实践
前言
灰度发布（又名金丝雀发布）是指在黑与白之间，能够平滑过渡的一种发布方式。在其上可以进行A/B testing，即让一部分用户继续用产品特性A，一部分用户开始用产品特性B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。
总结下一些应用场景：
- 微服务依赖很多组件，需要在实际环境验证
- 部署新功能有风险，然后可以通过导流一小部分用户实际使用，来减小风险
- 让特定的用户访问新版本，比如部署一个版本，只让测试使用
- A/B Testing，部署两个版本，进行版本对比，比如验证两个推荐服务的推荐效果
灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。
## 灰度发布也可以通过 Kong 实现
https://blog.csdn.net/knight_zhou/article/details/122250341
##
写个监听器，监听pod的变化然后请求kong的api写到kong即可。
使用ingress-nginx 模拟灰度发布
## 参考文档
https://www.cnblogs.com/xiaoqi/p/ingress-nginx-canary.html
## 官网
https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/#canary
Ingress-Nginx 是一个K8S ingress工具，支持配置 Ingress Annotations 来实现不同场景下的灰度发布和测试。 Nginx Annotations 支持以下 4 种 Canary 规则：
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 规则可以总体划分为以下两类
- 基于权重的 Canary 规则
- 基于用户请求的 Canary 规则
测试
应用准备
两个版本的服务，正常版本:
import static java.util.Collections.singletonMap;
@SpringBootApplication
@Controller
public class RestPrometheusApplication {
@Autowired
private MeterRegistry registry;
@GetMapping(path = "/", produces = "application/json")
@ResponseBody
public Map landingPage() {
Counter.builder("mymetric").tag("foo", "bar").register(registry).increment();
return singletonMap("hello", "这是正常版本...");
}
public static void main(String[] args) {
SpringApplication.run(RestPrometheusApplication.class, args);
}
}
访问会输出：
{"hello":"这是正常版本"} 灰度版本：
import static java.util.Collections.singletonMap;
@SpringBootApplication
@Controller
public class RestPrometheusApplication {
@Autowired
private MeterRegistry registry;
@GetMapping(path = "/", produces = "application/json")
@ResponseBody
public Map landingPage() {
Counter.builder("mymetric").tag("foo", "bar").register(registry).increment();
return singletonMap("hello", "knight, this is a gray version");
}
public static void main(String[] args) {
SpringApplication.run(RestPrometheusApplication.class, args);
}
}
访问输出：
{"hello":"knight, this is a gray version"} ingress 配置
我们部署好两个服务，springboot-rest-demo是正常的服务，springboot-rest-demo-gray是灰度服务，我们来配置ingress，通过canary-by-header来实现：
正常服务的：
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: springboot-rest-demo
annotations:
kubernetes.io/ingress.class: nginx
spec:
rules:
- host: springboot-rest.knight.com
http:
paths:
- backend:
serviceName: springboot-rest-demo
servicePort: 80灰度 canary 版本：
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: springboot-rest-demo-gray
annotations:
kubernetes.io/ingress.class: nginx
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: springboot-rest.knight.com
http:
paths:
- backend:
serviceName: springboot-rest-demo-gray
servicePort: 80将上面的文件执行：
$sudo kubectl -n=default apply -f ingress-test.yml
ingress.extensions/springboot-rest-demo created
ingress.extensions/springboot-rest-demo-gray created执行测试，不添加header，访问的默认是正式版本：
# curl http://springboot-rest.knight.com; echo
{"hello":"ambassador"}
添加header，可以看到，访问的已经是灰度版本了
# curl -H "canary: true" http://springboot-rest.knight.com; echo
{"hello":"ambassador, this is a gray version"}