这期内容当中小编将会给大家带来有关F5与Openshift集成怎么实现灰度发布，文章内容丰富且以专业的角度为大家分析和叙述，阅读完这篇文章希望大家可以有所收获。
什么是灰度发布
灰度发布是指在黑与白之间，能够平滑过渡的一种发布方式。ABtest就是一种灰度发布方式，让一部分用户继续用A，一部分用户开始用B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。
灰度发布的价值
使用灰度发布可以在产品正式上线前针对特定一些目标用户进行开放，获得这些目标用户的反馈，及早发现问题，修复问题，完善产品的不足。如果发现新的版本价值不大，能够及早更换思路，避免产品直接上线后产生不好的影响。
Openshift Route自带的灰度发布功能
Openshift Route自带的灰度发布，是通过Route下“挂载”两个或两个以上Service，并调整各个Service的权值进行控制流量的分布。
例如应用有两个服务，分别为service-v1和service-v2，其中service-v2为新版本。通过不断放大service-v2的权值，观察用户的反馈，及时发现service-v2中的问题，并完善修复，最终service-v2承载所有service-v1的流量，实现服务的升级。通过这种方式，可以大大地降低service-v2中的问题对客户产生的影响。
Openshift Route对Service分流使用非常方便，一些普通的业务完全可以使用这个特性达到测试的目的。但是它的简单也带来了一些不足，就是它只能对请求进行概率地划分流量，并不能定向到用户。
例如，以下需求Openshift Route目前还无法实现。产品新版本正式发布前，我们希望对产品进行一些测试，只允许指定的一批用户或者一些网段的ip下的用户才能访问新版本。
流量到达F5时，F5会优先对请求进行iRule下的匹配检查，定向到对应的Pool
如果iRule下未匹配，则会控制vs下绑定的Polices规则进行匹配
在上篇中，我们知道Openshift上的F5控制器会自动在F5上生成Polices规则，来满足Openshift Route的功能。那么只需要将它与自定义的iRule结合就能够实现既满足服务的分流，又能控制用户对服务的定向访问。
准备工作（详细见上篇：Openshift-F5集成（南北流量走F5））
创建新的HostSub
Local Traffic -> Virtual Servers
Name：VS名字
Destination Address/Mask：VS的IP地址
Service Port：HTTP
HTTP Profile：http
Source Address Translation：Auto Map
HTTPS
Name：VS名字
Destination Address/Mask：VS的IP地址
Service Port：HTTPS
HTTP Profile：http
SSL Profile (Client)：/Common/clientssl
Source Address Translation：Auto Map
设置VS中的cccl-whitelist为1
对应每台F5设备创建一个Deployment
Deployment中的 --bigip-url 为设备的IP
Deployment中的 --bigip-partition为之前F5下创建的Partition,Openshift
Deployment中的--route-http-vserver为手动创建的HTTP VS
Deployment中的--route-https-vserver为手动创建的HTTPS VS
Deployment中的--route-label为给Controller打的标签（对于一组F5不需要配置，多组F5通过它打Label，并在Route中设置label f5type:label来指定使用的F5）
apiVersion: extensions/v1beta1 kind: Deployment metadata: name: f5-bigip-ctlr-01 spec: replicas: 1 template: metadata: name: k8s-bigip-ctlr labels: app: k8s-bigip-ctlr spec: # Name of the Service Account bound to a Cluster Role with the required # permissions serviceAccountName: bigip-ctlr containers: - name: k8s-bigip-ctlr # replace the version as needed image: "f5networks/k8s-bigip-ctlr:1.5.1" env: - name: BIGIP_USERNAME valueFrom: secretKeyRef: # Replace with the name of the Secret containing your login # credentials name: bigip-login key: username - name: BIGIP_PASSWORD valueFrom: secretKeyRef: # Replace with the name of the Secret containing your login # credentials name: bigip-login key: password command: ["/app/bin/k8s-bigip-ctlr"] args: [ # See the k8s-bigip-ctlr documentation for information about # all config options # http://clouddocs.f5.com/products/connectors/k8s-bigip-ctlr/latest "--bigip-username=$(BIGIP_USERNAME)", "--bigip-password=$(BIGIP_PASSWORD)", "--bigip-url=192.168.200.82", "--bigip-partition=OpenShift", "--pool-member-type=cluster", "--openshift-sdn-name=/Common/openshift_vxlan", '--manage-routes=true' '--route-http-vserver=testroute' '--route-https-vserver=testroute_https' ] --- apiVersion: extensions/v1beta1 kind: Deployment metadata: name: f5-bigip-ctlr-02 spec: replicas: 1 template: metadata: name: k8s-bigip-ctlr labels: app: k8s-bigip-ctlr spec: # Name of the Service Account bound to a Cluster Role with the required # permissions serviceAccountName: bigip-ctlr containers: - name: k8s-bigip-ctlr # replace the version as needed image: "f5networks/k8s-bigip-ctlr:1.5.1" env: - name: BIGIP_USERNAME valueFrom: secretKeyRef: # Replace with the name of the Secret containing your login # credentials name: bigip-login key: username - name: BIGIP_PASSWORD valueFrom: secretKeyRef: # Replace with the name of the Secret containing your login # credentials name: bigip-login key: password command: ["/app/bin/k8s-bigip-ctlr"] args: [ # See the k8s-bigip-ctlr documentation for information about # all config options # http://clouddocs.f5.com/products/connectors/k8s-bigip-ctlr/latest "--bigip-username=$(BIGIP_USERNAME)", "--bigip-password=$(BIGIP_PASSWORD)", "--bigip-url=192.168.200.83", "--bigip-partition=OpenShift", "--pool-member-type=cluster", "--openshift-sdn-name=/Common/openshift_vxlan", '--manage-routes=true' '--route-http-vserver=testroute' '--route-https-vserver=testroute_https' ]给vs手动绑定Policies
Openshift F5控制器创建好后，在F5上会自动创建两条Policies, 分别为：openshift_insecure_routes、openshift_secure_routes。
openshift_insecure_routes为HTTP应用服务
openshift_secure_routes为HTTPS应用服务。
绑定Policies与iRule
创建应用（Project名为testapp，Service名为f5-nginx-v1与f5-nginx-v2）
oc new-project testapp oc new-app harbor.example.com/public/nginx:1.14 --name=f5-nginx-v1 --allow-missing-images oc expose dc/f5-test-v1 --port=8080oc expose svc/f5-test-v1 test1.apps.openshift.com oc new-app harbor.example.com/public/nginx:1.14 --name=f5-nginx-v2 --allow-missing-images oc expose dc/f5-test-v2 --port=8080创建iRule,并绑定到VS
F5
说明：请求域名
test1.apps.openshift.com时，如果客户端IP为192.168.100.23，则访问testapp项目下的f5-nginx-v2服务，否则访问testapp项目下的f5-nginx-v1服务
注意：iRule规则需要在Common的Partition下创建when HTTP_REQUEST { if { [HTTP::host] equals "test1.apps.openshift.com" }{ log local0.info [HTTP::host] if {[IP::addr [IP::client_addr] equals 192.168.100.23/32 ]} { log local0.info "enter 2 pool before" log local0.info [HTTP::host] pool /f5-openShift/openshift_testapp_f5-nginx-v2 log local0.info "enter 2 pool later" } else { log local0.info "enter 3" pool /f5-openShift/openshift_testapp_f5-nginx-v1 } } }测试访问服务
本地(192.168.100.23)与另一台非192.168.100.23的机器上绑定hosts
VS的IP地址 test1.apps.openshift.com再访问test1.apps.openshift.com，查看页面显示，访问不同的Service。
上述就是小编为大家分享的F5与Openshift集成怎么实现灰度发布了，如果刚好有类似的疑惑，不妨参照上述分析进行理解。如果想知道更多相关知识，欢迎关注亿速云行业资讯频道。
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
