OpenShift負載分割槽策略(Router Shading)
在很多場景下，單靠幾個在Infra節點上的Router進行服務請求的轉發是不夠的，專案中很多時候都有流量隔離的需求，主要場景在於：
- 一個叢集中的不同的環境的流量隔離需求，比如開發走幾個Router,生產走另外幾個Router.
- 不同專案的流量不希望相互影響,希望保持獨立
- 為保證關鍵服務的SLA,需要單獨的流量入口
Openshift叢集支援大規模節點環境部署，這種環境下做負載的分割槽就很有必要了。因為所有的流量集中在幾個Infra節點上，效能
和擴充套件性都有問題。Openshift的Router提供了Shading的功能，下面我們來看看具體的實現
1.Router Shading的架構
2.前端負載均衡說明
在Router節點前端應有F5或者軟體負載均衡器，根據域名進行路由到不同的router
Router部署不一定部署在infra節點上，Router部署以後採用hostnetwork繫結宿主機的IP和埠。
| 域名 |
負載均衡vip |
Router IP |
| apps-prod.example.com |
10.30.0.33（舉例） |
192.168.56.106 |
|
|
|
192.168.56.104(暫時沒有) |
| apps-dev.example.com |
10.30.0.35 |
192.168.56.103 |
3.建立Router
開啟繫結主機網路許可權
oc adm policy add-scc-to-user hostnetwork -z router
建立router-dev,對應開發環境，建立router-prod對應生產環境
[[email protected] openshift-ansible]# oc adm router router-dev --replicas=1 --force-subdomain='${name}-${namespace}.apps-dev.example.com' info: password for stats user admin has been set to gGaytR7cPj --> Creating router router-dev ... warning: serviceaccounts "router" already exists warning: clusterrolebindings.authorization.openshift.io "router-router-dev-role" already exists deploymentconfig.apps.openshift.io "router-dev" created service "router-dev" created --> Success [[email protected] openshift-ansible]# oc adm router router-prod --replicas=1 --force-subdomain='${name}-${namespace}.apps-prod.example.com' info: password for stats user admin has been set to 49wuWv7F6O --> Creating router router-prod ... warning: serviceaccounts "router" already exists warning: clusterrolebindings.authorization.openshift.io "router-router-prod-role" already exists deploymentconfig.apps.openshift.io "router-prod" created service "router-prod" created --> Success
設定標籤繫結Router和相應的節點
給Router設定namespace_label.
oc set env dc/router-prod NAMESPACE_LABELS="router=prod" oc set env dc/router-dev NAMESPACE_LABELS="router=dev" oc label node node3.example.com "router=prod" oc label node master.example.com "router=dev"
編輯router dc的node-selector
oc edit dc/router-dev -n default 在spec->template->spec下 新增 nodeSelector: router: dev oc edit dc/router-prod -n default 在spec->template->spec下 新增 nodeSelector: router: prod
然後確保啟動成功
[[email protected] ~]# oc get pods -n default -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE docker-registry-1-q5t5m 1/1 Running 1 22d 10.130.1.110 node1.example.com <none> registry-console-1-8m2mq 1/1 Running 20 25d 10.128.0.122 master.example.com <none> router-2-w7bgw 1/1 Running 1 22d 192.168.56.104 node1.example.com <none> router-dev-4-srvcz 1/1 Running 1 3h 192.168.56.103 master.example.com <none> router-prod-4-vx8bw 1/1 Running 0 1m 192.168.56.106 node3.example.com <none>
4.建立專案及應用
建立一個專案project-1用於生產環境prod,同時給project-1打標籤
[[email protected] openshift-ansible]# oc new-project project-1 Now using project "project-1" on server "https://master.example.com:8443". [[email protected] ~]# oc label namespace project-1 router=prod namespace/project-1 labeled
部署應用，並建立Route，發現Project1下建立的route自動帶有apps-prod.example.com的域名
建立一個project-2用於開發環境dev，同時給project-2打標籤
[[email protected] openshift-ansible]# oc new-project project-2 Now using project "project-2" on server "https://master.example.com:8443". [[email protected] ~]# oc label namespace project-2 router=dev namespace/project-2 labeled
部署應用，並建立Route
5.訪問驗證
因沒有負載均衡器，在hosts檔案中設定
192.168.56.106 tomcat-project-1.apps-prod.example.com 192.168.56.103 project2tomcat-project-2.apps-dev.example.com
指到正確的Router節點所在的node ip,應用能夠正常訪問
修改192.168.56.106為192.168.56.103或者其他router所在節點， 讓請求路由到其他的Router節點，訪問失敗
6.域名規劃
鑑於OpenShift具備這種負載分割槽的策略，可以基於兩種模式對域名進行規劃。
- 規劃方案1:
- 不同的資料中心成為二級域名，或者分地域，如dc1.a.com, dc2.a.com
- 在資料中心上基於應用規劃三級域名，如app1.dc1.a.com, app3.dc2.a.com
- 應用提供的對外服務為 service1.app1.dc1.a.com, service2.app1.dc1.a.com
- 規劃方案2:
- 直接以應用作為二級域名，如app1.a.com, app2.a.com
- 應用提供的對外服務為 service1.app1.a.com, service2.app1.a.com
無論那種模式，都需要相應的域名，如app1.dc1.a.com或app1.a.com,對應上端的負載均衡地址存在於DNS解析記錄。也就是DNS將最後的域名解析為OpenShift上Router上端的負載均衡地址。