自從2012年正式成立，經過10的建設與發展，天翼云數據中心已經覆蓋了全國所有主要城市，滿足政府、教育、醫療和大中企業關鍵業務上云的需求。隨著越來越多的多可用區資源池的上線，天翼云的基礎設施建設也在計算資源利用，運維，開發效率等方面遇到了挑戰。隨著云原生轉型概念的流行，天翼云也積極擁抱變化，積極加入到向云原生的隊伍中。

天翼云基礎設施向云原生主要為了以下幾個目的:

• 控制成本：通過將基礎設施控制面的應用容器化部署，同時引入統一的部署與調度平臺，更加合理的分配部署應用的資源。配合容器集群的彈性伸縮機制，提高資源利用率，進一步降低了計算資源使用與運維的成本
• 提升效率：在業務應用的開發與發布方面，引入了標準化的發布工具與持續集成平臺，實現應用在云平臺上的快速部署，發布與升級。通過小步快跑的方式提高開發和發布效率
• 保證質量：通過提高底座平臺的可觀測性并建設全方位的監控告警體系，提前發現問題隱患，提高平臺上業務運行穩定性，從而保證服務質量

背景與云原生網絡的需求

天翼云底座在向云原生轉型道路上的第一步是將所有線上線下業務進行容器化改造，并滿足天翼云規模和業務上的特殊需求。為此天翼云云原生團隊對 Kubernetes 集群的各個組件進行了深度定制，形成了包含容器集群，可視化運維與監控，應用發布與部署的一體化集群底座。集群底座目前已經支撐了天翼云在全國60多個資源池中基礎設施的控制面和各種離在線業務的運行。天翼云基礎設施從2019年開始全面的容器化改造，到目前為止已經完成了90%業務的容器化，并運行在容器底座上。

天翼云容器底座網絡也在業務容器化改造過程中向更加云原生的方向發展。 天翼云基礎設施的業務規模以及網絡架構，對容器底座集群的網絡提出了更多要求。首先是天翼云遍布全國的多地域多可用區中集群的組網需求。天翼云有遍布全國的數據中心，并且有 IDC 的 VLAN 網絡與 SDN 提供的 VPC 兩種節點網絡。 容器底座要求容器集群能夠跨可用區部署，并且無論是處于數據中心或是處于邊緣機房的集群中的業務都能夠用容器 IP 直接進行通信。

那么容器底座集群的云原生網絡還面臨哪些挑戰呢？

首先是天翼云數據中心中異構網絡環境的適應性問題。集群底座的節點可以是物理服務器，用于承載像是虛擬化等對計算資源有較高要求的業務。這些節點所處的網絡一般是由VLAN進行隔離的物理網絡。另外一部分集群節點使用了虛擬機實例，用于運行一些相對來說不太重要，但有彈縮需求的離線業務。這類節點處在 SDN 虛擬化的 VPC 網絡中。底座要求集群網絡方案能夠連通處于兩種網絡架構節點中的容器，并且能夠對集群用戶向上屏蔽掉這兩種網絡的差異。

其次是跨集群的容器之間，以及容器與虛擬機之間的網絡連通性問題。社區普遍的容器集群網絡方案中，容器的 IP 地址一般來自集群的一個內網網段，這個網段中的地址只在集群內部有意義，不能從集群外直接訪問。但在天翼云的集群底座網絡中，要求某些在集群外以非容器化部署的應用，能夠直接用容器的 IP 訪問集群內的業務。同時不同集群中的業務，也要能夠用對方集群的容器IP直接訪問其他集群中的業務，這就對容器 IP 地址的固定與唯一性，以及跨集群的容器網絡打通提出了更高的要求。

再就是容器網絡的性能問題。首先是避免容器網絡在跨節點通信時使用的隧道封包。在 IDC 的 VLAN 網絡中，我們可以通過使用 Underlay 容器網絡，將容器的網卡直接接入宿主機網卡所在的交換機，獲得宿主機所在網段的 IP 地址來解決這個問題。在虛擬機節點網絡中，由于出于安全考慮，VPC 網絡一般不會放開偽傳輸和端口欺詐這樣的選項，所以只能將容器的網卡掛載到分配給宿主機的額外的彈性網卡上。使用這兩種方法可以使物理機和虛擬機節點中的容器，獲得接近于宿主機網卡的網絡性能，并且能夠分配與宿主機同一子網中的 IP 地址，達到從集群外直接用容器 IP 訪問容器內業務的效果。但這兩種方案也有一定的缺點，就是對IP地址，彈性網卡這樣的網絡資源的消耗。由于天翼云的容器集群節點數量通常比較大，如果無論容器對網絡的吞吐或者訪問的需求一律接入宿主機所在的網絡，無疑是對 IP 地址和彈性網卡的巨大浪費。所以容器底座還要求集群網絡能夠同時兼容 Overlay 網絡，提高容器集群的兼容性和可擴展性。另外還需要支持容器掛載智能網卡，優化內核參數，利用 dpdk，eBPF 等高級內核功能，來加速容器網絡。

最后是對集群網絡的可觀測性，可運維性以及易用性的要求。同時還要支持指定節點作為集群出網流量的網關。充分利用天翼云其他成熟的網絡產品，例如負載均衡，云路由器，來擴展容器集群的功能，同時避免重復造輪子。

天翼云底座容器網絡的云原生建設

然后我們帶著上面的挑戰與需求投入到了容器集群底座的建設當中。下圖是在天翼云容器底座的架構中，我們投入建設工作的部分組件：

首先容器底座集群構建在天翼云各種基礎設施之上，在單個底座集群當中，我們從下到上的利用內核的高級選項，將容器網絡的 QoS， Underlay/Overlay 網絡，網卡直通等需求，最終實現在了自研 CNI 插件中。同時通過天翼云在集群外提供的其他能力，例如負載均衡，網關，以及自研的跨集群的服務發現的 DNS 方案，提供集群到集群，外部到集群的訪問打通方案。

為此天翼云云原生團隊自主研發了集群底座專用的網絡插件：CTCNI。相較于常見的開源 CNI 項目，CTCNI 實現了以下的特色功能：

• 同時兼容 VLAN 與 VPC 兩種節點網絡，并能夠根據節點所在網絡類型，決定容器網卡的掛載方式
• 在 VLAN 網絡中支持 Underlay 容器網絡，在 VPC 網絡中支持容器掛載節點的彈性網卡。達到容器與宿主機處于同一網絡的目的。
• 同時支持 Overlay 網絡，這也是容器的默認掛載選項。在滿足大多數容器的網絡需求時，盡量降低對IP地址，彈性網卡等網絡資源的消耗
• 支持智能網卡，使用了 dpdk，eBPF 等內核技術加速了容器網絡棧
• 自動配置天翼云的負載均衡，云路由器等產品，擴展集群網絡功能

CTCNI 的一個重要應用場景是打通服務器中非容器化部署的應用對集群內容器化應用的訪問。雖然 Kubernetes 集群原生提供了諸如 Ingress，NodePort 等方案將集群內服務暴露到集群外，但在天翼云底座的云原生改造過程中，用戶還是希望能夠保留之前使用習慣，用固定的 IP 地址和端口訪問容器化的應用服務。為此 CTCNI 通過將容器掛載彈性網卡，或者使用 Underlay 網絡分配給容器宿主機所在網絡的 IP，讓集群外應用能用直接用這個 IP 地址訪問到容器提供的服務：

另外為了還支持了在同一個集群內，Underlay，Overlay 和 彈性網卡三種網絡并存。容器根據自己所在節點的網絡類型，以及自己對網絡功能需求，選擇其中之一。下圖中節點1和節點2中的容器處于集群中的 Overlay 網絡，使用了集群內網段的 IP 地址，沒有使用彈性網卡或者宿主機網絡 IP。而節點3的容器則通過 Underlay 網絡與宿主機處于同一子網，它的 IP 地址可以直接從集群外部訪問到：

除了 CTCNI 內部實現的豐富功能以外，天翼云還提供了豐富的網絡功能，例如負載均衡，彈性公網地址以及云路由器。利用這些外部產品，可以方便的擴展底座容器網絡的功能。例如在前面提到的，容器底座集群有跨地域集群的互訪需求，這可以在兩個集群之間配置云路由器的路由規則來實現，達到兩個集群間使用對方的容器 IP 來進行互訪：

另外利用將彈性公網 IP 與固定的容器 IP 進行綁定，可以將容器內服務暴露給集群外的用戶。利用彈性公網 IP 加負載均衡器的方式，可以在其后端綁定多個容器，配合健康檢查可以達到流量分流與高可用的效果：

雖然使用 Underlay 網絡或者彈性網卡避免跨節點隧道的封解包，已經讓容器獲得了近似與宿主機網卡的網絡延遲與吞吐帶寬。但是依然額外的使用了 veth 虛擬網卡對，Linux 網橋，iptables 這樣的內核子系統來實現容器網卡，流量轉發等功能，最終還是加長了容器網絡棧的處理鏈路。為了進一步優化容器網絡的性能， CTCNI 利用了  eBPF 這樣的內核技術，對訪問集群內容器服務的場景做出了優化。通過在容器網卡發送數據的鏈路中注入 eBPF 程序，直接將 Service IP 轉換成后端容器的 IP 地址，從而繞過了 iptables 或者 ipvs 的規則匹配。另外對于容器直接訪問集群外服務，或者集群外服務直接訪問容器的場景，CTCNI 也通過將內核中的網絡棧的處理工作，卸載到宿主機的智能網卡上，或者直接由應用程序包含進 dpdk，繞過內核的網絡棧處理鏈路，進一步優化容器網絡性能。

容器底座網絡云原生化的落地實踐

在底座集群網絡的云原生化實踐過程中，我們也遇到了一些在需求整理和建設初期未曾考慮到的問題。下面將從易用性，擴展性，可觀測性三方面進行介紹。

易用性問題

首先遇到的是易用性問題。基于 CTCNI 的容器網絡功能豐富，并且涉及了與眾多類型的網絡資源的交互。從功能方面講，CTCNI 就支持了容器固定 IP，同時支持 Overlay 和 Underlay 網絡，以及容器掛載智能網卡或者宿主機的彈性網卡等多種選擇；而從涉及的網絡資源方面看，又包含了 VPC，子網，彈性網卡，彈性 IP，路由規則等資源。要正確的配置這些資源來實現 CTCNI 豐富的功能，對云原生團隊的開發者來說已經并非易事，對真正用戶來說更是心智負擔。例如要將一組容器通過負載均衡向集群外暴露，最初就需要手動的創建和配置負載均衡，監聽器，監控檢查，目標組等資源來達到目的。為了對用戶屏蔽掉繁瑣重復的配置流程將用戶從中解放出來，但又同時對用戶保持配置狀態的透明，云原生團隊決定使用聲明式的方案配置和管理這些網絡資源。我們各種網絡資源類型擴展成為 Kubernetes 集群的資源，并為每種資源開發相應的 Operator，將資源的配置工作根據期望的狀態由 Operator 調用天翼云平臺的 OpenAPI 自動完成。用戶只需要在容器工作負載中聲明希望如何暴露服務，一切資源就會被自動創建和配置，用戶也可以查詢這些資源的狀態。

跨集群的服務發現

其次是跨集群的服務發現問題，因為天翼云容器底座要求集群容器可以跨集群用容器 IP 直接通信。而從服務名到容器 IP 的轉換有兩種方法:

• 用 Nacos 這樣的服務注冊和發現方案，中心化的提供服務名到 IP 地址的查詢服務。但這要求使用方編寫查詢邏輯的代碼，有一定侵入性
• 實現一個全局的 DNS 服務，作為所有集群的 DNS 上游服務器，負責服務名到 IP 地址的解析工作。但這也有服務不穩定，延遲大，因為緩存原因解析結果不準確等問題

而且兩種方案都需要服務提供方以某種方式將域名和 IP 注冊，雖然容器 IP 地址可以固定，但仍然是一種心智負擔。所以天翼云云原生團隊實現了自己的解決方案：CTDNS。為了解決自動服務注冊的問題，CTDNS 的方法是：

1. 運行一個中心化的 Nacos 集群，用于服務注冊和發現
2. 在集群中運行一個 Mutation Webhook，監聽并判斷一個容器是否需要將其 IP 和域名注冊到 Nacos。如果是，則向 Pod 注入一個初始化容器。
3. 初始化容器在運行時獲取域名與容器的 IP 地址，并向 Nacos 注冊。

而為了解決服務發現的問題，CTDNS 在集群中運行了另一個 DNS 服務，設置成為了集群 CoreDNS 的上游服務器。該DNS服務器監聽 Nacos 集群所有記錄的更新，并將解析記錄緩存在本地。當集群中容器有解析需求時，會立即返回給 CoreDNS 最新的解析結果。

上面介紹的CTDNS 注冊和解析服務的工作流程大致如下圖所示：

集中式出集群網關

在一般的集群容器網絡的實現中，容器訪問集群外的服務的出網節點是當前的宿主機節點。在 Underlay 和彈性網卡作為容器網卡的方案中，由于容器 IP 來自于宿主機網絡網段且是唯一的，可以使用安全組來對其進行限制。在 Overlay 網絡中，服務端看到的請求源 IP 就是當前節點的 IP。容器底座出于安全，流量審計以及對請求來源IP設置白名單的需求，要求集群所有的出網流量通過指定的節點流出集群，并支持出網節點的高可用。CTCNI 根據對出網網關這樣的擴展資源的配置，通過配置每個節點上的流表，實現了這個功能。

可觀測性

雖然網絡資源聲明式的管理方式可以向用戶和運維人員展示資源的當前狀態。但是對于集群中每個節點和容器的網絡狀態和各種實時指標，需要進行額外的采集和展示，來提高底座容器網絡的可觀測性。通過在每個節點運行專門的網絡指標的 exptor，將網絡控制平臺信息以及數據平面質量信息以 Prometheus 所支持的格式對外暴露，并由 Dashboard 進行可視化的展示。同時天翼云的統一監控平臺也會監控相關指標，并對異常進行告警。

總結

天翼云容器底座目前已經支撐了天翼云60個線上資源池業務的運行。從功能上將，它兼容了各地異構的主機網絡，支持跨集群的容器之間訪問。通過自研的跨集群服務發現機制與天翼云的其他網絡產品，擴展了云原生網絡功能。在性能上，通過 eBPF，dpdk，智能網卡卸載等方案，進一步提升了容器網絡的性能。在易用性和可觀測性上，更以聲明式和指標可視化的方式，使天翼云容器底座網絡以更加云原生的方式工作。