** 本文基于 OpenShift 3.11，Kubernetes 1.11 進(jìn)行測(cè)試 ***

成都創(chuàng)新互聯(lián)公司是一家朝氣蓬勃的網(wǎng)站建設(shè)公司。公司專注于為企業(yè)提供信息化建設(shè)解決方案。從事網(wǎng)站開(kāi)發(fā)，網(wǎng)站制作，網(wǎng)站設(shè)計(jì)，網(wǎng)站模板，微信公眾號(hào)開(kāi)發(fā)，軟件開(kāi)發(fā)，小程序制作，十載建站對(duì)生料攪拌車等多個(gè)方面，擁有多年的網(wǎng)站推廣經(jīng)驗(yàn)。

1. OpenShift 為什么需要 Router 和 Route？

顧名思義，Router 是路由器，Route 是路由器中配置的路由。OpenShift 中的這兩個(gè)概念是為了解決從集群外部（就是從除了集群節(jié)點(diǎn)以外的其它地方）訪問(wèn)服務(wù)的需求。不曉得為什么OpenShift 要將Kubernetes 中的 Ingress 改為 Router，我倒是覺(jué)得 Ingress 名字更貼切。

從外部通過(guò) router 和從內(nèi)部通過(guò) servide 訪問(wèn) pod 中的應(yīng)用兩個(gè)過(guò)程的簡(jiǎn)單的示意圖如下：

上圖中，某個(gè)應(yīng)用的三個(gè)pod 分別位于 node1，node2 和 node3 上。OpenShift 中有三層IP地址概念：

• pod 自己的 IP 地址，可以類比為 OpenStack 中虛擬機(jī)的固定IP。它只有在集群內(nèi)才有意義。

• service 的 IP 地址。Service 通常有 ClusterIP，這也是一種集群內(nèi)部的IP 地址。

• 應(yīng)用的外部 IP 地址，可以類比為OpenStack 中的浮動(dòng)IP，或者IDC IP（和浮動(dòng)IP 之間是NAT 映射關(guān)系）。

因此，要從集群外部訪問(wèn) pod 中的應(yīng)用，無(wú)非兩種方式：

• 一種是利用一個(gè)代理（proxy），把外部 IP 地址轉(zhuǎn)化為后端的 Pod IP 地址。這就是 OpenShift router/route 的思路。OpenShift 中的 router 服務(wù)，是一個(gè)運(yùn)行在特定節(jié)點(diǎn)（通常是基礎(chǔ)架構(gòu)節(jié)點(diǎn)）上的集群基礎(chǔ)服務(wù)，由集群管理員負(fù)責(zé)創(chuàng)建和管理。它可以有多個(gè)副本（pod）。router 中可有多個(gè) route，每個(gè) route 能通過(guò)外部HTTP 請(qǐng)求的域名找出其后端的 pod 列表，并進(jìn)行網(wǎng)絡(luò)包的轉(zhuǎn)發(fā)。也就是將pod 中的應(yīng)用暴露到外網(wǎng)域名，使得用戶可以外面通過(guò)域名訪問(wèn)到應(yīng)用。這實(shí)際上是一種七層負(fù)載均衡器。OpenShift 默認(rèn)采用 HAProxy 來(lái)實(shí)現(xiàn)，當(dāng)然也支持其它實(shí)現(xiàn)，比如 F5.

• 另一種是將服務(wù)直接暴露到集群外。這種方式具體會(huì)在『服務(wù) Service』那一篇文章中詳細(xì)解釋。

2. OpenShift 如何利用 HAProxy 實(shí)現(xiàn) router 和 route？

2.1 Router 部署

使用 ansible 采用默認(rèn)配置部署 OpenShift 集群時(shí)，在集群 Infra 節(jié)點(diǎn)上，會(huì)以 Host networking 方式運(yùn)行一個(gè) HAProxy 的 pod，它會(huì)在所有網(wǎng)卡的 80 和 443 端口上進(jìn)行監(jiān)聽(tīng)。

[root@infra-node3 cloud-user]# netstat -lntp | grep haproxy
tcp        0      0 127.0.0.1:10443         0.0.0.0:*               LISTEN      583/haproxy         
tcp        0      0 127.0.0.1:10444         0.0.0.0:*               LISTEN      583/haproxy         
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      583/haproxy         
tcp        0      0 0.0.0.0:443             0.0.0.0:*               LISTEN      583/haproxy

其中，172.0.0.1 上的 10443 和 10444 是HAproxy 自己使用的。下文會(huì)有解釋。

因此，在每個(gè) infra 節(jié)點(diǎn)上，只能有一個(gè) HAProxy pod，因?yàn)檫@些端口只能被占用一次。如果調(diào)度器找不到滿足要求的節(jié)點(diǎn)，則router 服務(wù)的調(diào)度就會(huì)失敗：

0/7 nodes are available: 2 node(s) didn't have free ports for the requested pod ports, 5 node(s) didn't match node selector

OpenShift HAProxy Router 支持兩種部署方式：

• 一種是常見(jiàn)的單Router 服務(wù)部署，它有一個(gè)或多個(gè)實(shí)例（pod），分布在多個(gè)節(jié)點(diǎn)上，負(fù)責(zé)整個(gè)集群上部署的服務(wù)的對(duì)外訪問(wèn)。

• 另一種是分片（sharding）部署。此時(shí)，會(huì)有多個(gè) Router 服務(wù)，每個(gè)Router 服務(wù)負(fù)責(zé)指定的若干project，兩者之間采用標(biāo)簽（label）進(jìn)行映射。這是為了解決單個(gè) Router 的性能不夠問(wèn)題而提出的解決方案。

OpenShift 提供了 oc adm router 命令來(lái)創(chuàng)建 router 服務(wù)。

創(chuàng)建router：

[root@master1 cloud-user]# oc adm router router2 --replicas=1 --service-account=routerinfo: password for stats user admin has been set to J3YyPjlbqf--> Creating router router2 ...
    warning: serviceaccounts "router" already exists
    clusterrolebinding.authorization.openshift.io "router-router2-role" created
    deploymentconfig.apps.openshift.io "router2" created
    service "router2" created--> Success

詳細(xì)的部署方法請(qǐng)參見(jiàn)官方文檔 https://docs.openshift.com/container-platform/3.11/install_config/router/default_haproxy_router.html。

2.2 Router pod 中的 HAProxy 進(jìn)程

在 Router 服務(wù)的每個(gè) pod 之中，openshift-router 進(jìn)程啟動(dòng)了一個(gè) haproy 進(jìn)程：

UID        PID  PPID  C STIME TTY          TIME CMD1000000+     1     0  0 Nov21 ?        00:14:27 /usr/bin/openshift-router1000000+ 16011     1  0 12:42 ?        00:00:00 /usr/sbin/haproxy -f /var/lib/haproxy/conf/haproxy.config -p /var/lib/haproxy/run/haproxy.pid -x /var/lib/haproxy/run/haproxy.sock -sf 16004

查看 haproxy 使用的配置文件（只是部分）：

-base /etc/-base /etc/-forwarded-.: /var/lib/haproxy/conf/error-page---keep--request inspect--request content accept -uri /
  http-request del- insensitive (RFC ), we need to convert the -request set-header Host % we need to redirect//var/lib/haproxy/conf/os_route_http_redirect.map) -%[base,map_reg(/var/lib/haproxy/conf/# determined by the next backend  the chain -request  inspect--request content accept  { req_ssl_hello_type  the connection is SNI and the route is a passthrough don
  #  the SNI , we also need to compare it  -insensitive mode (by converting it to lowercase) as RFC -/var/lib/haproxy/conf/os_sni_passthrough.map) -%[req.ssl_sni,lower,map_reg(/var/lib/haproxy/conf/os_tcp_be.map)] -request set-header X-Forwarded-Host %-request set-header X-Forwarded-Port %-request set-header X-Forwarded-Proto http  !-request set-header X-Forwarded-Proto https -request set-header X-Forwarded-Proto-Version h3  { ssl_fc_alpn --request add-header Forwarded =%[src];host=%[req.hdr(host)];proto=%[req.hdr(X-Forwarded-Proto)];proto-version=%[req.hdr(X-Forwarded-Proto---84nrt:jenkins:.: .: cookie 8669a19afc9f0fed6824feb9fb1cf4ac weight

為了簡(jiǎn)單期間，上面只是配置文件的部分內(nèi)容，它主要包括三種類型：

• 全局配置，比如大連接數(shù) maxconn，超時(shí)時(shí)間 timeout 等；以及front部分，即前端配置，HAProxy 默認(rèn)會(huì)在 443 和 80 兩個(gè)端口上分別監(jiān)聽(tīng)外部 https 和 http 請(qǐng)求。

• backend，即每個(gè)服務(wù)的后端配置，里面有很多關(guān)鍵內(nèi)容，比如后端協(xié)議（mode）、負(fù)載均衡方法（balance）、后端列表（server，這里是pod，包括其IP 地址和端口）、證書(shū)等。

因此，OpenShift 的路由器功能需要能對(duì)這三部分進(jìn)行管理和控制。

關(guān)于負(fù)載均衡器和 HAProxy 的詳細(xì)介紹，可以參考 Neutron 理解 (7): Neutron 是如何實(shí)現(xiàn)負(fù)載均衡器虛擬化的 這篇文章。

2.3 全局配置管理

要指定或修改 HAProxy 的全局配置，OpenShift 有提供兩種方式：

（1）第一種是使用 oc adm router 命令在創(chuàng)建 router 時(shí)候指定各種參數(shù)，比如 --max-connections 用于設(shè)置大連接數(shù)。比如：

oc adm router --max-connections=200000 --ports='81:80,444:443' router3

創(chuàng)建出來(lái)的HAProxy 的 maxconn 將是 20000，router3 這個(gè)服務(wù)對(duì)外暴露出來(lái)的端口是 81 和 444，但是 HAProxy pod 的端口依然是 80 和 443.

（2）通過(guò)設(shè)置 dc/ 的環(huán)境變量來(lái)設(shè)置 router 的全局配置。

在官方文檔 https://docs.openshift.com/container-platform/3.4/architecture/core_concepts/routes.html#haproxy-template-router 中有完整的環(huán)境變量列表。比如運(yùn)行以下命令后，

 oc set env dc/router3 ROUTER_SERVICE_HTTPS_PORT=444 ROUTER_SERVICE_HTTP_PORT=81 STATS_PORT=1937

router3 會(huì)重新部署，新部署的HAProxy 的 https 監(jiān)聽(tīng)端口是 444，http 監(jiān)聽(tīng)端口是 80，統(tǒng)計(jì)端口是 1937.

2.4 OpenShift passthrough 類型的 route 與 HAProxy backend

（1）通過(guò)OpenShift Console 或者 oc 命令創(chuàng)建一條 route，它將 sit 項(xiàng)目的 jenkins 服務(wù)暴露到域名 sitjenkins.com.cn：

在界面上創(chuàng)建 route：

結(jié)果：

Name:                   sitjenkins.com.cn
Namespace:              sitLabels:                 app=jenkins-ephemeral
                        template=jenkins-ephemeral-template
Annotations:            Requested Host:         sitjenkins.com.cnPath:                   TLS Termination:        passthroughEndpoint Port:          web

Service:        jenkins
Weight:         100 (100%)
Endpoints:      10.128.2.15:8080, 10.131.0.10:8080

這里，service name 起了一個(gè)中介作用，把 route 和服務(wù)的端點(diǎn)（也就是pod）連接了起來(lái)。

（2）router 服務(wù)的兩個(gè) pod 中的 HAProxy 進(jìn)程的配置文件中多了一個(gè)backend：

# Secure backend, pass through
backend 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-h3fff:jenkins:10.131.0.10:8080 10.131.0.10:8080 weight 256 check inter 5000ms

其中，這些后端 server 其實(shí)就是 pod，它們是 openshift 通過(guò)步驟（1）中的 service name 找到的。balance 是負(fù)載均衡策略，后文會(huì)解釋。

（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 根據(jù)上面的 map 文件為該條 route 選擇第（2）步中增加的 backend的邏輯如下

frontend public_ssl  #解釋：前端協(xié)議 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 ##檢查通過(guò) sni 傳來(lái)的 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 中根據(jù) 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

（6）HAPorxy 進(jìn)程會(huì)重啟，從而應(yīng)用修改了的配置文件。

理解（5）中的腳本需要的一些背景知識(shí)：

• SNI：TLS Server Name Indication (SNI) ，這是 TLS 網(wǎng)絡(luò)協(xié)議的一種擴(kuò)展，會(huì)在 TLS 握手前由客戶端（client）告知服務(wù)器端（server）它將會(huì)連接的域名（hostname），使得服務(wù)器端可以根據(jù)該hostname 向客戶端段返回指定的證書(shū)，從而使得服務(wù)器端能夠支持多個(gè)hostname 需要的多個(gè)證書(shū)。詳情請(qǐng)參閱 https://en.wikipedia.org/wiki/Server_Name_Indication。

• OpenShift passthrough route：這種 route 的 SSL 連接不會(huì)在 router 上被 TLS 終止（termination），而是router 會(huì)將 TLS 鏈接透?jìng)鞯胶蠖?。下文有解釋?/p>

• HAProxy 對(duì) SNI 的支持：HAProxy 會(huì)根據(jù) SNI 的信息中的 hostname 去選擇特定的 backend。詳情請(qǐng)參閱 https://www.haproxy.com/blog/enhanced-ssl-load-balancing-with-server-name-indication-sni-tls-extension/。

• HAProxy ACL：詳情請(qǐng)參閱 https://www.haproxy.com/documentation/aloha/10-0/traffic-management/lb-layer7/acls/

從上面的藍(lán)色注釋中，我們能看到 HAProxy 進(jìn)程通過(guò) https 請(qǐng)求中通過(guò) SNI 傳入的域名 sitjenkins.com.cn ，在 os_tcp_be.map 文件中獲取到了 backend 名稱 be_tcp:sit:sitjenkins.com.cn，這樣就和（2）步驟中的 backend 對(duì)應(yīng)上了。

OpenShift 的 router 使用的 HAProxy 采用基于域名的負(fù)載均衡路由方式，示例如下，具體說(shuō)明請(qǐng)參加官方文檔。

2.5 OpenShift edge 和 re-encrypt 類型的 route 與 HAProxy

HAProxy 前端：前端依然是在 443 端口監(jiān)聽(tīng)外部 HTTPS 請(qǐng)求

 sni

但是，當(dāng) TLS 終止類型不是 passthrough （edge 或者 re-encrypt）時(shí)，會(huì)使用backend be_sni。

backend be_sni
  server fe_sni 127.0.0.1:10444 weight 1 send-prox

而這個(gè)后端是由本機(jī)的 127.0.0.1:10444 提供服務(wù)，因此又轉(zhuǎn)到了前端 fe_sni：

frontend fe_sni
  # terminate ssl on edge
  bind 127.0.0.1:10444 ssl no-sslv3 crt /var/lib/haproxy/router/certs/default.pem crt-list /var/lib/haproxy/conf/cert_config.map accept-proxy
  mode http。。。。。。

  # map to backend
  # Search from most specific to general path (host case).
  # Note: If no match, haproxy uses the default_backend, no other
  #       use_backend directives below this will be processed.
  use_backend %[base,map_reg(/var/lib/haproxy/conf/os_edge_reencrypt_be.map)]

  default_backend openshift_default

map 映射文件：

sh-4.2$ cat /var/lib/haproxy/conf/os_edge_reencrypt_be.map^edgejenkins\.com\.cn(:[0-9]+)?(/.*)?$ be_edge_http:sit:jenkins-edge

Edge 類型 route 的 HAProxy 后端：

backend be_edge_http:sit:jenkins-edge
  mode http
  option redispatch
  option forwardfor
  balance leastconn

  timeout check 5000ms
  .....
  server pod:jenkins-1-bqhfj:jenkins:10.128.2.15:8080 10.128.2.15:8080 cookie 71c6bd03732fa7da2f1b497b1e4c7993 weight 256 check inter 5000ms
  server pod:jenkins-1-h3fff:jenkins:10.131.0.10:8080 10.131.0.10:8080 cookie fa8d7fb72a46958a7add1406e6d26cc8 weight 256 check inter 5000ms

Re-encrypt 類型 route 的 HAProxy 后端：

-

http-request set-header X-Forwarded-Host %[req.hdr(host)]
http-request set-header X-Forwarded-Port %[dst_port]
http-request set-header X-Forwarded-Proto http if !{ ssl_fc }
http-request set-header X-Forwarded-Proto https if { ssl_fc }
http-request set-header X-Forwarded-Proto-Version h3 if { ssl_fc_alpn -i h3 }

  server pod:jenkins-1-bqhfj:jenkins:10.128.2.15:8080 10.128.2.15:8080 cookie ... weight 256 ssl verifyhost jenkins.sit.svc verify required ca-file /var/run/secrets/kubernetes.io/serviceaccount/service-ca.crt check inter 5000ms #與后端的鏈路采用 ssl 加密，并且要檢查hostname
  server pod:jenkins-1-h3fff:jenkins:10.131.0.10:8080 10.131.0.10:8080 cookie ... weight 256 ssl verifyhost jenkins.sit.svc verify required ca-file /var/run/secrets/kubernetes.io/serviceaccount/service-ca.crt check inter 5000ms

這里可以看出來(lái)重新使用密鑰對(duì)連接進(jìn)行加密，但是不知道為何 mode 依然是 http，而不是 https。

2.6 設(shè)置和修改 route 配置

route 配置主要有以下幾個(gè)比較重要的：

（1）SSL 終結(jié)方式。共三種：

• edge：TLS 在 router 上被終結(jié)，然后非SSL網(wǎng)絡(luò)包被轉(zhuǎn)發(fā)給后端 pod。因此需要在 router 上安裝 TLS 證書(shū)。不安裝的話，會(huì)使用 router 的默認(rèn)證書(shū)。

• passthrough：加密網(wǎng)絡(luò)包直接被發(fā)給 pod，router 上不做TLS 終結(jié)，因?yàn)椴恍枰?router 上配置證書(shū)或密鑰。

• Re-encryption：是 edge 的一種變種。首先 router 上會(huì)使用一個(gè)證書(shū)做 TSL 終結(jié)，然后使用另外的證書(shū)再進(jìn)行加密，然后發(fā)給后端 pod。因此，整個(gè)網(wǎng)絡(luò)路徑都是加密的。

設(shè)置：

• 可以在創(chuàng)建 route 時(shí)設(shè)置，也可以通過(guò)修改 route 的 termination 配置項(xiàng)來(lái)修改其 SSL 終結(jié)方式。

• 具體請(qǐng)參考官方文檔 https://docs.okd.io/latest/architecture/networking/routes.html#edge-termination

（2）負(fù)載均衡策略。也有三種：

• roundrobin：根據(jù)權(quán)重輪流使用所有后端。

• leastconn：選擇最少連接的后端接收請(qǐng)求。

• source：將源IP進(jìn)行哈希，確保來(lái)自同一個(gè)源IP的請(qǐng)求發(fā)給同一個(gè)后端。

設(shè)置：

• 要修改整個(gè) router 的負(fù)載均衡策略，可使用 ROUTER_TCP_BALANCE_SCHEME 環(huán)境變量，為該 router 的所有 passthrough 類型的 route設(shè)置負(fù)載均衡策略，使用 ROUTER_LOAD_BALANCE_ALGORITHM 為其它類型的 route 設(shè)置策略。

• 可以使用 haproxy.router.openshift.io/balance 為某個(gè) route 設(shè)置負(fù)載均衡策略。

舉例：

• 設(shè)置整個(gè) router 的環(huán)境變量：oc set env dc/router ROUTER_TCP_BALANCE_SCHEME=roundrobin.改完以后，該 router 實(shí)例會(huì)重新部署，所有 passthrough 的 route 都是 roundrobin 類型的了。默認(rèn)為 source 類型。

• 修改某個(gè) route 的負(fù)載均衡的策略：oc edit route aaaa.svc.cluster.local.修改完成后，HAProxy 中對(duì)應(yīng)該 route 的 backend 中的 balance 值會(huì)被修改為 leastconn。

2.7 一個(gè) route 將流量分給多個(gè)后端服務(wù)

該功能常用于一些開(kāi)發(fā)測(cè)試流程，比如做A/B 測(cè)試。

在下面的配置中，有一個(gè)應(yīng)用三個(gè)版本的部署，前端一個(gè) route，各服務(wù)使用不同的權(quán)重。

下面是 HAProxy 配置文件中的 backend 配置，采用 roundrobin 負(fù)載均衡模式：

3. OpenShift router 服務(wù)如何實(shí)現(xiàn)高可用？

OpenShift router 服務(wù)支持兩種高可用模式。

3.1 單 router 服務(wù)多副本，并利用和DNS/LB 實(shí)現(xiàn)高可用

這種模式只部署一個(gè) router 服務(wù)，它支持集群的所有對(duì)外暴露的服務(wù)。要實(shí)現(xiàn)HA，需要設(shè)置副本數(shù)（replicas）大于1，使得會(huì)在超過(guò)一臺(tái)服務(wù)器上創(chuàng)建pod，然后再通過(guò)DNS輪詢或者四層負(fù)載均衡。

因?yàn)?router/pod 中的 HAProxy 要實(shí)現(xiàn)本地配置文件，因此實(shí)際上它們是有狀態(tài)容器。OpenShift 采用 etcd 作為配置的統(tǒng)一存儲(chǔ)，openshift-router 進(jìn)程應(yīng)該是采取某種機(jī)制（被通知或定時(shí)拉?。?etcd 中獲取 router 和 route 的配置，然后再修改本地的配置文件，再重啟 HAPorxy 進(jìn)程來(lái)應(yīng)用新修改了的配置文件。 要深入了解這里面的工作原理，可以去看源代碼。

3.2 多 router 服務(wù)通過(guò)分片（sharding）實(shí)現(xiàn)高可用

這種模式下，管理員需要?jiǎng)?chuàng)建和部署多個(gè) router 服務(wù)，每個(gè)router 服務(wù)支持一個(gè)或幾個(gè) project/namespace。router 和 project/namespace 之間的映射使用標(biāo)簽（label）來(lái)實(shí)現(xiàn)。具體的配置請(qǐng)參考官網(wǎng) https://docs.openshift.com/container-platform/3.11/install_config/router/default_haproxy_router.html。實(shí)際上，和一些產(chǎn)品（比如mysql，memedcache）的分片功能類似，該功能更多地是為了解決性能問(wèn)題，而無(wú)法完全解決高可用問(wèn)題。

4. 常見(jiàn)問(wèn)題如何排查？

從上面的分析可以看出，要使得 router 和 route 都正常工作，至少要確保以下幾個(gè)環(huán)節(jié)都是沒(méi)問(wèn)題的：

1. 客戶端使用 route 中配置的域名和端口來(lái)訪問(wèn)服務(wù)。

2. DNS 能將域名解析到目標(biāo) router 所在的服務(wù)器（在使用分片配置時(shí)比較復(fù)雜，尤其需要注意）。

3. 如有采用另外的四層負(fù)載均衡器的話，它得配置正確、工作正常。

4. HAProxy 能通過(guò)域名匹配到正確的backend。

5. router 和 route 的配置被正確地反映到了 HAProxy 的配置文件中了。

6. HAProxy 進(jìn)程重啟了，從而讀取了新修改的配置文件。

7. 后端 pod 列表正確，并且至少有一個(gè) pod 正常工作。

如果您看到如下的錯(cuò)誤頁(yè)面，則說(shuō)明上面的第3到7點(diǎn)至少有一處不能正常功能。此時(shí)，進(jìn)行有針對(duì)性的排查即可。

另外有需要云服務(wù)器可以了解下創(chuàng)新互聯(lián)cdcxhl.cn，海內(nèi)外云服務(wù)器15元起步，三天無(wú)理由+7*72小時(shí)售后在線，公司持有idc許可證，提供“云服務(wù)器、裸金屬服務(wù)器、高防服務(wù)器、香港服務(wù)器、美國(guó)服務(wù)器、虛擬主機(jī)、免備案服務(wù)器”等云主機(jī)租用服務(wù)以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡(jiǎn)單易用、服務(wù)可用性高、性價(jià)比高”等特點(diǎn)與優(yōu)勢(shì)，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應(yīng)用場(chǎng)景需求。

網(wǎng)頁(yè)標(biāo)題：理解OpenShift（1）：網(wǎng)絡(luò)之Router和Route-創(chuàng)新互聯(lián)
文章分享：http://www.sd-ha.com/article0/ejhio.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供品牌網(wǎng)站設(shè)計(jì)、網(wǎng)站建設(shè)、網(wǎng)站內(nèi)鏈、定制開(kāi)發(fā)、網(wǎng)站導(dǎo)航、微信小程序

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)