kubernetes云原生應(yīng)用負(fù)載均衡選型分析

本篇內(nèi)容介紹了“kubernetes云原生應(yīng)用負(fù)載均衡選型分析”的有關(guān)知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！

創(chuàng)新互聯(lián)公司主要從事成都網(wǎng)站設(shè)計、成都做網(wǎng)站、網(wǎng)頁設(shè)計、企業(yè)做網(wǎng)站、公司建網(wǎng)站等業(yè)務(wù)。立足成都服務(wù)睢縣,10余年網(wǎng)站建設(shè)經(jīng)驗,價格優(yōu)惠、服務(wù)專業(yè),歡迎來電咨詢建站服務(wù):028-86922220

引言

應(yīng)用的入口流量管理一直是開發(fā)運維關(guān)注的焦點之一，隨業(yè)務(wù)部署的計算資源、網(wǎng)絡(luò)環(huán)境、應(yīng)用架構(gòu)的發(fā)展變更，接入層流量管理方案的發(fā)展可大致分為傳統(tǒng)架構(gòu)、云原生容器化兩個階段。為滿足應(yīng)用交付的效率和訴求，各階段都涌現(xiàn)了不同的接入層解決方案，從最初的簡單負(fù)載均衡，到后來的 HAProxy、Nginx 等反向代理，再到如今的容器化環(huán)境下的各類 Kubernetes Ingress Controller。每個發(fā)展階段有哪些特點？面臨什么挑戰(zhàn)？都有什么解決方案？

階段	應(yīng)用部署資源粒度	應(yīng)用架構(gòu)	應(yīng)用訪問尋址
傳統(tǒng)架構(gòu)	物理/虛擬機(jī)（資源利用率低）	單體或簡單拆分模塊	基于較固定的 IP 地址管理
云原生容器化	容器（資源利用率高）	服務(wù)化	容器 IP 動態(tài)變化，通過動態(tài)服務(wù)注冊更新

傳統(tǒng)架構(gòu)階段，業(yè)務(wù)為單體應(yīng)用，三層架構(gòu)；部署于物理機(jī)/虛擬機(jī)；網(wǎng)絡(luò)環(huán)境基于 IP 地址管理，相對固定，基本不會變化；業(yè)務(wù)更新迭代的速度較慢，接入層的主要需求是具備 4 層和 7 層的負(fù)載均衡能力，用傳統(tǒng)負(fù)載均衡器支持即可。隨著應(yīng)用架構(gòu)演進(jìn)（應(yīng)用做了一定模塊拆分）和迭代效率的提升，出現(xiàn)了一些更復(fù)雜的接入層訴求：按流量內(nèi)容特征路由、灰度發(fā)布、限流、鑒權(quán)等，一般通過在負(fù)載均衡器后增加一層網(wǎng)絡(luò)代理（e.g. Nginx）支持，網(wǎng)絡(luò)代理 Nginx 具備更多的 7 層流量處理的能力，可通過 OpenResty 社區(qū)的 Lua 擴(kuò)展上述內(nèi)容路由、灰度發(fā)布、鑒權(quán)限流等高級功能。

云原生容器化階段的理想狀態(tài)是業(yè)務(wù)開發(fā)者只需專注實現(xiàn)業(yè)務(wù)邏輯，無需關(guān)心資源調(diào)度和運維管理，可真正做到按需使用，按量計費。虛擬機(jī)/物理機(jī)資源粒度粗糙，利用效率較低，需提前規(guī)劃計算、存儲、網(wǎng)絡(luò)資源，與理想狀態(tài)有較大差距。云原生階段，容器資源的粒度更細(xì)，利用率高，啟動/銷毀速度達(dá)到秒級，可靈活彈性伸縮（Kubernetes 已成為容器編排調(diào)度的業(yè)界標(biāo)準(zhǔn)，以下容器環(huán)境均代指 Kubernetes 集群）；網(wǎng)絡(luò)管理環(huán)境也發(fā)生了變更，出現(xiàn) Service 的概念，一個微服務(wù)往往是由一組彈性伸縮、動態(tài)調(diào)度的容器（Pod）承載，Pod 的 IP 地址動態(tài)變化，這一組 Pod 一般以 Service 對外提供訪問，流量管理是以 Service 為單位。服務(wù)化拆分業(yè)務(wù)模塊構(gòu)建應(yīng)用更容易，加上容器環(huán)境良好的彈性伸縮能力，DevOps 理念得以很好的實施，微服務(wù)的迭代步伐加快，經(jīng)常需要滾動更新。此時的入口流量管理面臨如下新挑戰(zhàn)：

1. 需要與 Kubernetes 集成，支持轉(zhuǎn)發(fā)流量到指定 Pod。

2. 更新迭代速度加快，對服務(wù)新版本灰度發(fā)布的訴求更加強(qiáng)烈。

3. 出現(xiàn)集群概念，集群之間的服務(wù)發(fā)現(xiàn)是隔離的，接入層需支持跨集群的服務(wù)發(fā)現(xiàn)（即接入層可選擇 backend 為多個集群的 Pod ）；這區(qū)別于傳統(tǒng)物理機(jī)/虛擬機(jī)階段，沒有集群隔離，只需保證網(wǎng)絡(luò)聯(lián)通性，即可配置接入層后端為任意對應(yīng)服務(wù)的 IP 地址。

4. 傳統(tǒng)階段到云原生階段的遷移過程中，出現(xiàn) VM、容器環(huán)境混布的情況。

基于上述挑戰(zhàn)，出現(xiàn)了以下容器環(huán)境的接入層流量管理解決方案：

1. Kubernetes 官方定義的 Ingress API：老牌網(wǎng)絡(luò)代理（e.g. Nginx，HAProxy）或云廠商的負(fù)載均衡產(chǎn)品（e.g. AWS Elastic Load Balancer，騰訊云 CLB）都實現(xiàn)了各自的 Ingress Controller，作為單個集群的入口流量管理解決方案。灰度發(fā)布、鑒權(quán)限流等能力，視 Ingress Controller 的能力，可通過 Annotation 擴(kuò)展，部分 Ingress Controller 還設(shè)計了自己的流量管理模型和語法。

2. Service Mesh Ingress：服務(wù)網(wǎng)格的服務(wù)發(fā)現(xiàn)和管理界限大于集群緯度，以 Istio Ingress Gateway 為例，基于 Istio 跨集群的服務(wù)發(fā)現(xiàn)能力，backend 可以來自不同集群的服務(wù)，同時還支持注冊在網(wǎng)格內(nèi)運行在虛擬機(jī)上的服務(wù)。Istio 也設(shè)計了自己的管理模型和語法，聲明式支持配置一致的南北 + 東西向流量管理。

3. 沿用原有 VM 上部署的網(wǎng)絡(luò)代理，轉(zhuǎn)發(fā)流量至 VM 服務(wù)或 Kubernetes 集群的服務(wù)。

下面本文將從云原生容器化環(huán)境入口流量管理使用場景切入，帶您了解云原生接入層流量管理的各類解決方案及優(yōu)劣對比。

云原生接入層流量管理場景與解決方案

場景一：基礎(chǔ)流量管理

入口流量管理的首個使用場景是需要將服務(wù)暴露給外部，供客戶端調(diào)用。常見的方式是將服務(wù)按 URL 暴露，例如一個電商網(wǎng)站，需要將 /login 的請求路由到登陸服務(wù)，將 /product 的請求路由到商品服務(wù)等，該場景要求接入層具備基于流量內(nèi)容路由的能力。

方案：Load Balancer + NodePort

在容器化的早期階段，應(yīng)用同時部署在虛擬機(jī)和 Kubernetes 集群上，很多用戶會使用原有負(fù)載均衡（e.g. Nginx, 騰訊云 CLB）將請求分別轉(zhuǎn)發(fā)到虛擬機(jī)和容器，同時受限于容器網(wǎng)絡(luò)方案，原有負(fù)載均衡不能直接訪問 Pod IP，因此需要通過 NodePort 暴露集群內(nèi)的服務(wù)。

但是該方案存在以下問題：

1. NodePort 端口數(shù)量有限（默認(rèn) 30000-32767）

2. 隨著集群規(guī)模的擴(kuò)大，Nginx 配置文件越來越復(fù)雜，不易管理

3. 用戶將應(yīng)用發(fā)布到 Kubernetes 集群后，需要再單獨修改 Nginx 配置，體驗不夠云原生

方案：Kubernetes Ingress

Kubernetes 提供了 Ingress API [1] 用于暴露集群內(nèi)的 HTTP 服務(wù)，Ingress 支持基于 Host 和 Path 將請求路由到不同 Service。為了讓 Ingress 工作，集群必須有一個正在運行的 Ingress 控制器（e.g. Nginx Ingress Controller）。原生 Ingress 語法提供簡單的基于 Host，Path 路由，以及配置 TLS 的能力。

1. 基于 Host 路由

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: public-services
  namespace: default
spec:
  rules:
  - host: service1.tencent.com
    http:
      paths:
      - backend:
          serviceName: service1
          servicePort: 80
        path: /
  - host: service2.tencent.com
    http:
      paths:
      - backend:
          serviceName: service2
          servicePort: 80
        path: /

2. 基于 Path 路由

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: public-services
  namespace: default
spec:
  rules:
  - host: services.tencent.com
    http:
      paths:
      - backend:
          serviceName: service1
          servicePort: 80
        path: /service1
      - backend:
          serviceName: service2
          servicePort: 80
        path: /service2

3. TLS 配置

Ingress 也提供了 TLS 支持，可以將集群內(nèi)的 HTTP 服務(wù)對外暴露為 HTTPS，我們需要先將 SSL 證書以 Secret 的形式保存在集群中，再使用 Ingress 引用剛剛創(chuàng)建的 Secret。

apiVersion: v1
kind: Secret
metadata:
  name: public-services-tls
  namespace: default
data:
  tls.crt: base64 encoded cert
  tls.key: base64 encoded key
type: kubernetes.io/tls
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: services-with-tls
  namespace: default
spec:
  tls:
  - hosts:
      - services.tencent.com
    secretName: public-services-tls
  rules:
    http:
      paths:
      - backend:
          serviceName: service1
          servicePort: 80
        path: /service1
      - backend:
          serviceName: service2
          servicePort: 80
        path: /service2

Kubernetes Ingress 小結(jié)：對于簡單的 HTTP 流量的路由，使用 Ingress 配置非常容易，這也是當(dāng)前 Ingress 受歡迎的原因（據(jù) CNCF 2020 云原生調(diào)查報告 [2]，50% 的用戶正在或即將使用第三方代理做應(yīng)用流量轉(zhuǎn)發(fā)，其中 Nginx 和 Envoy [3] 是最受歡迎的 Ingress provider）。

但是另一方面原生 Ingress 的功能十分有限，不能滿足很多復(fù)雜場景的需求。許多第三方的 Ingress Controller [4] 通過 annotation 或新的配置模型和語法擴(kuò)展了原生 Ingress 的功能，但仍然受限于集群間服務(wù)發(fā)現(xiàn)隔離的問題，只能作為單集群入口流量管理方案。

場景二：灰度發(fā)布

服務(wù)可暴露給外部訪問后，還需要考慮如何做版本發(fā)布，做平滑、無風(fēng)險地迭代。常見的兩種做法是按權(quán)重或流量內(nèi)容切部分流量至新版本驗證穩(wěn)定性，無問題后逐漸過渡至新版本，即我們熟知的灰度發(fā)布、AB test。

Kubernetes Ingress API 原生并沒有灰度發(fā)布的功能，Nginx ingress controller 通過 annotation 的方式擴(kuò)展了原生 Ingress API 的功能，實現(xiàn)了灰度發(fā)布，但這種方式并不能很好地支撐控制應(yīng)用流量的發(fā)布策略，相比之下，Istio CRD 配置更靈活易用，下面介紹如何使用 Istio VirtualService 配置灰度發(fā)布路由規(guī)則。

1. 基于權(quán)重

Istio 可通過 Virtual Service 配置基于權(quán)重的灰度發(fā)布，以下是配置來自 {namespace}/{gateway} 的入口流量 95% 路由到 {service} 的 current 版本，5% 路由到 canary 版本的示例：

apiVersion: ...
kind: VirtualService
metadata:
  name: canary-weight
spec:
  hosts:
    - '*'
  gateways:
    - {namespace}/{gateway}
  http:
    - route:
        - destination:
            host: {service}
            subset: current
          weight: 95
        - destination:
            host: {service}
            subset: canary
          weight: 5

2. 基于請求內(nèi)容

VirtualService 也支持配置基于內(nèi)容的灰度發(fā)布路由規(guī)則，以下是配置來自 {namespace}/{gateway} 的入口流量 header cookie "version=stable" 時路由到 {service} 的 current 版本，"version=canary" 時路由到 {service} 的 canary 版本的示例：

apiVersion: ...
kind: VirtualService
metadata:
  name: canary-content
spec:
  hosts:
    - '*'
  gateways:
    - {namespace}/{gateway}
  http:
    - match:
        - headers:
            cookie:
              exact: version=stable
      route:
        - destination:
            host: {service}
            subset: current
    - match:
        - headers:
            cookie:
              exact: version=canary
      route:
        - destination:
            host: {service}
            subset: canary

場景三：應(yīng)用流量鑒權(quán)與限流

鑒權(quán)與限流，是保證南北流量的安全性與健壯性的兩個重要能力。

接入層是訪問后端服務(wù)的統(tǒng)一入口，保證接入層的安全是接入層流量管理的一個重要場景，一般在入口處需要配置認(rèn)證與授權(quán)規(guī)則，傳統(tǒng)架構(gòu)下認(rèn)證授權(quán)功能一般通過代碼邏輯實現(xiàn)，Istio 自 1.5 之后提供了 AuthorizationPolicy 和 RequestAuthentication CRD [5]，可靈活配置入口層的認(rèn)證和授權(quán)規(guī)則。

1. 請求身份認(rèn)證（JWT）

入口處認(rèn)證請求攜帶的 Json Web Token，放通攜帶合法令牌的請求，拒絕攜帶非法令牌的請求。

以下是使用 Istio RequestAuthentication 配置 Ingress Gateway 放通攜帶合法 JWT 請求的配置示例：

apiVersion: ..
kind: RequestAuthentication
metadata:
  name: jwt-example
  namespace: istio-system
spec:
  selector:
    matchLabels:
      istio: ingressgateway
  jwtRules:
  - issuer: {issuer that issued the JWT}
    jwksUri: {URL of the provider’s public key set to validate signature of the JWT}

2. 授權(quán)

在入口處配置授權(quán)策略，根據(jù)流量內(nèi)容特征，允許/拒絕流量訪問，例如在入口處配置 IP 黑/白名單；或有外部鑒權(quán)服務(wù)，希望入口組件可對接外部鑒權(quán)服務(wù)，按照其返回的鑒權(quán)結(jié)果放通/拒絕流量。

以下是使用 Istio AuthorizationPolicy 為 Ingress Gateway 配置 IP block 白名單的示例：

apiVersion: ...
kind: AuthorizationPolicy
metadata:
  name: white-list
  namespace: istio-system
spec:
  selector:
    matchLabels:
      app: istio-ingressgateway
  action: ALLOW
  rules:
  - from:
    - source:
        ipBlocks: {single IP or CIDR}

Istio 1.9 增強(qiáng)了對 AuthorizationPolicy 對于對接外部鑒權(quán)系統(tǒng)的支持，可配置 Ingress Gateway 按照外部鑒權(quán)系統(tǒng)返回的結(jié)果放通或拒絕流量。

apiVersion: ...
kind: AuthorizationPolicy
metadata:
  name: ext-authz
  namespace: istio-system
spec:
  selector:
    matchLabels:
      app: istio-ingressgateway
  action: CUSTOM
  provider:
    name: "my-ext-authz-service"
  rules: ...

3. 限流業(yè)務(wù)規(guī)模較大，后端服務(wù)提供給眾多租戶使用時，需要在入口處控制請求的速率，例如限制每個 User ID 每分鐘只能請求 “/product” 接口 100 次。 為了使用 Istio Ingress Gateway 的限流功能，首先需要安裝 Ratelimit service，可以自行實現(xiàn)或直接使用社區(qū)的 ratelimit [6]，然后使用 Envoyfilter 配置限流規(guī)則，具體配置方法可參考官方文檔[7]。

場景四：多集群異構(gòu)場景入口流量管理

隨著業(yè)務(wù)規(guī)模的增加，或?qū)θ轂?zāi)、數(shù)據(jù)合規(guī)性、業(yè)務(wù)之間隔離要求的提升，業(yè)務(wù)會考慮與實施部署多個 Kubernetes 集群，甚至?xí)霈F(xiàn)容器化環(huán)境與非容器化環(huán)境異構(gòu)混布的情況，給入口流量管理又帶來了一系列新的挑戰(zhàn)。

多 Kubernetes 集群一般是基于容災(zāi)和業(yè)務(wù)隔離兩方面的考慮：

（1）容災(zāi)。Kubernetes 集群有地域?qū)傩裕鶕?jù)應(yīng)用交付提供服務(wù)的訪問時效和容災(zāi)訴求，同一應(yīng)用可能分布在多個不同的地理區(qū)域。多（公有）云、混合云（IDC + 公有云）架構(gòu)的容災(zāi)，也需部署多個集群。跨地域多集群容災(zāi)與就近接入可通過 DNS 解析提供，但 DNS 有緩存，故障轉(zhuǎn)移實際生效時間可能較長，并且無法視服務(wù)健康程度切部分流量到備份地域，只能全部切換。

Istio 基于以下能力：1. 多集群服務(wù)發(fā)現(xiàn)能力；2. 地域感知、故障感知、容災(zāi)流量容量規(guī)劃，可實現(xiàn)：1. 當(dāng)所有集群的服務(wù)都健康時，按照請求來源地就近路由至對應(yīng)服務(wù)；2. 某個集群的服務(wù)出現(xiàn)部分故障時，視服務(wù)的健康程度轉(zhuǎn)移一定比例的流量到其他集群的備份服務(wù)。

（2）業(yè)務(wù)隔離。據(jù) CNCF 2020 云原生調(diào)查報告顯示 [2]，用多個集群做應(yīng)用隔離是僅次于用 namespace 隔離的使用方式，使用率從 2019 年的 47% 上升到了2020年的 50%。多個業(yè)務(wù)仍共用一個流量入口時，接入層需具備多集群服務(wù)發(fā)現(xiàn)的能力，將流量按指定策略路由至指定集群的服務(wù)。

方案：Service Mesh Ingress

Kubernetes Ingress Controller 遇到的一個挑戰(zhàn)是，Kubernetes 集群隔離了集群間的服務(wù)發(fā)現(xiàn)，Ingress Controller 只能作為集群級別的流量入口。而 Service Mesh 技術(shù)借助于控制面服務(wù)發(fā)現(xiàn)的能力，可發(fā)現(xiàn)或注冊多個集群的服務(wù)甚至異構(gòu)服務(wù)，打通集群間的服務(wù)發(fā)現(xiàn)壁壘，不受應(yīng)用部署平臺限制，天然提供一致的接入流量轉(zhuǎn)發(fā)管理能力。

Istio 作為最受歡迎的 Service Mesh 開源項目，它的接入層 Istio Ingress Gateway 同樣提供了對 Ingress API 的支持，但是不建議使用 Ingress 去配置 Ingress Gateway，這大大削弱了 Istio 的能力。Istio 對流量管理模型提供了更高程度的抽象，可以直接使用 Istio API 實現(xiàn)更靈活的流量管理能力，實現(xiàn)灰度發(fā)布，跨集群路由，地域感知等高級特性。

Istio Ingress Gateway 基于 Envoy [3] 實現(xiàn)，Envoy 最初由 Lyft 創(chuàng)建，是一款為云原生場景設(shè)計的高性能服務(wù)代理軟件，后由 Lyft 捐獻(xiàn)到了 CNCF 社區(qū)，并已從 CNCF 畢業(yè)。

1. 多 Kubernetes 集群服務(wù)管理

Istiod 可以通過網(wǎng)格內(nèi)所有集群的 API Server 來獲取 endpoints 信息，聚合多個集群的信息后，將最終生成的配置推送到 Ingress Gateway，Ingress Gateway 可以將請求按需轉(zhuǎn)發(fā)至網(wǎng)格內(nèi)所有 Pod。

2. 地域感知負(fù)載均衡

在服務(wù)網(wǎng)格中，一個 Pod 的地理信息包括以下 3 個部分 [8]：

• Region（地域）： 通常代表一個較大的地理區(qū)域（e.g 北京 上海），在 Kubernetes 中，節(jié)點的地域由標(biāo)簽 topology.kubernetes.io/region 決定

• Zone（可用區(qū)）：一個地域通常包含多個可用區(qū)（e.g. 北京一區(qū) 北京二區(qū)），在 Kubernetes 中，節(jié)點的可用區(qū)由標(biāo)簽 topology.kubernetes.io/zone 決定

• Sub-zone：允許對可用區(qū)做進(jìn)一步劃分實現(xiàn)更細(xì)粒度的控制，例如可以按照 rack（機(jī)架）劃分，在 Kubernetes 中不存在 sub-zone 的概念，Istio 使用節(jié)點的 topology.istio.io/subzone 標(biāo)簽來定義 sub-zone

如果使用云廠商托管的 Kubernetes 服務(wù)，節(jié)點的 Region 和 Zone 標(biāo)簽已由云廠商配置，例如在 TKE 集群中，上海二區(qū)的節(jié)點會有以下標(biāo)簽：

• topology.kubernetes.io/region: sh

• topology.kubernetes.io/zone: "200002"

網(wǎng)格內(nèi)的集群可能分布在不同地域不同可用區(qū)，大多數(shù)情況下，我們希望盡量減少跨地域/跨可用區(qū)的請求調(diào)用，因為這會增加請求時延。因此接入層需具備感知 endpoints 地理信息的能力，并支持根據(jù)地理信息配置負(fù)載均衡及故障轉(zhuǎn)移策略。

（1）地域故障轉(zhuǎn)移

在開啟地域負(fù)載均衡的情況下，Istio 會告知 Ingress Gateway 將請求就近轉(zhuǎn)發(fā)。 當(dāng)所有實例都正常時，請求將保持在同一地點，當(dāng)實例異常時，流量會分發(fā)到下一優(yōu)先地域的實例。

例如，位于 bj.bj-01 的 Ingress Gateway 轉(zhuǎn)發(fā)請求的優(yōu)先級如下：

優(yōu)先級	地理位置
1	bj.bj-01	Region Zone 完全匹配
2	bj.bj-02	Region 匹配 Zone 不匹配
3	sh.sh-01/sh-02	Region Zone 都不匹配

（2）地域加權(quán)負(fù)載均衡

地域加權(quán)負(fù)載均衡可以將用戶定義的一定百分比的流量分發(fā)到某些地域，例如我們可以使用如下配置分發(fā)流量：

global:
  localityLbSetting:
    enabled: true
    distribute:
    - from: bj/bj-01/*
      to:
        "bj/bj-01/*": 70
        "bj/bj-02/*": 20
        "sh/sh-01/*": 10

3. 異構(gòu)服務(wù)入口流量管理

除了多集群，用戶在云原生改造的過程中，常常會面臨部分服務(wù)已經(jīng)做了容器化改造，運行在 Kubernetes 集群，部分不便改造的服務(wù)仍在虛擬機(jī)的情況，甚至?xí)胁糠质褂玫氖窃茝S商 serverless 云函數(shù)服務(wù)（e.g. AWS lambda）。接入層需具備異構(gòu)服務(wù)注冊/發(fā)現(xiàn)的能力，以管理異構(gòu)部署服務(wù)的南北向流量。

可以通過 Istio 提供的 WorkloadGroup 和 WorkloadEntry 將虛擬機(jī)上的服務(wù)注冊到網(wǎng)格內(nèi)，同一個服務(wù)可以同時運行在 Kubernetes 集群和虛擬機(jī)上。

Istio Ingress Gateway 小結(jié)：Istio Ingress Gateway 在入口灰度發(fā)布、安全、多集群異構(gòu)流量管理等場景提供了多集群服務(wù)發(fā)現(xiàn)、地域感知、流量容量規(guī)劃，以及更強(qiáng)大靈活的流量管理 API 的支持，但與此同時，用戶也不得不面對 Istio 的復(fù)雜性。需要投入資源和人力成本運維 Istiod 和 Istio Ingress Gateway，集成 metric，trace，log 等可觀測性及證書管理周邊系統(tǒng)成本較高，還需要正確配置各種 CRD（Gateway VirtualService DestinationRule 等）。

接入層解決方案功能對比

以下是騰訊云容器環(huán)境下常見的接入層解決方案功能對比。

多集群灰度發(fā)布/跨集群容災(zāi) Demo

下面將使用騰訊云服務(wù)網(wǎng)格 TCM 控制臺演示 Service Mesh Ingress 做多 Kubernetes 集群環(huán)境下的灰度發(fā)布和容災(zāi)。

1. 創(chuàng)建服務(wù)網(wǎng)格，添加兩個部署服務(wù)的服務(wù)發(fā)現(xiàn)集群（基礎(chǔ)監(jiān)控指標(biāo)自動對接到云監(jiān)控，可在控制臺查看，可視情況開啟云原生監(jiān)控，滿足自定義監(jiān)控訴求），勾選啟用 Ingress Gateway

2. 使用 Destination Rule 定義 frontend 服務(wù)的版本（frontend 服務(wù)在兩個集群均有同樣的部署）

3. 使用 Gateway 配置 ingress gateway 監(jiān)聽規(guī)則，開啟 443 端口 https 訪問，使用騰訊云 SSL 平臺服務(wù)器證書

4. 使用 VirtualService 配置路由規(guī)則，50% 流量路由至 v1 版本，50% 路由至 v2 版本

5. 有訪問請求后，查看工作負(fù)載（frontend，frontend-canary）監(jiān)控，兩個版本均有流量，比例大致 1:1

6. 灰度結(jié)束，更改權(quán)重，100% 的流量均路由至 v2 版本，再次查看工作負(fù)載的監(jiān)控數(shù)據(jù)，發(fā)現(xiàn)所有流量都已請求至 frontend-canary

7. 下面我們通過調(diào)整其中一個集群的 frontend 服務(wù)工作負(fù)載 Pod 數(shù)量為 0 來模擬其中一個集群 frontend 服務(wù)故障情況，發(fā)現(xiàn)其中一個集群 frontend 服務(wù)故障后，仍可以正常訪問該服務(wù)，查看另一集群的 frontend 服務(wù)的工作負(fù)載監(jiān)控，會發(fā)現(xiàn)入帶寬增加了一倍，表明其中一個集群的服務(wù)故障后，流量容災(zāi)切到了另一集群。

8. 如有擴(kuò)展東西向流量管理的需要，可以給業(yè)務(wù)注入 envoy sidecar，即可使用同一套 Istio API 實現(xiàn)南北東西向流量一致性管理，開箱即用網(wǎng)絡(luò)拓?fù)?、調(diào)用追蹤等可觀測性功能。

騰訊云服務(wù)網(wǎng)格 TCM，是騰訊云完全兼容 Istio 的 Service Mesh 產(chǎn)品，目前已實現(xiàn)了控制面組件托管，使用 TCM Ingress Gateway 只需要部署一組數(shù)據(jù)面 envoy pod 在業(yè)務(wù)集群，即可開箱即用上述 Istio Ingress Gateway 的所有入口流量管理能力。同時，TCM 集成了騰訊云監(jiān)控、證書周邊產(chǎn)品，提供開箱即用的可觀測能力和證書配置功能。

“kubernetes云原生應(yīng)用負(fù)載均衡選型分析”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識可以關(guān)注創(chuàng)新互聯(lián)網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實用文章！

文章名稱：kubernetes云原生應(yīng)用負(fù)載均衡選型分析
網(wǎng)站URL：http://muchs.cn/article28/ipidjp.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供小程序開發(fā)、網(wǎng)站改版、ChatGPT、網(wǎng)站收錄、搜索引擎優(yōu)化、云服務(wù)器

廣告

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