【編者的話】作爲事實上的容器雲標準，Kubernetes爲應用帶來了快速部署、快速迭代、快速擴縮容等便利，同時在簡化運維和提高硬件資源利用率等方面也有很大的優勢。但Kubernetes中應用的Pod IP是允許變化的，而且Pod使用Kubernetes內部虛擬網絡，Pod本身IP對外不可見，應用Pod出集羣數據包源IP地址使用的是其所在宿主機IP。在這種情況下，爲滿足對應用流量管控的要求，需要爲應用劃分專用的虛擬機節點，以虛擬機的IP區分應用進行流量管控，這不能充分發揮Kubernetes資源利用率方面的優勢。爲達到對應用Pod流量進行精細化管控的目的，提高Kubernetes資源利用率，我們對Kubernetes網絡和防火牆聯動方案進行探索。

Kubernetes網絡方案介紹

在介紹Kubernetes網絡與防火牆聯動方案之前，需要先簡單介紹一下Kubernetes的網絡方案。

Kubernetes網絡的基本設計原則是每個Pod都擁有唯一一個獨立的IP地址，用戶不需要額外考慮如何建立Pod之間的連接，也不需要考慮容器端口與宿主機端口映射等問題。Kubernetes並不具體去實現諸如給Pod分配IP、回收IP、記錄宿主機IP—Pod IP對應關係之類的細節，而是委託CNI實例去管理Pod的網絡資源併爲Pod建立互通能力。CNI（Container Network Interface）是一個標準的接口規範，其本身實現了一些基本的插件， 比如bridge、ipvlan、macvlan、loopback、vlan等網絡接口。

目前主流的容器網絡解決方案都有對應CNI的支持能力，比如Flannel、Calico、Weave、Contiv、SR-IOV、Amazon ECS CNI Plugins等。我行Kubernetes集羣使用的網絡插件即爲Flannel插件。一般來說，這些容器網絡插件的工作模式可從容器網絡流量穿越宿主機網絡的形態方面分爲兩種：

  • Overlay網絡：容器網絡的IP和MAC地址對宿主機網絡不可見，跨宿主機容器間通信需要將容器流量進行封裝轉發，而容器出集羣的流量需要進行SNAT轉換。Flannel的vxlan工作模式、Calico的IPIP模式均屬於該類型。
  • Underlay網絡：容器網絡對宿主機可見，在容器進行通信時不需要對流量進行封裝，直接建立路由表，根據規則進行路由轉發進行通信。Flannel的host-gw工作模式、Calico的BGP工作模式均屬於該類型。

目前我行使用的Fannel插件的VXLAN工作模式即屬於第一種方案。如下圖所示，在該模式下，Pod-1通過veth pair的方式連接到node1的cni0網橋上。在跟Pod-2通信時數據包首先通過cni0到達宿主機，根據宿主機路由規則（172.16.2.0/24 via 172.16.2.0 dev flannel.1 onlink）將數據包交給VTEP設備Flannel.1處理。然後，Flannel.1設備將數據包進行VXLAN封裝，在宿主機網絡中進行傳輸，待數據包到達Node2時再由Node2上的Flannel.1設備解封得到原始數據包並傳遞給Pod-2。

在該種模式下，跨宿主機Pod間的通信需要進行封裝傳輸，Pod的IP地址不會暴露在宿主機網絡，使得不同集羣可以使用同一個Pod地址池。但是，在該種模式下，除了Pod間跨宿主機通信會對原始消息進行封裝，Pod出集羣的數據包也會進行SNAT轉換，出集羣的所有Pod流量其源地址使用的均是宿主機IP地址，導致我們無法對單個Pod進行精確的流量管控。

Kubernetes網絡與防火牆聯動方案

爲達到對應用Pod流量進行精確管控的目的，第一，Pod數據流量需要可以區分；第二，Kubernetes中Pod的IP不是一直不變的，會隨着Pod的建立、銷燬、漂移等動作進行分配、回收、更新，這需要流量管控方隨時掌握Pod和IP的對應關係。對於第一個問題，我們考慮使用基於路由轉發方式的underlay容器網絡方案，將Pod的IP地址對外暴露。對於第二個問題，我們使用Kubernetes客戶端編寫 Kubemonitor工具對Pod的變動信息進行監控，並實時把變動信息發送給網絡防火牆更新策略。

基於路由轉發的容器網絡方案

行內Kubernetes平臺使用的Flannel網絡插件可以使用host-gw工作模式，該模式將宿主機作爲主機路由，對其上的Pod流量進行路由轉發，如圖所示：

在host-gw網絡模式下，Pod-1轉發給Pod-2的流量不再經過封裝，直接根據Node1的路由錶轉發至Node2傳遞到Pod-2。除此之外，要在集羣外監控Pod-1的流量包，還需Pod-1的IP地址對集羣外可見，需要配置Flannel的啓動參數 –ip-masq=false 使得出羣流量不經過SNAT轉換。

使用Flannel host-gw網絡模式，並且配置出集羣流量不經過SNAT轉換，除了需要網絡方面配置Pod IP地址的回程路由外，每個集羣將單獨需要一個地址段來作爲本集羣的Pod 網絡地址池。現用的VXLAN模式，集羣的IP地址池是一個子網掩碼爲16爲的虛擬地址段（172.16.0.0/16），該地址段最多支持256個集羣節點，每個節點上可以爲256個Pod分配IP地址。使用host-gw後，爲了區分Pod流量和配置Pod的回程路由，Pod網絡不能再使用虛擬地址段，且不同集羣間也不能共用同一個地址段。該種情況下如果繼續使用16位掩碼的地址段作爲Pod的IP地址池，會大量浪費行內IP地址段資源。爲避免該問題，可將集羣Pod網絡的地址池的子網掩碼調整爲18，這樣能在很大程度上減輕地址段的浪費。子網掩碼爲18的Pod地址段支持64個節點，每個節點支持256個Pod，可以滿足我行集羣需求。

Pod IP信息實時推送工具——Kubemonitor

要達到精細化管控Pod流量的目的，除了區分出Pod的流量，在Kubernetes中應用Pod會發生銷燬、重建、副本縮放、漂移等情況，應用的Pod數量和IP地址是會發生變化的，需要編寫自動化工具將Pod IP的變動信息實時推送防火牆開通策略。

如下圖所示，Kubemonitor主要包含以下幾個部分。

  • Kubernetes Client是Kubernetes集羣的開源客戶端，完成與Kuberetes集羣的連接、驗證、資源獲取、監聽等功能。該客戶端使用了Kubernetes統一的異步消息處理機制——List-Watch機制，其中List機制用於一次性獲取集羣資源最新的狀態，Watch機制用於監聽Kubernetes資源變動，在資源新建、更新、刪除時實時獲得最新信息。
  • Resources Controller 根據配置文件選擇監聽的集羣資源類型（Pod、Server、Statefultset、Deployment等），並調動Resources Manager模塊去處理所監聽資源的變動信息。
  • 當集羣資源的任何屬性值發生變化（如狀態、硬件資源申請量、網絡屬性等）Resources Controller都會監聽並獲取到，但這麼龐雜的變動信息不一定是我們關注的。在與防火牆聯動的需求中，我們其實主要關注（應用系統，Pod名稱，IP地址）這樣一個三元組信息，而對其餘的比如硬件資源申請量等並不關注。Resources Manager模塊主要用於去除無關變動信息，並按約定格式生成通知消息。
  • Interface模塊實現了與其他系統的對接接口。Kubemonitor通過Interface支持的接口類型（如Webhook、Kafka）將資源變動消息通知給所需系統。
  • Consensus Server共識服務。在容器環境部署需要考慮在Pod在被遷移、殺死、出錯時的產生的服務連續性問題。Kubemonitor通過多副本部署來實現高可用行。但是多副本部署時每個副本都會獨立監聽併發送資源變動信息，導致對接系統收到變動消息重複。爲此Kubeminitor使用分佈式一致性協議Raft實現了Consensus Server功能。Consensus Server負責監聽Kubemonitor副本的變化，選舉出Master節點與對接系統通信，同時負責同步Kubemonitor所有副本獲取到的資源變動信息的狀態。該共識服務模塊完成多副本部署時消息去重任務，且最多能容忍不多於一半的Kubemonitor副本掉線。
  • Kubemonitor的配置文件通過Config模塊進行管理。除了給防火牆通知Pod變動信息外，未來所有需要Kubernete集羣資源最新狀態的系統均可進行配置，通過Kubemonitor進行實時推送。

後記

該工作完成後，Kubernetes集羣內部東西向網絡性能將提升20%，並可在對Pod流量進行精細化網絡管控的前提下實現集羣內應用混合部署，極大提高硬件資源利用率。

Kubernetes網絡與防火牆聯動方案目前已經與網絡中心配合完成了前期的測試驗證工作，即將交付業務進行試用。該方案對於容器平臺來說除了涉及到Kubernetes集羣underlay網絡改造外，還要保證Kubemonitor推送消息的準確性和及時性；對於網絡方也要論證使用underlay方案後的Kubernetes集羣Pod地址段的劃分、Pod回程路由的建立和路由規則下發、以及針對Pod進行的防火牆策略更新等問題，這些問題需要雙方共同探索、論證、攜手推進。

原文鏈接： https://mp.weixin.qq.com/s/FRTXWvn_Q-CpZFGELjhGHA

相關文章