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对应生产环境
[root@master 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 [root@master 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
然后确保启动成功
[root@master ~]# 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打标签
[root@master openshift-ansible]# oc new-project project-1 Now using project "project-1" on server "https://master.example.com:8443". [root@master ~]# oc label namespace project-1 router=prod namespace/project-1 labeled
部署应用，并建立Route，发现Project1下建立的route自动带有apps-prod.example.com的域名
建立一个project-2用于开发环境dev，同时给project-2打标签
[root@master openshift-ansible]# oc new-project project-2 Now using project "project-2" on server "https://master.example.com:8443". [root@master ~]# 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具备这种负载分区的策略，可以比较灵活的规划Router的分布
相对的，也可以基于两种模式对Router暴露出去的域名进行规划。
- 规划方案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上端的负载均衡地址。
