*作者：* *魁予*

## 問題提出

流量有損是在應用釋出時的常見問題，其現象通常會反饋到流量監控上，如下圖所示，釋出過程中服務 RT 突然升高，造成部分業務響應變慢，給使用者的最直觀體驗就是卡頓；或是請求的 500 錯誤數突增，在使用者側可能感受到服務降級或服務不可用，從而影響使用者體驗。

![1.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/472bfbab187445e9a2abff1a8561219b~tplv-k3u1fbpfcp-zoom-1.image "1.png")

![2.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/64976848fe4e49beb0afaca3ac7f869e~tplv-k3u1fbpfcp-zoom-1.image "2.png")

因為應用釋出會伴隨流量有損，所以我們往往需要將釋出計劃移到業務低谷期，並嚴格限制應用釋出的持續時間，儘管如此，還是不能完全避免釋出帶來的風險，有時甚至不得不選擇停機發布。EDAS 作為一個通用應用管理系統，應用釋出是其最基本的功能之一，而 K8s 應用是 EDAS 中最普遍的應用的形態，下文將透過對 EDAS 客戶真實場景的歸納，從 K8s 的流量路徑入手，分析有損釋出產生的原因，並提供實用的解決方案。

## 流量路徑分析

K8s 中，流量通常可以從以下幾種路徑進入到應用 Pod 中，每條路徑大相徑庭，流量損失的原因各不相同。我們將分情況探究每種路徑的路由機制，以及 Pod 變更對流量路徑的影響。

### LB Service 流量

![3.jpeg](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/7c041240aa4941fa957665dabc1897ae~tplv-k3u1fbpfcp-zoom-1.image "3.jpeg")

透過 LoadBalancer 型別 Service 訪問應用時，流量路徑中核心元件是 LoadBalancer 和 ipvs/iptables。LoadBalancer 負責接收 K8s 叢集外部流量並轉發到 Node 節點上，ipvs/iptables 負責將節點接收到的流量轉發到 Pod 中。核心元件的動作由 CCM（cloud-controller-manager）和 kube-proxy 驅動，分別負責更新 LoadBalancer 後端和 ipvs/iptables 規則。

在應用釋出時，就緒的 Pod 會被新增到 Endpoint 後端，Terminating 狀態的 Pod 會從 Endpoint 中移除。kube-proxy 元件會更新各節點的 ipvs/iptables 規則，CCM 元件監聽到了 Endpoint 的變更後會呼叫雲廠商 API 更新負載均衡器後端，將 Node IP 和埠更新到後端列表中。流量進入後，會根據負載均衡器配置的監聽後端列表轉發到對應的節點，再由節點 ipvs/iptables 轉發到實際 Pod。

Service 支援設定 externalTrafficPolicy，根據該引數的不同，節點 kube-proxy 元件更新 ipvs/iptables 列表及 CCM 更新負載均衡器後端的行為會有所不同：

-   Local 模式：CCM 僅會將目標服務所在節點新增入負載均衡後端地址列表。流量到達該節點後僅會轉發到本節點的 Pod 中。
-   Cluster 模式：CCM 會將所有節點都新增到負載均衡後端地址列表。流量到達該節點後允許被轉發到其他節點的 Pod 中。

### Nginx Ingress 流量

![4.jpeg](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/983265790b4b41f5b5081d220c893827~tplv-k3u1fbpfcp-zoom-1.image "4.jpeg")

透過 Nginx Ingress 提供的 SLB 訪問應用時，流量路徑核心元件為 Ingress Controller，它不但作為代理伺服器負責將流量轉發到後端服務的 Pod 中，還負責根據 Endpoint 更新閘道器代理的路由規則。

在應用釋出時，Ingress Controller 會監聽 Endpoint 的變化，並更新 Ingress 閘道器路由後端，流量進入後會根據流量特徵轉發到匹配規則上游，並根據上游後端列表選擇一個後端將請求轉發過去。

預設情況下，Controller 在監聽到 Service 的 Endpoint 變更後，會呼叫 Nginx 中的動態配置後端介面，更新 Nginx 閘道器上游後端列表為服務 Endpoint 列表，即 Pod 的 IP 和埠列表。因此，流量進入 Ingress Controller 後會被直接轉發到後端 Pod IP 和埠。

### 微服務流量

![5.jpeg](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/a2ace55fdefd4c1baa02e7a196dc9375~tplv-k3u1fbpfcp-zoom-1.image "5.jpeg")

使用微服務方式訪問應用時，核心元件為註冊中心。Provider 啟動後會將服務註冊到註冊中心，Consumer 會訂閱註冊中心中服務的地址列表。

在應用釋出時，Provider 啟動後會將 Pod IP 和埠註冊到註冊中心，下線的 Pod 會從註冊中心移除。服務端列表的變更會被消費者訂閱，並更新快取的服務後端 Pod IP 和埠列表。流量進入後，消費者會根據服務地址列表由客戶端負載均衡轉發到對應的 Provider Pod 中。

## 原因分析與通用解決方案

應用釋出過程其實是新 Pod 上線和舊 Pod 下線的過程，當流量路由規則的更新與應用 Pod 上下線配合出現問題時，就會出現流量損失。我們可以將應用釋出中造成的流量損失歸類為上線有損和下線有損，總的來看，上線和下線有損的原因如下，後文將分情況做更深入討論：

-   上線有損：新Pod上線後過早被加入路由後端，流量被過早路由到了未準備好的Pod。
-   下線有損：舊Pod下線後路由規則沒有及時將後端移除，流量仍路由到了停止中的Pod。

### 上線有損分析與對策

K8s 中 Pod 上線流程如下圖所示：

![6.jpeg](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/5e8595bda02b42778965929b933e85a2~tplv-k3u1fbpfcp-zoom-1.image "6.jpeg")

如果在 Pod 上線時，不對 Pod 中服務進行可用性檢查，這會使得 Pod 啟動後過早被新增到 Endpoint 後端，後被其他閘道器控制器新增到閘道器路由規則中，那麼流量被轉發到該 Pod 後就會出現連線被拒絕的錯誤。因此，健康檢查尤為重要，我們需要確保 Pod 啟動完成再讓其分攤線上流量，避免流量損失。K8s 為 Pod 提供了 readinessProbe 用於校驗新 Pod 是否就緒，設定合理的就緒探針對應用實際的啟動狀態進行檢查，進而能夠控制其在 Service 後端 Endpoint 中上線的時機。

-   **基於 Endpoint 流量場景**

對於基於 Endpoint 控制流量路徑的場景，如 LB Service 流量和 Nginx Ingress 流量，配置合適的就緒探針檢查就能夠保證服務健康檢查透過後，才將其新增到 Endpoint 後端分攤流量，以避免流量損失。例如，在 Spring Boot 2.3.0 以上版本中增加了健康檢查介面/actuator/health/readiness 和/actuator/health/liveness 以支援配置應用部署在 K8s 環境下的就緒探針和存活探針配置：

```
readinessProbe: 
  ...
  httpGet:
    path: /actuator/health/readiness
    port: ${server.port}
```

-   **微服務流量場景**

對於微服務應用，服務的註冊和發現由註冊中心管理，而註冊中心並沒有如 K8s 就緒探針的檢查機制。並且由於 JAVA 應用通常啟動較慢，服務註冊成功後所需資源均仍然可能在初始化中，比如資料庫連線池、執行緒池、JIT編譯等。如果此時有大量微服務請求湧入，那麼很可能造成請求 RT 過高或超時等異常。

針對上述問題，Dubbo 提供了延遲註冊、服務預熱的解決方案，功能概述如下：

-   延遲註冊功能允許使用者指定一段時長，程式在啟動後，會先完成設定的等待，再將服務釋出到註冊中心，在等待期間，程式有機會完成初始化，避免了服務請求的湧入。

-   服務預熱功能允許使用者設定預熱時長，Provider 在向註冊中⼼註冊服務時，將⾃身的預熱時⻓、服務啟動時間透過後設資料的形式註冊到註冊中⼼中，Consumer 在註冊中⼼訂閱相關服務例項列表，根據例項的預熱時長，結合 Provider 啟動時間計算呼叫權重，以控制剛啟動例項分配更少的流量。透過小流量預熱，能夠讓程式在較低負載的情況下完成類載入、JIT 編譯等操作，以支援預熱結束後讓新例項穩定均攤流量。

我們可以透過為程式增加如下配置來開啟延遲註冊和服務預熱功能：

```
dubbo:
    provider:
        warmup: 120000
        delay: 5000
```

配置以上引數後，我們透過為 Provider 應用擴容一個 Pod，來檢視新 Pod 啟動過程中的 QPS 曲線以驗證流量預熱效果。QPS 資料如下圖所示：

![7.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/493b999ab81940b99c7be513bcb6ebf2~tplv-k3u1fbpfcp-zoom-1.image "7.png")

根據 Pod 接收流量的 QPS 曲線可以看出，在 Pod 啟動後沒有直接均攤線上的流量，而是在設定的預熱時長 120 秒內，每秒處理的流量呈線性增長趨勢，並在 120 秒後趨於穩定，符合流量預熱的預期效果。

### 下線有損分析與對策

在 K8s 中，Pod 下線流程如下圖所示：

![8.jpeg](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/6e6087fbf8b543de84eefdf75d454681~tplv-k3u1fbpfcp-zoom-1.image "8.jpeg")

從圖中我們可以看到，Pod 被刪除後，狀態被 endpoint-controller 和 kubelet 訂閱，並分別執行移除 Endpoint 和刪除 Pod 操作。而這兩個元件的操作是同時進行的，並非我們預期的按順序先移除 Endpoint 後再刪除 Pod，因此有可能會出現在 Pod 已經接收到了 SIGTERM 訊號，但仍然有流量進入的情況。

K8s 在 Pod 下線流程中提供了 preStop Hook 機制，可以讓 kubelet 在發現 Pod 狀態為 Terminating 時，不立即向容器傳送 SIGTERM 訊號，而允許其做一些停止前操作。對於上述問題的通用方案，可以在 preStop 中設定 sleep 一段時間，讓 SIGTERM 延遲一段時間再傳送到應用中，可以避免在這段時間內流入的流量損失。此外，也能允許已被 Pod 接收的流量繼續處理完成。

上面介紹了在變更時，由於 Pod 下線和 Endpoint 更新時機不符合預期順序可能會導致的流量有損問題，在應用接入了多種型別閘道器後，流量路徑的複雜度增加了，在其他路由環節也會出現流量損失的可能。

-   **LB Service 流量場景**

在使用 LoadBalancer 型別 Service 訪問應用時，配置 Local 模式的 externalTrafficPolicy 可以避免流量被二次轉發並且能夠保留請求包源 IP 地址。

應用釋出過程中，Pod 下線並且已經從節點的 ipvs 列表中刪除，但是由 CCM 監聽 Endpoint 變更並呼叫雲廠商 API 更新負載均衡器後端的操作可能會存在延遲。如果新 Pod 被排程到了其他的節點，且原節點不存在可用 Pod 時，若負載均衡器路由規則沒有及時更新，那麼負載均衡器仍然會將流量轉發到原節點上，而這條路徑沒有可用後端，導致流量有損。

![9.jpeg](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/7f0115cb84da448a8b9d69f8c007a1dd~tplv-k3u1fbpfcp-zoom-1.image "9.jpeg")

此時，在 Pod 的 preStop 中配置 sleep 雖然能夠讓 Pod 在 LoadBalancer 後端更新前正常執行一段時間，但卻無法保證 kube-proxy 在 CCM 移除 LoadBalancer 後端前不刪除節點中 ipvs/iptables 規則的。場景如上圖所示，在 Pod 下線過程中，請求路徑 2 已經刪除，而請求路徑 1 還沒有及時更新，即使 sleep 能夠讓 Pod 繼續提供一段時間服務，但由於轉發規則的不完整，流量沒有被轉發到 Pod 就已經被丟棄了。

解決方案：

-   設定 externalTrafficPolicy 為 Cluster 能夠避免流量下線損失。因為 Cluster 模式下叢集所有節點均被加入負載均衡器後端，且節點中 ipvs 維護了叢集所有可用 Pod 列表，當本節點中不存在可用 Pod 時，可以二次轉發到其他節點上的 Pod 中，但是會導致二次轉發損耗，並且無法保留源 IP 地址。

-   設定 Pod 原地升級，透過為 Node 打特定標籤的方式，設定新 Pod 仍然被排程到本節點上。那麼該流程無需呼叫雲廠商 API 進行負載均衡器後端更新，流量進入後會轉發到新 Pod 中。

-   **Nginx Ingress 流量場景**

對於 Nginx Ingress，預設情況下流量是透過閘道器直接轉發到後端 PodIP 而非 Service 的 ClusterIP。在應用釋出過程中，Pod 下線，並由 Ingress Controller 監聽 Endpoint 變更並更新到 Nginx 閘道器的操作存在延遲，流量進入後仍然可能被轉發到已下線的 Pod，此時就會出現流量損失。

![10.jpeg](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/ae015c4424fe46fcaec2ec680e54ed76~tplv-k3u1fbpfcp-zoom-1.image "10.jpeg")

解決方案：

-   Ingress 註解“nginx.ingress.kubernetes.io/service-upstream”支援配置為“true”或“false”，預設為“false”。設定該註解為“true”時，路由規則使用 ClusterIP 為 Ingress 上游服務地址；設定為“false”時，路由規則使用 Pod IP 為 Ingress 上游服務地址。由於 Service 的 ClusterIP 總是不變的，當 Pod 上下線時，無需考慮 Nginx 閘道器配置的變更，不會出現上述流量下線有損問題。但需要注意的是，當使用該特性時流量負載均衡均由 K8s 控制，一些 Ingress Controller 特性將會失效，如會話保持、重試策略等。

-   在 Pod 的 preStop 設定 sleep 一段時間，讓 Pod 接收 SIGTERM 訊號前等待一段時間，允許接收並處理這段時間內的流量，避免流量損失。

-   **微服務流量場景**

在 Provider 應用釋出的過程中，Pod 下線並從註冊中心登出，但消費者訂閱服務端列表變更存在一定的延遲，此時流量進入 Consumer 後，若 Consumer 仍沒有重新整理 serverList，仍然可能會訪問到已下線的 Pod。

![11.jpeg](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/5b77877232d74b8cb42abed440511b6c~tplv-k3u1fbpfcp-zoom-1.image "11.jpeg")

對於微服務應用 Pod 的下線，服務註冊發現是透過註冊中心而非不依賴於 Endpoint，上述 endpoint-controller 移除 Endpoint 並不能實現 Pod IP 從註冊中心下線。僅僅在 preStop 中 sleep 仍然無法解決消費者 serverList 快取重新整理延遲問題。為了舊 Pod 能夠優雅下線，在 preStop 中需要首先從註冊中心下線，並能夠處理已經接收的流量，還需要保證下線前消費者已經將其客戶端快取的 Provider 例項列表重新整理。下線例項可以透過呼叫註冊中心介面，或在程式中呼叫服務框架所提供的介面並設定到 preStop 以達到上述效果，在 EDAS 中可以直接使用http://localhost:54199/offline：

```
lifecycle:
  preStop:
     exec:
       command:
         - /bin/sh
         - -c
         - curl http://localhost:54199/offline; sleep 30;
```

## 企業級一站式解決方案

上面我們對應用釋出過程中三種常用流量路徑的流量有損問題進行了原因分析並給出瞭解決方案。總的來說，為了保證流量無損，需要從閘道器引數和 Pod 生命週期探針和鉤子來保證流量路徑和 Pod 上下線的默契配合。EDAS 在面對上述問題時，提供了無侵入式的解決方案，無需更改程式程式碼或引數配置，在 EDAS 控制檯即可實現應用無損上下線。如下圖所示：

-   LB Service 支援配置外部流量策略（externalTrafficPolicy）

![12.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/dff5eb75a2094c54af40462dbe921b36~tplv-k3u1fbpfcp-zoom-1.image "12.png")

-   Nginx Ingress 支援配置註解：

nginx.ingress.kubernetes.io/service-upstream

![13.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/afb8a2e4685a46eb902bbe22a329cc35~tplv-k3u1fbpfcp-zoom-1.image "13.png")

-   微服務應用配置無損上線引數

![14.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/7bbefd7aa0a947a4b4f00e6dfad2bcfd~tplv-k3u1fbpfcp-zoom-1.image "14.png")

除此之外，EDAS 還提供了多種流量閘道器管理方式，如 Nginx Ingress、ALB Ingress、雲原生閘道器，也為應用的釋出提供了多種部署方式，如分批發布、金絲雀釋出，還提供了不同維度的可觀測手段，如 Ingress 監控、應用監控。在 EDAS 平臺管理應用，能夠輕鬆實現多種部署場景下的無損上下線。

K8s 有損釋出問題探究

相關文章