核心内容摘要
10秒详论成色，18K金1.88克拉的心动，VVS净度下的璀璨光芒
前言上一小节istio成功的安装并且还解决了常见的426的问题本节内容主要探讨一下istio关于流量转发的问题按比例分发配置需要创建一个backend-v1它与backend的selector都是/* by
hk - online tools website :
hk/zh/jianfan.html */ app: backendbackend-v1部署完成之后它会立即分走50%的流量为了测试istio流控我们需要在不改变任何配置的情况下实现9:1分流也就是90%进入原backend10%进入新的backend-v1标记2个deployment追加标签backend为/* by
hk - online tools website :
hk/zh/jianfan.html */ version: v0backend-v1为version: v1kubectl patch deployment backend -p {spec:{template:{metadata:{labels:{version:v0}}}}} kubectl patch deployment backend-v1 -p {spec:{template:{metadata:{labels:{version:v1}}}}}创建istio资源DestinationRule该资源主要用来标记istio要往哪个地方转发apiVersion: networking.istio.io/v1 kind: DestinationRule metadata: name: backend-dr namespace: default spec: host: backend-service subsets: - labels: version: v0 name: v0 - labels: version: v1 name: v1创建istio资源VirtualService该资源用来确定转发的权重apiVersion: networking.istio.io/v1 kind: VirtualService metadata: name: backend-vs namespace: default spec: hosts: - backend-service http: - route: - destination: host: backend-service subset: v0 weight: 90 - destination: host: backend-service subset: v1 weight: 10调试测试命令for i in {
.10}; do curl -s
10.
22.
1
178:30785/test /dev/null ; done登录到k8s的istio-proxy控制台查看kubectl logs -f -l appbackend -c istio-proxy[
T08:24:
5
670Z] GET /test HTTP/
1 200 - upstream
10.
244.
55:10000 duration0ms routedefault [
T08:24:
5
687Z] GET /test HTTP/
1 200 - upstream
10.
244.
55:10000 duration0ms routedefault [
T08:24:
5
706Z] GET /test HTTP/
1 200 - upstream
10.
244.
53:10000 duration0ms routedefault [
T08:24:
5
741Z] GET /test HTTP/
1 200 - upstream
10.
244.
53:10000 duration1ms routedefault [
T08:24:
5
751Z] GET /test HTTP/
1 200 - upstream
10.
244.
53:10000 duration0ms routedefault [
T08:24:
5
759Z] GET /test HTTP/
1 200 - upstream
10.
244.
53:10000 duration0ms routedefault [
T08:24:
5
696Z] GET /test HTTP/
1 200 - upstream
10.
244.
55:10000 duration0ms routedefault [
T08:24:
5
716Z] GET /test HTTP/
1 200 - upstream
10.
244.
55:10000 duration0ms routedefault [
T08:24:
5
725Z] GET /test HTTP/
1 200 - upstream
10.
244.
55:10000 duration0ms routedefault [
T08:24:
5
734Z] GET /test HTTP/
1 200 - upstream
10.
244.
55:10000 duration0ms routedefault▶ kubectl get pod -owide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES backend-86b958bdc-5zjgn 2/2 Running 0 21m
10.
244.
53 wilson none none backend-v
ccff86dc-sl6bt 2/2 Running 0 119s
10.
244.
55 wilson none none nginx-test-7d
vsrp 2/2 Running 0 30m
10.
244.
61 wilson none none明显不对
10.
244.
55与
10.
244.
53的比例并没有呈现9:1转发到backend要backend-v1还是5:5修复可以直接修改nginx的配置server { listen 80; listen [::]:80; server_name localhost; location /test { proxy_http_version
1; # proxy_set_header Host $host; # 原配置 proxy_set_header Host backend-service.default.svc.cluster.local; # 新配置 proxy_pass http://backend-service:10000; } }重启之后再次测试[
T08:30:
5
968Z] GET /test HTTP/
1 200 - upstream
10.
244.
53:10000 duration0ms routedefault [
T08:30:
5
988Z] GET /test HTTP/
1 200 - upstream
10.
244.
53:10000 duration1ms routedefault [
T08:31:
0
027Z] GET /test HTTP/
1 200 - upstream
10.
244.
53:10000 duration1ms routedefault [
T08:31:
0
037Z] GET /test HTTP/
1 200 - upstream
10.
244.
53:10000 duration0ms routedefault [
T08:31:
0
048Z] GET /test HTTP/
1 200 - upstream
10.
244.
53:10000 duration0ms routedefault [
T08:31:
0
056Z] GET /test HTTP/
1 200 - upstream
10.
244.
53:10000 duration0ms routedefault [
T08:31:
0
008Z] GET /test HTTP/
1 200 - upstream
10.
244.
55:10000 duration0ms routedefault [
T08:31:
0
066Z] GET /test HTTP/
1 200 - upstream
10.
244.
53:10000 duration0ms routedefault [
T08:31:
0
074Z] GET /test HTTP/
1 200 - upstream
10.
244.
53:10000 duration0ms routedefault [
T08:31:
0
083Z] GET /test HTTP/
1 200 - upstream
10.
244.
53:10000 duration0ms routedefault已经生效了这次只有1次
10.
244.
55:10000疑问有位大哥说了如果这样配置的明显影响了业务nginx的配置被修改了所有的host被写死了都成了backend-service.default.svc.cluster.local而后端业务是需要把客户端的host带入过去的改了之后后端业务收到严重影响确实固定host属于粗暴简单的写法还有更加惊喜的解决方法调整VirtualService添加hostsapiVersion: networking.istio.io/v1 kind: VirtualService metadata: name: backend-vs namespace: default spec: hosts: - backend-service - api.wilsontest.com # 新增 http: - route: - destination: host: backend-service subset: v0 weight: 90 - destination: host: backend-service subset: v1 weight: 10客户端访问的时候必须带上该域名for i in {
.10}; do curl -s -H host: api.wilsontest.com
10.
22.
1
178:30785/test /dev/null ; done这样也可以解决问题不过坑点也来了年久失修从无数前人继承的祖传代码就需要好好的梳理到底有哪些host来访问否则漏掉host的话就会出现配置问题。
-_-!再次凸显了istio之中host是非常非常重要的Istio 的路由决策、Service 的匹配完全依赖 Host 头Istio 的 VirtualService 本质上是一个“增强版”的路由器。
如果发现请求的 Host 是 backend-service就按 90:10 分配。
之前的配置是$host由于客户端没有传输host当请求经过 Nginx 的 Sidecar时它会检查Host发现为空。
由于路由表里没有对应的记录 sidecar并不认识按普通 K8s 流量处理按header分发apiVersion: networking.istio.io/v1 kind: VirtualService metadata: name: backend-vs namespace: default spec: hosts: - backend-service - api.wilsontest.com http: - match: - headers: hellotest: exact: true route: - destination: host: backend-service subset: v1 - route: - destination: host: backend-service subset: v0curl -s -H host: api.wilsontest.com -H hellotest: true
10.
22.
1
178:30785/test。
只有header里面匹配了hellotest: true才会去v1否则全部去v0按前缀分发apiVersion: networking.istio.io/v1 kind: VirtualService metadata: name: backend-vs namespace: default spec: hosts: - backend-service - api.wilsontest.com http: - match: - uri: prefix: /test/v1 route: - destination: host: backend-service subset: v1 - route: - destination: host: backend-service subset: v0带有/test/v1前缀的都会去新版本v1满足不了条件都会走默认的版本v0url改写apiVersion: networking.istio.io/v1 kind: VirtualService metadata: name: backend-vs namespace: default spec: hosts: - backend-service - api.wilsontest.com http: - match: - uri: prefix: /test/v1 route: - destination: host: backend-service subset: v1 - match: - uri: prefix: /test/v2 rewrite: uri: /test route: - destination: host: backend-service subset: v0 - route: - destination: host: backend-service subset: v0如果是/test/v1就访问v1版本/test/v2重写成/test并且访问v0版本其余的默认都会走v0版本蓝绿、金丝雀、灰度、A/B测试关于流量分流的各种操作大部分都集中在以下场景蓝绿实现瞬间切换与零宕机回滚消除发布期间的中间状态金丝雀像矿工用金丝雀探测毒气一样先让一小部分用户如1%~5%访问新版本观察系统指标如错误率、延迟若无问题再逐步扩大范围灰度将用户群体按比例或特定规则如地域、设备逐步切换到新版本例如10%→30%→100%持续观察反馈A/B同时向随机分组的用户展示不同版本A组用旧版B组用新版通过统计指标如点击率、转化率判断哪个版本更优蓝绿发布金丝雀发布灰度发布A/B测试主要目标零停机、瞬时回滚用真实流量快速发现技术风险平稳、可控地逐步替换所有用户验证不同版本的业务效果流量路由全量切换100%→0%极小比例引流如1%-5%按比例分阶段扩大10%→50%→100%按规则/随机分配如50%/50%关注重点系统可用性与回滚速度系统稳定性指标错误率、延迟发布过程平稳性与综合反馈业务指标转化率、留存率所需资源两套完整环境成本高一套环境新版本实例较少一套环境新旧版本实例共存一套或多套环境并行运行多个版本用户选择全体用户同时切换小部分用户随机或按基础设施选择用户按比例或属性逐步迁移用户随机分组或按属性定向分配持续时间极短切换在几分钟内短几小时到一天中长几天到数周长数周到数月典型场景关键业务大版本升级、基础设施更换后端服务、中间件、数据库变更前端功能、用户界面更新UI设计、文案、算法策略、定价优化联系我联系我做深入的交流至此本文结束在下才疏学浅有撒汤漏水的请各位不吝赐教...本文来自博客园作者it排球君转载请注明原文链接https://www.cnblogs.com/MrVolleyball/p/19574573本文版权归作者和博客园共有欢迎转载但未经作者同意必须在文章页面给出原文连接否则保留追究法律责任的权利。