建设网站的风险6,如何创建自己的网站平台免费,云主机 多个网站,wordpress阿里云主机通过Ingress-nginx实现灰度发布 灰度发布原理将新版本灰度给部分用户切一定比例的流量给新版本 部署两个版本的服务以 nginx 为例#xff0c;先部署一个 v1 版本:部署一个 v2 版本再创建一个 Ingress#xff0c;对外暴露服务#xff0c;指向 v1 版本的服务:访问验证 基于 He… 通过Ingress-nginx实现灰度发布 灰度发布原理将新版本灰度给部分用户切一定比例的流量给新版本 部署两个版本的服务以 nginx 为例先部署一个 v1 版本:部署一个 v2 版本再创建一个 Ingress对外暴露服务指向 v1 版本的服务:访问验证 基于 Header 的流量切分测试访问 基于 Cookie 的流量切分测试访问: 基于服务权重的流量切分测试访问: 灰度发布原理
将新版本灰度给部分用户
假设线上运行了一套对外提供 7 层服务的 Service A 服务后来开发了个新版本 Service A’ 想要上线但又不想直接替换掉原来的 Service A希望先灰度一小部分用户等运行一段时间足够稳定了再逐渐全量上线新版本最后平滑下线旧版本。这个时候就可以利用 Nginx Ingress 基于 Header 或 Cookie 进行流量切分的策略来发布业务使用 Header 或 Cookie 来标识不同类型的用户我们通过配置 Ingress 来实现让带有指定 Header 或 Cookie 的请求被转发到新版本其它的仍然转发到旧版本从而实现将新版本灰度给部分用户:
切一定比例的流量给新版本
假设线上运行了一套对外提供 7 层服务的 Service B 服务后来修复了一些问题需要灰度上线一个新版本 Service B’但又不想直接替换掉原来的 Service B而是让先切 10% 的流量到新版本等观察一段时间稳定后再逐渐加大新版本的流量比例直至完全替换旧版本最后再滑下线旧版本从而实现切一定比例的流量给新版本:
部署两个版本的服务
Ingress-Nginx是一个K8S ingress工具支持配置Ingress Annotations来实现不同场景下的灰度发布和测试。 Nginx Annotations 支持以下几种Canary规则
假设我们现在部署了两个版本的服务老版本和canary版本nginx.ingress.kubernetes.io/canary-by-header基于Request Header的流量切分适用于灰度发布以及 A/B 测试。当Request Header 设置为 always时请求将会被一直发送到 Canary 版本当 Request Header 设置为 never时请求不会被发送到 Canary 入口。nginx.ingress.kubernetes.io/canary-by-header-value要匹配的 Request Header 的值用于通知 Ingress 将请求路由到 Canary Ingress 中指定的服务。当 Request Header 设置为此值时它将被路由到 Canary 入口。nginx.ingress.kubernetes.io/canary-weight基于服务权重的流量切分适用于蓝绿部署权重范围 0 - 100 按百分比将请求路由到 Canary Ingress 中指定的服务。权重为 0 意味着该金丝雀规则不会向 Canary 入口的服务发送任何请求。权重为60意味着60%流量转到canary。权重为 100 意味着所有请求都将被发送到 Canary 入口。nginx.ingress.kubernetes.io/canary-by-cookie基于 Cookie 的流量切分适用于灰度发布与 A/B 测试。用于通知 Ingress 将请求路由到 Canary Ingress 中指定的服务的cookie。当 cookie 值设置为 always时它将被路由到 Canary 入口当 cookie 值设置为 never时请求不会被发送到 Canary 入口。
以 nginx 为例先部署一个 v1 版本: 上传openresty.tar.gz至node节点 链接https://pan.baidu.com/s/10BU9qNqiAjfQfb9ZyVh1cQ?pwd6uaq 提取码6uaq ctr -nk8s.io images import openresty.tar.gz
docker load -i openresty.tar.gz在master执行 vim v1.yamlapiVersion: apps/v1
kind: Deployment
metadata:name: nginx-v1
spec:replicas: 1selector:matchLabels:app: nginxversion: v1template:metadata:labels:app: nginxversion: v1spec:containers:- name: nginximage: openresty/openresty:centosimagePullPolicy: IfNotPresentports:- name: httpprotocol: TCPcontainerPort: 80volumeMounts:- mountPath: /usr/local/openresty/nginx/conf/nginx.confname: configsubPath: nginx.confvolumes:- name: configconfigMap:name: nginx-v1
---
apiVersion: v1
kind: ConfigMap
metadata:labels:app: nginxversion: v1name: nginx-v1
data:nginx.conf: |-worker_processes 1;events {accept_mutex on;multi_accept on;use epoll;worker_connections 1024;}http {ignore_invalid_headers off;server {listen 80;location / {access_by_lua local header_str ngx.say(nginx-v1);}}}
---
apiVersion: v1
kind: Service
metadata:name: nginx-v1
spec:type: ClusterIPports:- port: 80protocol: TCPname: httpselector:app: nginxversion: v1kubectl apply -f v1.yaml部署一个 v2 版本
vim v2.yamlapiVersion: apps/v1
kind: Deployment
metadata:name: nginx-v2
spec:replicas: 1selector:matchLabels:app: nginxversion: v2template:metadata:labels:app: nginxversion: v2spec:containers:- name: nginximage: openresty/openresty:centosimagePullPolicy: IfNotPresentports:- name: httpprotocol: TCPcontainerPort: 80volumeMounts:- mountPath: /usr/local/openresty/nginx/conf/nginx.confname: configsubPath: nginx.confvolumes:- name: configconfigMap:name: nginx-v2
---
apiVersion: v1
kind: ConfigMap
metadata:labels:app: nginxversion: v2name: nginx-v2
data:nginx.conf: |-worker_processes 1;events {accept_mutex on;multi_accept on;use epoll;worker_connections 1024;}http {ignore_invalid_headers off;server {listen 80;location / {access_by_lua local header_str ngx.say(nginx-v2);}}}
---
apiVersion: v1
kind: Service
metadata:name: nginx-v2
spec:type: ClusterIPports:- port: 80protocol: TCPname: httpselector:app: nginxversion: v2kubectl apply -f v2.yaml再创建一个 Ingress对外暴露服务指向 v1 版本的服务:
vim v1-ingress.yamlapiVersion: networking.k8s.io/v1
kind: Ingress
metadata:name: nginxannotations:kubernetes.io/ingress.class: nginx
spec:rules:- host: canary.example.comhttp:paths:- path: / #配置访问路径如果通过url进行转发需要修改空默认为访问的路径为/pathType: Prefixbackend: #配置后端服务service:name: nginx-v1port:number: 80kubectl apply -f v1-ingress.yaml访问验证
#curl -H Host: canary.example.com http://EXTERNAL-IP # EXTERNAL-IP 替换为 Nginx Ingress 自身对外暴露的 IPcurl -H Host: canary.example.com http://192.168.40.12基于 Header 的流量切分 创建 Canary Ingress指定 v2 版本的后端服务且加上一些 annotation实现仅将带有名为 Region 且值为 cd 或 sz 的请求头的请求转发给当前 Canary Ingress模拟灰度新版本给成都和深圳地域的用户: vim v2-ingress.yamlapiVersion: networking.k8s.io/v1
kind: Ingress
metadata:annotations:kubernetes.io/ingress.class: nginxnginx.ingress.kubernetes.io/canary: truenginx.ingress.kubernetes.io/canary-by-header: Regionnginx.ingress.kubernetes.io/canary-by-header-pattern: cd|szname: nginx-canary
spec:rules:- host: canary.example.comhttp:paths:- path: / #配置访问路径如果通过url进行转发需要修改空默认为访问的路径为/pathType: Prefixbackend: #配置后端服务service:name: nginx-v2port:number: 80kubectl apply -f v2-ingress.yaml测试访问
#curl -H Host: canary.example.com -H Region: cd http://EXTERNAL-IP # EXTERNAL-IP 替换为 Nginx Ingress 自身对外暴露的 IPcurl -H Host: canary.example.com -H Region: cd http://192.168.40.12curl -H Host: canary.example.com -H Region: bj http://192.168.40.12curl -H Host: canary.example.com -H Region: cd http://192.168.40.12可以看到只有 header Region 为 cd 或 sz 的请求才由 v2 版本服务响应。 基于 Cookie 的流量切分 与前面 Header 类似不过使用 Cookie 就无法自定义 value 了这里以模拟灰度成都地域用户为例仅将带有名为 user_from_cd 的 cookie 的请求转发给当前 Canary Ingress 。先删除前面基于 Header 的流量切分的 Canary Ingress然后创建下面新的 Canary Ingress: kubectl delete -f v2-ingress.yaml
vim v1-cookie.yamlapiVersion: networking.k8s.io/v1
kind: Ingress
metadata:annotations:kubernetes.io/ingress.class: nginxnginx.ingress.kubernetes.io/canary: truenginx.ingress.kubernetes.io/canary-by-cookie: user_from_cdname: nginx-canary
spec:rules:- host: canary.example.comhttp:paths:- path: / #配置访问路径如果通过url进行转发需要修改空默认为访问的路径为/pathType: Prefixbackend: #配置后端服务service:name: nginx-v2port:number: 80kubectl apply -f v1-cookie.yaml测试访问:
#curl -s -H Host: canary.example.com --cookie user_from_cdalways http://EXTERNAL-IP # EXTERNAL-IP 替换为 Nginx Ingress 自身对外暴露的 IPcurl -s -H Host: canary.example.com --cookie user_from_cdalways http://192.168.40.12curl -s -H Host: canary.example.com --cookie user_from_bjalways http://192.168.40.12curl -s -H Host: canary.example.com http://192.168.40.12可以看到只有 cookie user_from_cd 为 always 的请求才由 v2 版本的服务响应。 基于服务权重的流量切分 基于服务权重的 Canary Ingress 就简单了直接定义需要导入的流量比例这里以导入 10% 流量到 v2 版本为例 (如果有先删除之前的 Canary Ingress): kubectl delete -f v1-cookie.yamlvim v1-weight.yamlapiVersion: networking.k8s.io/v1
kind: Ingress
metadata:annotations:kubernetes.io/ingress.class: nginxnginx.ingress.kubernetes.io/canary: truenginx.ingress.kubernetes.io/canary-weight: 10name: nginx-canary
spec:rules:- host: canary.example.comhttp:paths:- path: / #配置访问路径如果通过url进行转发需要修改空默认为访问的路径为/pathType: Prefixbackend: #配置后端服务service:name: nginx-v2port:number: 80kubectl apply -f v1-weight.yaml测试访问:
#for i in {1..10}; do curl -H Host: canary.example.com http://EXTERNAL-IP; done;for i in {1..10}; do curl -H Host: canary.example.com http://192.168.40.12; done;可以看到大概只有十分之一的几率由 v2 版本的服务响应符合 10% 服务权重的设置
