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上端的负载均衡地址。