<object id="3iwlw"><noframes id="3iwlw"></noframes></object>

      <th id="3iwlw"></th>

    1. <rp id="3iwlw"></rp>
      <rp id="3iwlw"></rp>

    2. <button id="3iwlw"></button>
      云計算·大數據 頻道

      Kubernetes網絡的可視化指南

        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服務的唯一方式。

        發布服務的ServiceTypes:

        Kubernetes服務提供了一種訪問一組Pod的方法,通常通過使用標簽選擇器來定義。這可能是應用程序試圖訪問集群中的其他應用程序,也可能允許你將集群中運行的應用程序公開給外部世界。Kubernetes ServiceTypes允許你指定所需的服務類型。

        不同的ServiceTypes包括:

        ClusterIP:這是默認的ServiceType。它使服務只能從集群內訪問,并允許集群內的應用程序相互通信。沒有外部訪問。

        LoadBalancer:此服務類型使用云提供商的負載均衡器對外公開服務。來自外部負載均衡器的流量被定向到后端POD。云提供商決定如何實現負載均衡。

        NodePort:這允許外部通信通過在所有節點上打開特定端口來訪問服務。然后,發送到此端口的任何流量都會轉發到該服務。

        ExternalName:這種類型的服務使用ExternalName字段的內容,通過返回CNAME記錄及其值,將服務映射到DNS名稱。未設置任何類型的代理。

        網絡軟件

        只要你了解所使用的技術,Kubernetes內部的網絡與物理世界中的網絡沒有太大區別。好好學習,記住網絡基礎知識,就可以輕松實現容器、Pod和服務之間的通信。

      0
      相關文章
        漂亮的苏酥全文阅读