DevOps專題|玩轉Kubernetes網路

京東科技開發者發表於2020-01-17
dev

DevOps專題|玩轉Kubernetes網路

Kubernetes無疑是當前最火熱的容器編排工具，網路是kubernetes中非常重要的一環， 本文主要介紹一些相應的網路原理及術語，以及kubernetes中的網路方案和對比。 Kubernetes本身並不提供網路功能，只是把網路介面開放出來，透過外掛的形式實現。為了滿足不同的網路功能及需求，使容器在建立或銷燬時能夠容易地配置容器網路， CNI（Container Network Interface）應運而生， CNI旨在定義執行時和外掛之間的介面，在kubernetes中，CNI連線kubelet和網路外掛來為容器配置對應的網路設定。

1 背景

容器網路是容器選擇連線到其他容器、主機和外部網路的機制。在kubernetes網路模型設計中，往往需要每個Pod都擁有一個獨立的IP地址，而且假定所有的pod都在一個可以直接連通的、扁平的網路空間中。使用者不需要額外考慮如何建立Pod之間的連線，也不需要考慮將容器埠對映到主機埠等問題。所有節點都可在不用NAT的方式下同所有容器通訊，容器的地址和別人看到的地址是同一個地址。

2 技術術語

IPAM： IP地址管理；這個IP地址管理並不是容器所特有的，傳統的網路比如說DHCP其實也是一種IPAM，到了容器時代我們談IPAM，主流的兩種方法：基於CIDR的IP地址段分配地或者精確為每一個容器分配IP。但總之一旦形成一個容器主機叢集之後，上面的容器都要給它分配一個全域性唯一的IP地址，這就涉及到IPAM的話題。
Overlay： 在現有二層或三層網路之上再構建起來一個獨立的網路，這個網路通常會有自己獨立的IP地址空間、交換或者路由的實現。
BGP： 主幹網自治網路的路由協議，用於管理邊緣路由器之間資料包的路由方式。BGP透過考慮可用路徑，路由規則和特定網路策略，幫助弄清楚如何將資料從一個網路傳送到另一個網路。BGP有時被用作CNI外掛中的路由機制，而不是封裝的覆蓋網路。
封裝： 封裝是指在附加層中封裝網路資料包以提供其他上下文和資訊的過程。在overlay網路中，封裝被用於從虛擬網路轉換到底層地址空間，從而能路由到不同的位置（資料包可以被解封裝，並繼續到其目的地）。

3 CNI

Container Network Interface (CNI) 最早是由CoreOS發起的容器網路規範，是Kubernetes網路外掛的基礎。其基本思想為：Container Runtime在建立容器時，先建立好network namespace，然後呼叫CNI外掛為這個netns配置網路，其後再啟動容器內的程式。
CNI Plugin負責給容器配置網路，必須實現為由容器管理系統（rkt或者kubernetes)呼叫的可執行檔案，包括兩個基本的介面來配置網路：
配置網路: AddNetwork(net NetworkConfig, rt RuntimeConf) (types.Result, error)
清理網路: DelNetwork(net NetworkConfig, rt RuntimeConf) error
在Kubernetes中，kubelet決定了容器應該加入哪個網路以及它需要呼叫哪個外掛。然後外掛會將介面新增到容器網路名稱空間中，作為一個veth對的一側。接著它會在主機上進行更改，比如將veth的其他部分連線到網橋。再之後，它會透過呼叫單獨的IPAM（IP地址管理）外掛來分配IP地址並設定路由。

4 IPAM

以上CNI外掛解決了Pod內網路配置的問題，但是網路還有一個問題要解決的便是IP管理，為了解耦網路配置和ip管理， CNI定義了第二種型別的外掛-ip地址管理外掛（IPAM外掛）。
與CNI外掛一樣，IPAM外掛透過執行可執行檔案來呼叫。IPAM外掛負責為介面配置和管理IP地址。
CNI外掛在執行時呼叫IPAM外掛，IPAM外掛來確定介面IP /子網，閘道器和路由等資訊，從而在容器啟動時分配IP地址並配置網路，並將此資訊返回給CNI外掛，在刪除容器時再次呼叫它以清理這些資源。
IPAM外掛可以透過協議（例如dhcp），儲存在本地檔案系統上的資料，網路配置檔案的“ipam”部分或上述各項的組合來獲取資訊。

5 介紹兩種常見的k8s網路方案

flannel

flannel是CoreOS團隊設計的一個網路方案，以etcd作為儲存，給node上的每個容器分配全域性唯一的IP地址， 容器間透過overlay網路互相通訊。

DevOps專題|玩轉Kubernetes網路

Pod間通訊如下：
• Pod1和pod不在同一宿主機
資料從源容器中發出後，經由所在主機的docker0虛擬網路卡轉發到flannel0虛擬網路卡（veth pair），flanneld服務監聽在網路卡的另外一端，Flannel透過Etcd服務維護了一張節點間的路由表，利用etcd來管理可分配的IP地址段資源，同時監控etcd中每個Pod的實際地址，源主機的flanneld服務將原本的資料內容UDP封裝後根據自己的路由表投遞給目的節點的flanneld服務，資料到達以後被解包，然後直接進入目的節點的flannel0虛擬網路卡，然後被轉發到目的主機的docker0虛擬網路卡，最後就像本機容器通訊一下的有docker0路由到達目標容器。
• Pod1和Pod2在同一臺宿主機
Pod1和Pod2在同一臺主機的話，由Docker0網橋直接轉發請求到Pod2，不經過Flannel。

calico

DevOps專題|玩轉Kubernetes網路

Calico是一個純3層的資料中心網路方案，而且無縫整合像OpenStack這種IaaS雲架構，能夠提供可控的VM、容器、裸機之間的IP通訊。
透過將整個網際網路的可擴充套件IP網路原則壓縮到資料中心級別，Calico在每一個計算節點利用Linux Kernel實現了一個高效的vRouter來負責資料轉發，而每個vRouter透過BGP協議負責把自己上執行的workload的路由資訊像整個Calico網路內傳播——小規模部署可以直接互聯，大規模下可透過指定的BGP route reflector來完成。這樣保證最終所有的workload之間的資料流量都是透過IP路由的方式完成互聯的。
Calico節點組網可以直接利用資料中心的網路結構（無論是L2或者L3），不需要額外的NAT，隧道或者Overlay Network。
Calico還提供了豐富而靈活的網路Policy，保證透過各個節點上的ACLs來提供Workload的多租戶隔離、安全組以及其他可達性限制等功能。

6 k8s網路在雲翼的實踐

容器技術的誕生，伴隨自己諸多的優點被廣泛應用。容器消除了部署環境差異，保證了應用生命週期的環境一致性標準，高資源利用率和隔離性，以及快速部署的特性，給企業的生產提升了效率，節約了成本。
隨著京東雲業務的快速增長，業務部署不能再侷限於物理機、虛擬機器等傳統的方式， 雲翼早在2017年就開始了容器方向的探索之路，我們發現容器背後的理念很超前，但現實中生產環境有許多存量的業務，無法與之匹配，理念上是有一些差異， 如社群的容器倡導one process one container（在容器中只執行一個應用）。
雲翼作為京東雲DevOps平臺，提供了集部署、運維、監控、日誌等諸多功能，這些功能實現大多都是需要在例項內部署Agent與對應的服務通訊，而例項如何標識到自身往往是使用IP的方式，容器在內部落地的一個很強烈的需求就是能夠固定IP，使運維或者開發能方便登入容器排查問題；另外很大一部分存量的業務架構依賴固定IP；還有內部的一些基礎系統都是透過IP來過濾，例如接入/LB 等後端需要填寫IP地址。容器在內部的落地，不能完全不考慮存量業務的相容性，很難放棄原有的技術體系， 我們希望容器的引用能減輕上手成本，能更貼近傳統運維的習慣，為了方便管理，我們把容器的網路和機房的內網放在一個平坦的網路。
我們開發了ipamD，大概的實現原理是pod每次建立時呼叫IPAMclient去請求ipamD申請地址， ipamD是一個常駐程式，維護了各個應用下對應分組的地址資訊，透過pod字首名可以查到對應例項的IP，透過這種方式實現了IP地址固定的需求。
另外為了降本增效，提升並滿足一些業務方的特定需求，希望容器能夠跑在京東雲的虛擬機器上以方便管控相關的業務，我們開發了相應的網路外掛來滿足在雲主機中執行容器的需求，使雲翼的使用者能無差別的使用IaaS的資源。
雲主機上的CNI外掛藉助彈性網路卡、路由策略實現了：
  1. 所有容器可以不需要NAT雙向互通
  2. 所有容器到Node可以不需要NAT雙向互通，反之亦然

DevOps專題|玩轉Kubernetes網路

（圖片來自）
注：具體實現可參考 amazon-vpc-cni-k8s()
雲翼藉助 docker/k8s 大幅提升了開發、測試、運維的生產力，簡化了人工和自動系統管理工作。 如果你想了解更多關於京東雲翼，歡迎點選“ 閱讀 ”~
歡迎點選“ 京東雲 ”瞭解更多精彩內容

DevOps專題|玩轉Kubernetes網路

DevOps專題|玩轉Kubernetes網路


來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/69912185/viewspace-2673749/，如需轉載，請註明出處，否則將追究法律責任。

相關文章