Kubernetes內部的網絡與物理世界中的網絡沒有太大區別。有了網絡基礎知識，你就可以輕松實現容器Pod和服務之間的通信。
從使用交換機、路由器和以太網電纜的物理網絡轉移到使用軟件定義網絡(SDN)和虛擬接口的虛擬網絡需要一段輕微的學習曲線。當然，原則保持不變，但有不同的規范和最佳實踐。Kubernetes有自己的一套規則，如果你處理的是容器和云，這有助于了解Kubernetes網絡是如何工作的。
Kubernetes網絡模型有一些需要記住的一般規則：
每個pod都有自己的IP地址：不需要在Pod之間創建鏈接，也不需要將容器端口映射到主機端口。不需要NAT：節點上的Pod應該能夠與沒有NAT的所有節點上的所有Pod通信。代理獲得所有訪問權限：節點(系統守護進程、Kubelet)上的代理可以與該節點中的所有Pod通信。共享命名空間：Pod中的容器共享網絡命名空間(IP和MAC地址)，因此它們可以使用環回地址相互通信。Kubernetes網絡解決了什么問題Kubernetes網絡旨在確保Kubernetes中的不同實體類型可以通信。Kubernetes基礎設施的布局在設計上有很多分離。命名空間、容器和Pod旨在保持組件彼此不同，因此高度結構化的通信計劃非常重要。
容器到容器的網絡容器到容器的網絡通過Pod網絡命名空間進行。網絡命名空間允許你擁有獨立的網絡接口和路由表，這些接口和路由表與系統的其余部分隔離并獨立運行。每個Pod都有自己的網絡命名空間，其中的容器共享相同的IP地址和端口。這些容器之間的所有通信都是通過localhost進行的，因為它們都是同一命名空間的一部分。(由圖中的綠線表示。)
Pod到Pod的網絡對于Kubernetes，每個節點都有一個指定的用于Pod的CIDR IP范圍。這確保每個Pod都能收到集群中其他Pod可以看到的唯一IP地址。創建新Pod時，IP地址從不重疊。與容器到容器的網絡不同，Pod到Pod的通信使用真實的IP進行，無論你是將Pod部署在同一節點上還是集群中的不同節點上。
上圖顯示，為了使Pod相互通信，流量必須在Pod網絡命名空間和根網絡命名空間之間流動。這是通過虛擬以太網設備或veth對(圖中veth0到Pod命名空間1，veth1到Pod命名空間2)連接Pod命名空間和根命名空間來實現的。虛擬網橋連接這些虛擬接口，允許通信使用地址解析協議(ARP)在它們之間流動。
當數據從Pod 1發送到Pod 2時，事件流為：
Pod 1流量通過eth0流向根網絡命名空間的虛擬接口veth0。然后，流量通過veth0到達連接到veth1的虛擬網橋。流量通過虛擬網橋到達veth1。最后，流量通過veth1到達Pod 2的eth0接口。Pod到服務的網絡Pod很動態。它們可能需要根據需求擴大或縮小規模。在應用程序崩潰或節點故障的情況下，可以再次創建它們。這些事件會導致Pod的IP地址發生變化，這將給聯網帶來挑戰。
Kubernetes通過使用Service功能來解決此問題，該功能執行以下操作：
在前端分配靜態虛擬IP地址，以連接與服務關聯的任何后端吊艙。負載將尋址到此虛擬IP的所有流量平衡到后端Pod集。跟蹤Pod的IP地址，這樣即使Pod IP地址更改，客戶端也不會有任何問題，因為它們只直接連接到服務本身的靜態虛擬IP地址。集群內負載均衡有兩種方式：
IPTABLES：在這種模式下，kube-proxy監視API服務器中的更改。對于每個新服務，它都會安裝iptables規則，這些規則將流量捕獲到Service的clusterIP和端口，然后將流量重定向到服務的后端Pod。Pod是隨機選擇的。此模式可靠，系統開銷較低，因為Linux Netfilter處理流量時不需要在用戶空間和內核空間之間切換。IPV：IPV構建在Netfilter之上，并實現傳輸層負載均衡。IPVS使用Netfilter鉤子函數，使用哈希表作為底層數據結構，并在內核空間中工作。這意味著IPVS模式下的kube代理比iptables模式下的kube代理具有更低的延遲、更高的吞吐量和更好的性能來重定向流量。上圖顯示了從Pod 1到Pod 3的包流通過Service到不同節點(以紅色標記)。前往虛擬網橋的包必須使用默認路由(eth0)，因為網橋上運行的ARP無法理解該服務。之后，包必須通過iptables進行過濾，iptables使用kube代理在節點中定義的規則。因此，該圖顯示了當前的路徑。
Internet到服務的網絡到目前為止，已經討論了如何在集群內路由流量。然而，Kubernetes網絡還有另一面，那就是將應用程序暴露于外部網絡。
你可以通過兩種不同的方式將應用程序公開給外部網絡。
出口：當你想要將流量從Kubernetes服務路由到Internet時，請使用此選項。在這種情況下，iptables執行源NAT，因此流量似乎來自節點，而不是Pod。入口：這是從外部世界到服務的傳入流量。入口還允許并阻止使用連接規則與服務進行的特定通信。通常，有兩種入口解決方案在不同的網絡堆棧區域上運行：服務負載均衡器和入口控制器。發現服務Kubernetes發現服務有兩種方式：
環境變量：在Pod運行的節點上運行的kubelet服務負責以{SVCNAME}\u service\u HOST和{SVCNAME}\u service\u PORT的格式為每個活動服務設置環境變量。你必須在客戶端Pod出現之前創建服務。否則，這些客戶端Pod將不會填充其環境變量。DNS：DNS服務實現為Kubernetes服務，映射到一個或多個DNS服務器Pod，這些Pod與任何其他Pod一樣進行調度。集群中的Pod配置為使用DNS服務，DNS搜索列表包括Pod自己的命名空間和集群的默認域。集群感知DNS服務器(如CoreDNS)監視Kubernetes API以獲取新服務，并為每個服務創建一組DNS記錄。如果在整個集群中啟用了DNS，則所有Pod都可以根據其DNS名稱自動解析服務。Kubernetes DNS服務器是訪問ExternalName服務的唯一方式。發布服務的ServiceTypesKubernetes服務提供了一種訪問一組Pod的方法，通常通過使用標簽選擇器來定義。這可能是應用程序試圖訪問集群中的其他應用程序，也可能允許你將集群中運行的應用程序公開給外部世界。Kubernetes ServiceTypes允許你指定所需的服務類型。
不同的ServiceTypes包括：
ClusterIP：這是默認的ServiceType。它使服務只能從集群內訪問，并允許集群內的應用程序相互通信。沒有外部訪問。LoadBalancer：此服務類型使用云提供商的負載均衡器對外公開服務。來自外部負載均衡器的流量被定向到后端POD。云提供商決定如何實現負載均衡。NodePort：這允許外部通信通過在所有節點上打開特定端口來訪問服務。然后，發送到此端口的任何流量都會轉發到該服務。ExternalName：這種類型的服務使用ExternalName字段的內容，通過返回CNAME記錄及其值，將服務映射到DNS名稱。未設置任何類型的代理。網絡軟件只要你了解所使用的技術，Kubernetes內部的網絡與物理世界中的網絡沒有太大區別。好好學習，記住網絡基礎知識，就可以輕松實現容器、Pod和服務之間的通信。
X 關閉
X 關閉