Router vs Route详解 route和router的区别是什么( 三 )


因此,OpenShift 的路由器功能需要能对这三部分进行管理和控制 。
2.3 全局配置管理
要指定或修改 HAProxy 的全局配置,OpenShift 有提供两种方式:
(1)第一种是使用 oc adm router 命令在创建 router 时候指定各种参数,比如 --max-connections 用于设置最大连接数 。比如:
oc adm router --max-connections=200000 --ports='81:80,444:443' router3
创建出来的HAProxy 的 maxconn 将是 20000,router3 这个服务对外暴露出来的端口是 81 和 444,但是 HAProxy pod 的端口依然是 80 和 443.
(2)通过设置 dc/ 的环境变量来设置 router 的全局配置 。
在官方文档 https://docs.openshift.com/container-platform/3.4/architecture/core_concepts/routes.html#haproxy-template-router 中有完整的环境变量列表 。比如运行以下命令后,
oc set env dc/router3 ROUTER_SERVICE_HTTPS_PORT=444 ROUTER_SERVICE_HTTP_PORT=81 STATS_PORT=1937
router3 会重新部署,新部署的HAProxy 的 https 监听端口是 444,http 监听端口是 80,统计端口是 1937.
2.4 OpenShift passthrough 类型的 route 与 HAProxy backend
(1)通过OpenShift Console 或者 oc 命令创建一条 route,它将 sit 项目的 jenkins 服务暴露到域名 sitjenkins.com.cn:
在界面上创建 route:

Router vs Route详解 route和router的区别是什么



Router vs Route详解 route和router的区别是什么


结果:
Name: sitjenkins.com.cnNamespace: sitLabels: app=jenkins-ephemeral template=jenkins-ephemeral-templateAnnotations: Requested Host: sitjenkins.com.cnPath: TLS Termination: passthroughEndpoint Port: webService: jenkinsWeight: 100 (100%)Endpoints: 10.128.2.15:8080, 10.131.0.10:8080
【Router vs Route详解 route和router的区别是什么】这里,service name 起了一个中介作用,把 route 和服务的端点(也就是pod)连接了起来 。
(2)router 服务的两个 pod 中的 HAProxy 进程的配置文件中多了一个backend:
# Secure backend, pass throughbackend be_tcp:sit:sitjenkins.com.cn balance source hash-type consistent timeout check 5000ms} server pod:jenkins-1-bqhfj:jenkins:10.128.2.15:8080 10.128.2.15:8080 weight 256 check inter 5000ms server pod:jenkins-1-h2fff:jenkins:10.131.0.10:8080 10.131.0.10:8080 weight 256 check inter 5000ms
其中,这些后端 server 其实就是 pod,它们是 openshift 通过步骤(1)中的 service name 找到的 。balance 是负载均衡策略,后文会解释 。
(3)文件
/var/lib/haproxy/conf/os_sni_passthrough.map 中多了一条记录
sh-4.2$ cat /var/lib/haproxy/conf/os_sni_passthrough.map^sitjenkins\.com\.cn(:[0-9]+)?(/.*)?$ 1
(4)文件
/var/lib/haproxy/conf/os_tcp_be.map 中多了一条记录
sh-4.2$ cat /var/lib/haproxy/conf/os_tcp_be.map^sitjenkins\.com\.cn(:[0-9]+)?(/.*)?$ be_tcp:sit:sitjenkins.com.cn
(5)HAProxy 根据上面的 map 文件为该条 route 选择第(2)步中增加的 backend的逻辑如下
frontend public_ssl #解释:前端协议 https, bind :443 ##前端端口 443 tcp-request inspect-delay 5s tcp-request content accept if { req_ssl_hello_type 1 } # if the connection is SNI and the route is a passthrough don't use the termination backend, just use the tcp backend # for the SNI case, we also need to compare it in case-insensitive mode (by converting it to lowercase) as RFC 4343 says acl sni req.ssl_sni -m found ##检查 https request 支持 sni acl sni_passthrough req.ssl_sni,lower,map_reg(/var/lib/haproxy/conf/os_sni_passthrough.map) -m found ##检查通过 sni 传来的 hostname 在 os_sni_patthrough.map 文件中 use_backend %[req.ssl_sni,lower,map_reg(/var/lib/haproxy/conf/os_tcp_be.map)] if sni sni_passthrough ##从 oc_tcp_be.map 中根据 sni hostname 获取 backend name # if the route is SNI and NOT passthrough enter the termination flow use_backend be_sni if sni # non SNI requests should enter a default termination backend rather than the custom cert SNI backend since it # will not be able to match a cert to an SNI host default_backend be_no_sni

推荐阅读