## 前言

`Kubernetes`在叢集接入層設計並提供了兩種原生資源`Service`和`Ingress`，分別負責四層和七層的網路接入層配置。

傳統的做法是建立Ingress或LoadBalancer型別的Service來繫結騰訊雲的負載均衡將服務對外暴露。這種做法將使用者流量負載到使用者節點的NodePort上，透過KubeProxy元件轉發到容器網路中，但這種方案在業務的效能和能力支援會有所侷限。

為了解決這個問題，TKE容器團隊為在騰訊雲上**使用獨立或託管叢集的使用者提供了一種新的網路模式，利用彈性網路卡直連Pod的方案很大的增強了效能和業務能力的支援**。

![](https://main.qcloudimg.com/raw/788cfca7974c376e943a6e3735dcc43a.png)

本文將會從傳統的模式的問題入手，比較新舊模式的區別，並在最後提供新直連模式的使用指引。

## 傳統模式面臨的問題與挑戰

### 效能與特性

`KubeProxy`在叢集中會將使用者`NodePort`的流量透過NAT的方式轉發到叢集網路中。這個NAT轉發帶來了以下一些問題。

1. NAT轉發導致請求在效能上有一定的損失。

2. 1. 進行NAT操作本身會帶來效能上的損失。
   2. NAT轉發的目的地址可能會使得流量在容器網路內跨節點轉發。

3. NAT轉發導致請求的來源IP被修改了，客戶端無法獲取來源IP。

4. 當負載均衡的流量集中到幾個NodePort時。過於集中的流量會導致NodePort的SNAT轉發過多，使得源埠耗盡流量異常。還可能導致 conntrack 插入衝突導致丟包，影響效能。

5. `KubeProxy`的轉發具有隨機性，無法支援會話保持。

6. `KubeProxy`的每個NodePort其實也起到獨立的負載均衡作用，由於負載均衡無法收斂到一個地方，所以難以達到全域性的負載均衡。

為了解決以上問題，我們以前給使用者提供的技術建議主要是透過Local轉發的方式，避免`KubeProxy`NAT轉發帶來的問題。但是因為轉發的隨機性，一個節點上部署多個副本時會話保持依舊無法支援。而且Local轉發在滾動更新時，容易出現服務的閃斷，對業務的滾動更新策略以及優雅停機提出了更高的要求。我們有理由去尋找更好的方案解決這個問題。

### 業務可用性

透過NodePort接入服務時，NodePort的設計存在極大的容錯性。負載均衡會繫結叢集所有節點的NodePort作為後端。叢集任意一個節點的訪問服務時，流量將隨機分配到叢集的工作負載中。這就意味著部分NodePort的不可用，或者是Pod的不可用都不會影響服務的流量接入。

和Local訪問一樣，直接將負載均衡後端連線到使用者Pod的情況下，當業務在滾動更新時，如果負載均衡不能夠及時繫結上新的Pod，業務的快速滾動可能導致業務入口的負載均衡後端數量嚴重不足甚至被清空。因此，業務滾動更新的時候，接入層的負載均衡的狀態良好，方能保證滾動更新的安全平穩。

### 負載均衡的控制面效能

負載均衡的控制面介面。包括建立刪除修改四層、七層監聽器，建立刪除七層規則，繫結各個監聽器或者規則的後端。這些介面大部分是非同步介面，需要輪詢請求結果，介面的呼叫時間相對較長。當使用者叢集規模較大時，大量的接入層資源同步會導致元件存在很大的時延上的壓力。

## 新舊模式對比

### 效能對比

Pod直連模式已經在騰訊TKE上線，是對負載均衡的控制面最佳化。針對整個同步流程，重點最佳化了批次呼叫和後端例項查詢兩個遠端呼叫比較頻繁的地方。**最佳化完成後，Ingress典型場景下的控制面效能較最佳化前版本有了95%-97%左右的效能提升。**目前同步的耗時主要集中在非同步介面的等待上。

#### 後端節點突增 (應對叢集擴容的場景)

![](https://main.qcloudimg.com/raw/01ea713f0120e4fa9ee6686259d7f82a.png)

#### 七層規則突增（應對業務第一次上線部署到叢集的場景）

![](https://main.qcloudimg.com/raw/bf17e229f420c6a962b99ebfe2b0c7a6.png)

![](https://main.qcloudimg.com/raw/db8eaca82632a61fe34080543df741e4.png)

除去控制面效能最佳化這樣的硬核最佳化，負載均衡能夠直接訪問容器網路的Pod就是元件業務能力最重要的組成部分了，其不僅避免了NAT轉發效能上的損失，同時避免了NAT轉發帶來的各種對叢集內業務功能影響。但是在啟動該專案時這一塊還沒有特別好的訪問容器網路的支援。所以一期考慮叢集CNI網路模式下Pod有彈性網路卡入口，這個入口可以直接接入到負載均衡以達到直接訪問的目的。負載均衡直接後端訪問到容器網路，目前已經有透過雲聯網解決的方案，後續也會繼續跟進這種更貼近叢集網路的直連方案。

接下來能夠直接訪問了，如何保證滾動更新時的可用性保證呢？我們找到了官方提供的一個特性`ReadinessGate`。這個特性在1.12正式提供出來，主要是用來控制Pod的狀態。預設情況下，Pod有以下Condition：PodScheduled、Initialized、ContainersReady，當這幾個狀態都Ready的時候，Pod Ready的Condition就透過了。但是在雲原生的場景下面，Pod的狀態是非常有可能需要參考其他狀態的。`ReadinessGate`提供了這樣一個機制，允許為Pod的狀態判斷新增一個柵欄，由第三方來進行判斷與控制。這樣Pod的狀態就和第三方關聯起來了。

### 負載均衡流量對比

#### 傳統NodePort模式

![傳統NodePort接入](https://main.qcloudimg.com/raw/b21169cc330c724ae9fa3ec504157580.png)

#### 請求細節過程

1. 請求流量進入負載均衡
2. 請求被負載均衡轉發到某一個節點的NodePort
3. KubeProxy將來自NodePort的流量進行NAT轉發，目的地址是隨機的一個Pod。
4. 請求進入容器網路，並根據Pod地址轉發到對應節點。
5. 請求來到Pod所屬節點，轉發到Pod。

#### 新的Pod直連模式

![ENI彈性網路卡直連](https://main.qcloudimg.com/raw/b9f9c5b29a3d91e7ad4d5b556d1b98ff.png)

#### 請求細節過程

1. 請求流量進入負載均衡
2. 請求被負載均衡轉發到某一個Pod的ENI彈性網路卡

### 直連與Local訪問的區別

看起來這兩種訪問方式的效果是一樣的，但是在細節上還是存在一些差別。

1. 從效能上區別不大，開啟Local訪問時，流量不會進行NAT操作也不會進行跨節點轉發，所以僅僅多了一個到容器網路的路由。
2. 沒有進行NAT操作，來源IP就能夠正確獲取了。會話保持功能可能會有以下問題，當一個節點上存在多個Pod時，流量到哪一個Pod是隨機的，這個機制可能會使話保持出現問題。

### ReadinessGate的引入

前面有兩個細節，可以在這裡得到解答。

1. 為什麼要求叢集版本高於 1.12
2. 為什麼`kubectl get pod -o wide`的結果中`READINESS GATES`列有內容。

**這裡涉及到一個滾動更新相關的問題**
當使用者開始為應用做滾動更新的時候，`Kubernetes`會根據更新策略進行滾動更新。但是其判斷一批Pod啟動的標識僅包括Pod自身的狀態，並不會考慮這個Pod在負載均衡上是否已經進行配置健康檢查是否透過。有的時候當接入層元件高負載，不能及時對這些Pod進行及時排程的話，這些滾動更新成功的Pod可能並沒有正在對外提供服務，從而導致服務的中斷。為了將滾動更新和負載均衡的後端狀態關聯起來，TKE接入層元件引入了Kubernetes 1.12中引入的新特性`ReadinessGate`。TKE接入層元件只有在確認後端繫結成功並且健康檢查透過時，透過配置`ReadinessGate`的狀態來使Pod達到Ready的狀態，從而推動整個工作負載的滾動更新。

**在叢集中使用`ReadinessGate`的細節**
Kubernetes叢集提供的是一個服務註冊的機制，你只需要將你的服務以`MutatingWebhookConfigurations`資源的形式註冊到叢集中就可以了。叢集會在Pod建立的時候按照你的配置的回撥路徑通知你，這個時候就可以對Pod做一些建立前的操作，在這個Case裡面就是給Pod加上`ReadinessGate`。唯一需要注意的就是這個回撥過程必須是Https的，所以標配需要在`MutatingWebhookConfigurations`中配置簽發請求的CA，並在服務端配置該CA簽發的證書。

**`ReadinessGate`機制的災難恢復**
使用者叢集中的服務註冊或是證書有可能被使用者刪除，雖然這些系統元件資源不應該被使用者修改或破壞。但在使用者對叢集的探索或是誤操作下，這類問題會不可避免的出現。所以接入層元件在啟動時會檢查以上資源的完整性，在完整性受到破壞時會重建以上資源，加強系統的魯棒性。

### QPS和網路時延對比

直連與NodePort是服務應用的接入層方案，其實最終參與工作的還是使用者部署的工作負載，使用者工作負載的能力直接決定了業務的QPS等指標。所以我們針對這兩種接入層方案，在工作負載壓力較低的情況下，重點針對網路鏈路的時延進行了一些對比測試。直連在接入層的網路鏈路上能夠最佳化10%左右的時間。同時測試中的監控也發現，直連模式減少了大量VPC網路內的流量。測試場景，從20節點到80節點，逐步增大叢集規模，透過wrk工具對叢集進行網路延時的測試。針對QPS和網路時延，下圖給出了直連場景與NodePort的對比測試。

![](https://main.qcloudimg.com/raw/e50da9c8402059dccf76dadd517e853c.png)

### KubeProxy的一些設計思考

`KubeProxy`的缺點也在前文中提到的一樣明顯。但是基於雲上負載均衡、VPC網路的各種特性，我們能給出各種其他更加本地化的接入層方案。但這並不意味著`KubeProxy`的設計不好或是作用不大。其對叢集接入層的設計極具普適性、容錯性，基本適用於所有業務場景下的叢集，作為一個官方提供的元件這個設計是非常合適的。

## 新模式使用指引

### 前置要求

1. `Kubernetes`叢集版本需要高於 1.12。
2. 叢集網路模式必須開啟`VPC-CNI`彈性網路卡模式。
3. 直連模式`Service`使用的工作負載需使用`VPC-CNI`彈性網路卡模式。

### 控制檯操作指引

1. 登入 [容器服務控制檯](https://console.cloud.tencent.com/tke2)。

2. 參考控制檯[ 建立 Service ](https://cloud.tencent.com/document/product/457/45489#.E5.88.9B.E5.BB.BA-service)步驟，進入 “新建Service” 頁面，根據實際需求設定 Service 引數。

其中，部分關鍵引數資訊需進行如下設定，如下圖所示：

![](https://main.qcloudimg.com/raw/1e52f535cd9eb5712ddf6c4760952e70.png)

- **服務訪問方式**：選擇為【提供公網訪問】或【VPC內網訪問】。
   - **網路模式**：勾選【採用負載均衡直連Pod模式】。
   - **Workload繫結**：選擇【引用Worklocad】，並在彈出視窗中選擇 VPC-CNI 模式的後端工作負載。

3. 單擊【建立服務】，完成建立。

### Kubectl操作指引

- **Workload示例：nginx-deployment-eni.yaml**

> 注意`spec.template.metadata.annotations`中宣告瞭`tke.cloud.tencent.com/networks: tke-route-eni`，在工作負載使用VPC-CNI彈性網路卡模式。

```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: nginx
  name: nginx-deployment-eni
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      annotations:
        tke.cloud.tencent.com/networks: tke-route-eni
      labels:
        app: nginx
    spec:
      containers:
        - image: nginx:1.7.9
          name: nginx
          ports:
            - containerPort: 80
              protocol: TCP
   ```

- Service示例：nginx-service-eni.yaml

> 注意：`metadata.annotations`中宣告瞭`service.cloud.tencent.com/direct-access: "true"`，Service在同步負載均衡時將採用直連的方式配置訪問後端。

```yaml
apiVersion: v1
kind: Service
metadata:
  annotations:
    service.cloud.tencent.com/direct-access: "true"
  labels:
    app: nginx
  name: nginx-service-eni
spec:
  externalTrafficPolicy: Cluster
  ports:
    - name: 80-80-no
      port: 80
      protocol: TCP
      targetPort: 80
  selector:
    app: nginx
  sessionAffinity: None
  type: LoadBalancer
    ```

- 部署以上內容到叢集

> 注意：在你的環境你首先需要連線到叢集（沒有叢集的需要先建立叢集），可以參考文章尾部的幫助文件配置kubectl連線叢集。

```shell
  ➜  ~ kubectl apply -f nginx-deployment-eni.yaml
  deployment.apps/nginx-deployment-eni created
  
  ➜  ~ kubectl apply -f nginx-service-eni.yaml
  service/nginx-service-eni configured
  
  ➜  ~ kubectl get pod -o wide
  NAME                                   READY   STATUS    RESTARTS   AGE   IP               NODE          NOMINATED NODE   READINESS GATES
  nginx-deployment-eni-bb7544db8-6ljkm   1/1     Running   0          24s   172.17.160.191   172.17.0.3    <none>           1/1
  nginx-deployment-eni-bb7544db8-xqqtv   1/1     Running   0          24s   172.17.160.190   172.17.0.46   <none>           1/1
  nginx-deployment-eni-bb7544db8-zk2cx   1/1     Running   0          24s   172.17.160.189   172.17.0.9    <none>           1/1
  ➜  ~ kubectl get service -o wide
NAME                TYPE           CLUSTER-IP      EXTERNAL-IP      PORT(S)        AGE    SELECTOR
kubernetes          ClusterIP      10.187.252.1    <none>           443/TCP        6d4h   <none>
  nginx-service-eni   LoadBalancer   10.187.254.62   150.158.221.31   80:32693/TCP   6d1h   app=nginx
    ```

## 總結

與業界對比，

- AWS有類似方案，透過彈性網路卡的方式實現了Pod直連。
- GKE（Google Kubernetes Engine）也有類似方案。結合CLB（Google Cloud Load Balancing）的NEG（Network Endpoint Groups）特性實現接入層直連Pod。

現在騰訊雲TKE也利用彈性網路卡實現了Pod直連的網路模式，現已在騰訊雲TKE上線。接下來，我們還計劃對這個特性進行更多最佳化，包括

1. 不依賴VPC-ENI的網路模式，實現普通容器網路下的Pod直連。
2. 支援在Pod刪除之前，摘除負載均衡後端。

歡迎大家一起來使用！

## 相關參考

1. [Kubernetes Service介紹](https://kubernetes.io/docs/concepts/services-networking/service)
2. [Kubernetes Ingress介紹](https://kubernetes.io/docs/concepts/services-networking/ingress)
3. [Kubernetes Deployments 滾動更新策略](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#strategy)
4. [Kubernetes Pods ReadinessGate特性](https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#pod-readiness-gate)
5. [Kubernetes 透過Local轉發獲取來源IP](https://kubernetes.io/docs/tasks/access-application-cluster/create-external-load-balancer/#preserving-the-client-source-ip)
6. [TKE容器服務 網路模式選型](https://cloud.tencent.com/document/product/457/41636)
7. [TKE容器服務 VPC-CNI網路模式](https://cloud.tencent.com/document/product/457/34993)
8. [TKE容器服務 配置kubectl並連線叢集](https://cloud.tencent.com/document/product/457/32191)
9. [AWS ALB Ingress Controller](https://aws.amazon.com/cn/blogs/opensource/kubernetes-ingress-aws-alb-ingress-controller/)
10. [GKE 透過獨立 NEG 配置容器原生負載平衡](https://cloud.google.com/kubernetes-engine/docs/how-to/standalone-neg)</none></none></none></none></none>

TKE基於彈性網路卡直連Pod的網路負載均衡

相關文章