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
Openshift -
建立一個VXLAN profile
F5 -
建立一個VXLAN Tunnel
F5 -
在每個F5裝置VXLAN中建立Self IP
F5 -
在當前主F5裝置的VXLAN下建立Floating IP
F5 -
建立一個新的Partition
F5 -
建立訪問F5 BIG-IP的私鑰
Openshift -
建立RBAC認證
Openshift
說明:以上操作具體步驟參考
上篇
手動建立VS（HTTP、HTTPS）
F5
-
Local Traffic -> Virtual Servers選中指定的Partition，新建VS -
HTTP
-
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
目的：修改cccl-whitelist的值為1，是為了防止當openshift建立控制器時，route模式下將VS原本的配置覆蓋掉
tmsh
cd /f5-openShift (openshift所在的partition)
modify ltm virtual testroute metadata add { cccl-whitelist { value 1 } }
modify ltm virtual testroute_https metadata add { cccl-whitelist { value 1 } }
建立F5控制器
Openshift
-
對應每臺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 # "--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 # "--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
F5
-
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。
（本文轉自 大魏分享 微信訂閱號）
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/31547898/viewspace-2186757/，如需轉載，請註明出處，否則將追究法律責任。
相關文章
- nginx 實現實用的灰度釋出Nginx
- 如何實現灰度釋出輕量化？
- nginx+lua+redis實現灰度釋出NginxRedis
- 乾貨分享｜使用 Istio 實現灰度釋出
- 使用 Nginx Ingress 實現金絲雀釋出/灰度釋出Nginx
- 如何用istio實現應用的灰度釋出
- 阿里雲基於ALB實現灰度釋出阿里
- 一鍵實現自動化部署（灰度釋出）實踐
- 分散式全鏈路灰度釋出的探索與實踐分散式
- 架構設計：微服務模式下，實現灰度釋出模式架構微服務模式
- Kubernetes 使用 Ingress-nginx 實現灰度釋出功能Nginx
- 灰度釋出的一種技術實踐
- Vue + Webpack 灰度釋出控制VueWeb
- 大規模微服務場景下灰度釋出與流量染色實踐微服務
- CODING DevOps + Nginx-ingress 實現自動化灰度釋出devNginx
- 微服務部署之藍綠髮布、滾動釋出、灰度釋出區別與特點微服務
- GitLab整合kubernetes實現自動釋出Gitlab
- 基於 Istio 的灰度釋出架構方案實踐之路架構
- 一文搞懂灰度釋出與 AB Test 的聯絡與區別
- Openshift-F5整合（總結）——與Router方案對比
- nginx 根據IP 進行灰度釋出Nginx
- 手把手教你在 TKE 叢集中實現簡單的藍綠髮布和灰度釋出
- 關於灰度釋出，你得知道這些......
- k8s-服務網格實戰-配置 Mesh（灰度釋出）K8S
- 技術乾貨 | AB測試和灰度釋出探索及實踐
- Redis(設計與實現):---釋出與訂閱介紹Redis
- Redis 設計與實現 （六）--釋出訂閱Redis
- [原創]淺談我們需要灰度釋出嗎？
- Knativa 基於流量的灰度釋出和自動彈性實踐
- 【Spring Cloud】Eureka實現微服務釋出與呼叫SpringCloud微服務
- SpringCloud 應用在 Kubernetes 上的最佳實踐 — 線上釋出（可灰度）SpringGCCloud
- 基於DotNetty實現自動釋出 - 實現一鍵打包釋出Netty
- 手把手教你搭建一個灰度釋出環境
- Spring Cloud Alibaba Nacos 之 灰度釋出(思路分享)SpringCloud
- 《前端運維》五、k8s--3灰度釋出、滾動更新與探針前端運維K8S
- SOFARPC 5.5.X 新版釋出 | 整合 Nacos 與 HystrixRPC
- 【Nginx】實現負載均衡、限流、快取、黑白名單和灰度釋出，這是最全的一篇了！Nginx負載快取
- 01 . OpenResty簡介部署,優缺點,壓測,適用場景及用Lua實現服務灰度釋出REST