F5与Openshift集成怎么实现灰度发布

共计 5443 个字符，预计需要花费 14 分钟才能阅读完成。

这期内容当中丸趣 TV 小编将会给大家带来有关 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 与 Openshift 集成实现灰度发布

流量到达 F5 时，F5 会优先对请求进行 iRule 下的匹配检查，定向到对应的 Pool

如果 iRule 下未匹配，则会控制 vs 下绑定的 Polices 规则进行匹配

在上篇中，我们知道 Openshift 上的 F5 控制器会自动在 F5 上生成 Polices 规则，来满足 Openshift Route 的功能。那么只需要将它与自定义的 iRule 结合就能够实现既满足服务的分流，又能控制用户对服务的定向访问。

F5 与 Openshift 集成配置与部署（实现灰度发布）

准备工作（详细见上篇：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。

上述就是丸趣 TV 小编为大家分享的 F5 与 Openshift 集成怎么实现灰度发布了，如果刚好有类似的疑惑，不妨参照上述分析进行理解。如果想知道更多相关知识，欢迎关注丸趣 TV 行业资讯频道。