歡迎光臨
每天分享高質量文章

灰度發佈在 UCloud 大規模虛擬網絡中的應用

本文主要詳細闡述了在 UCloud 的虛擬網絡里,如何利用 ServiceMesh 技術在虛擬網絡控制面以及利用可編程交換機在轉發麵實現灰度發佈。
— 徐亮


致謝

 作者 | UCloud / 徐亮

本文主要詳細闡述了在 UCloud 的虛擬網絡里,如何利用 ServiceMesh 技術在虛擬網絡控制面以及利用可編程交換機在轉發麵實現灰度發佈。

ServiceMesh 實現控制麵灰度

在控制面,早期灰度發佈採用 APIGW 的方式實現。APIGW 通常僅部署在用戶流量的入口,完全灰度發佈就需要完整地部署兩套系統。但在微服務化的時代,任何一個微服務發生變更都需要完整地部署兩套系統,這不僅成本高且嚴重影響產品變更速度。ServiceMesh 以類似於將 APIGateway 部署到本地,同時提供集中化控制的方式,完美地解決了這些問題。 

UCloud 的輕量級 ServiceMesh 平臺基於 Istio,繼續使用 Envoy 代理,修改 Pilot 在保留完整的 DSL 支持的基礎上實現了脫離 K8S 運行。

因此網絡團隊對 Pilot 做了高度定製,從而更能滿足自身的需求。

◈ 定製方案一:按賬號灰度。在 GRPC 或者 HTTP 請求中添加自定義 Header x-ucloud-routebyx-ucloud-routeby 採用 Cookie 的編碼格式,在其中包含賬戶信息,配置 Envoy 根據該 Header 進行策略路由。
◈ 定製方案二:採用顯式代理而不是 IPTables 透明引流的方式和 Envoy 集成,支持 HTTP 1.0、HTTP 2.0 和 gRPC。在配置了 Envoy 的 Proxy Port 情況下,通過 Envoy 接入 ServiceMesh;如果配置域名且沒有配置 Envoy 的 Proxy,則自動採用 ETCD gRPC 命名與發現的方式;如果配置 IP 地址和端口,則直連指定地址。
◈ 定製方案三:採用 docker-compose 管理容器實現 sidecar。新方案中仍然採用容器的方式打包和部署微服務,但採用 Host 的網絡方式簡化了現存服務的網絡通信方式。通過這種方式實現了一個簡單的服務管理、版本管理、集群管理、路由策略管理層,為集群中的每台 Node(虛擬機或物理服務器)生成 docker-compose 配置檔案,從而部署和管理每台 Node 的服務。

可編程交換機實現轉發麵灰度

在轉發麵灰度的方案選擇上,團隊採用了可編程交換機(基於 Barefoot Tofino 芯片)來實現灰度網關,替換普通交換機實現強灰度能力。 

灰度網關最大提供 64 個 100G 的接口、6.4T 帶寬,PPS 性能可達 4400 兆,延遲為 us 級別,能夠很好支持網絡寬帶的高性能要求。灰度網關可以提供:一致性哈希 ECMP 的能力;可以基於任意定製欄位(包括內層虛擬網絡地址以及租戶 ID)計算哈希;在計算哈希前優先應用灰度規則,可以根據任意欄位定製灰度規則,最小粒度可以做到按 TCP 流來灰度。

轉發麵灰度示例

有了上述這些新工具,可以通過部署新的策略實現更加細粒的灰度發佈,具體方案為:可編程交換機 BGP 宣告集群 VIP 引流,根據選擇欄位計算一致性哈希後將流量量分發給後端服務器,並按照選擇欄位(VNI、源地址、目的地址)配置灰度規則。

灰度步驟如下:

1. 按 VM 的粒度將流量量切換到灰度後端服務器器;
2. 切換完成後立刻自動回歸測試,根據路由表自動生成監測地址串列,並 Ping 檢測網絡互通性;
3. 測試通過則逐步增加灰度的VM地址;
4. 直到整個 VPC 的流量量全部切換到灰度後端服務器器;
5. 再切換一個新的 VPC,直到所有分片內的 VPC 都切換到新的灰度後端服務器;
6. 完成灰度發佈。

以上內容最早發表於 UCloud 10 月 12 日在上海主辦的 Tech Talk 第一期活動。Tech Talk 是 UCloud 面向用戶做深度技術交流的線下活動,後面也會繼續舉辦,歡迎參加。

赞(0)

分享創造快樂