Kubernetes網絡的原理是什么

本文小編為大家詳細介紹“Kubernetes網絡的原理是什么”，內容詳細，步驟清晰，細節處理妥當，希望這篇“Kubernetes網絡的原理是什么”文章能幫助大家解決疑惑，下面跟著小編的思路慢慢深入，一起來學習新知識吧。

Part.1 Kubernetes 網絡原理及挑戰

1. Kubernetes Pod 設計

Pod 是 Kubernetes 的基本調度單元，我們可以將 Pod 認為是容器的一種延伸擴展，一個 Pod 也是一個隔離體，而 Pod 內部又包含一組共享的容器。

每個 Pod 中的容器由一個特殊的 Pause 容器，及一個或多個緊密相關的業務容器組成。Pause 容器是 Pod 的根容器，對應的鏡像屬于 Kubernetes 平臺的一部分，以它的狀態代表整個容器組的狀態。同一個 Pod 里的容器之間僅需通過 localhost 就能互相通信。

每個 Pod 會被 Kubernetes 網絡組件分配一個唯一的（在集群內的 IP 地址，稱為 Pod IP，這樣就允許不同 Pod 中的服務可以使用同一端口 (同一個 Pod 中端口只能被一個服務占用)，避免了發生端口沖突的問題。

2. 挑戰

Pod 的 IP 是在 Kubernetes 集群內的，是虛擬且局域的。這就帶來一個問題，Pod IP 在集群內部訪問沒有問題，但在實際項目開發中，難免會有真實網絡環境下的應用需要訪問 Kubernetes 集群里的容器，這就需要我們做一些額外的工作。

本文將結合我們開發環境下基于 K8S 容器網絡演進的過程，介紹在 Pod IP 為虛擬或真實 IP 情況下的幾種直接訪問 Pod IP 的解決方案。

Part.2 基于 Kubernetes 的容器網絡演進

第一階段：Kubernetes + Flannel

最早，我們的網絡設計方案只服務于大交通業務。初期大交通的 Java 應用是部署在物理機上的，團隊內部容器相關的底層基礎設施幾乎為 0。為了更加平穩地實現容器化的落地，中間我們沒有直接把服務全部遷移到 K8S 中去，而是經歷了一段混跑。

這個過程中必然會有物理機上的 Java 應用訪問 K8S 里 Java 容器的情況 (一個注冊中心)。當時我們選用的網絡架構是 Flannel VXLAN + Kube-proxy，主要是考慮到 Flannel 的簡潔性。

Flannel 是為 K8S 設計的一個非常簡潔的多節點三層網絡方案，主要用于解決容器的跨主機通信問題，是一個比較大一統的方案。它的設計目的是為集群中的所有節點重新規劃 IP 地址的使用規則，從而使得不同節點上的容器能夠獲得「同屬一個內網」且「不重復的」IP 地址，并讓屬于不同節點上的容器能夠直接通過內網 IP 通信。

Flannel 的原理是為每個 host 分配一個 subnet，容器從此 subnet 中分配 IP，這些 IP 可以在 host 間路由，容器間無需 NAT 和 port  mapping 就可以跨主機通信。每個 subnet 都是從一個更大的 IP 池中劃分的，Flannel 會在每個 host 上面運行一個守護進程 flanneld，其職責就是從大池子中分配 subnet，為了各個主機間共享信息。Flannel 用 ETCD 存放網絡配置、已分配的 subnet、host 的 IP 等信息。

Flannel 的節點間有三種通信方式：

• VXLAN：默認配置，利用內核級別的 VXLAN 來封裝 host 之間傳送的包

• Host-gw：二層網絡配置，不支持云環境，通過在 host 的路由表中直接創建到其他主機 subnet 的路由條目

•  UDP：通常用于 debug

我們在所有的業務物理機上都部署了 Flannel，并且啟動 Flanneld 服務，使之加入 K8S 虛擬網絡，這樣物理機上的服務與 K8S 里的容器服務在互相調用時，就可以通過 Flannel+Kube-proxy 的虛擬網絡。整體結構圖如下：

• 我們在集群的 middleware 空間下以 nodeport 的方式部署了 VPN Server，并給客戶端分配了 10.140 的網段

• 當客戶端通過 172.18.12.21:30030 撥通 VPN 時，客戶端與 VPN Server 間的網絡被打通

• 因為 VPN Server 本身處于集群虛擬網絡環境中，所以其他容器的 IP 對于 vpn server 是可見的，因此撥通 VPN 后，VPN 客戶端就可以直接對集群內的 Pod 進行訪問

改造后開發環境與機房 K8S 集群之間的網絡架構圖如下所示：

通過在 K8S 集群里架設 OpenVPN，我們暫時解決了辦公區對機房 K8S 集群的 RPC 通訊問題。該方案的優缺點如下：

優點：

• 快速實現

• 工程量小

• 網絡隔離，證書驗證更安全

不足：

• 操作略繁瑣，如使用時需要申請證書，安裝客戶端軟件；每次使用前需要先打開 OpenVPN

• 是一種中間方案，沒有從本質上解決問題

第三階段：基于 MAC-VLAN 的 Kubernetes CNI

為了更好地支持 Java 業務的微服務改造，避免重復造輪子，我們構建了統一的 Java 基礎平臺，之前的網絡方案也面向更多的部門提供服務。

隨著服務的業務和人員越來越多，由人工操作帶來的不便和問題越來越明顯，我們決定對 K8S 網絡進行再一次改造。從之前的經驗中我們感到，如果 K8S 的虛擬網絡不去除，容器服務的 IP 是不可能直接由集群外的真實網絡到達的。

為了快速滿足不同業務場景下對于 K8S 網絡功能的需求，我們開始深入研究 CNI。

關于 CNI

CNI (Conteinre Network Interface) 旨在為容器平臺提供統一的網絡標準，由 Google 和 CoreOS 主導制定。它本身并不是一個完整的解決方案或者程序代碼，而是綜合考慮了靈活性、擴展性、IP 分配、多網卡等因素后，在 RKT 的基礎上發展起來的一種容器網絡接口協議。

CNI 的網絡分類和主流的實現工具主要包括：

• 第?類：與宿主機平??絡（2 層?絡或 3 層?絡），?絡插件主要包括 Bridge、MAC-VLAN 、IP-VLAN、Calico BGP、Flannel host-GW 等

• 第?類：利? SDN 技術的虛擬?絡，?絡插件主要有：Flannel vxlan、Calico ipip、Weave 等

MAC-VLAN  及其帶來的問題

通過對比測試，考慮到當下需求，我們最終決定基于網絡改造、運維成本和復雜度都較低的 MAC-VLAN  方案：

MAC-VLAN 具有 Linux Kernal 的特性，用于給一個物理網絡接口（parent）配置虛擬化接口。虛擬化接口與 parent 網絡接口擁有不同的 mac 地址，但 parent 接口上收到發給其對應的虛擬化接口的 mac 包時，會分發給對應的虛擬化接口，有點像將虛擬化接口和 parent 接口進行了「橋接」，使虛擬化網絡接口在配置了 IP 和路由后就能互相訪問。

在 MAC-VLAN 場景下，K8S 容器訪問可能會遇到一些問題，比如配置 MAC-VLAN 后，容器不能訪問 parent 接口的 IP。

通過調研，發現有以下兩種解決方案：

1. 虛擬網卡：打開網卡混雜模式，通過在宿主機上虛擬出一個虛擬網卡，將虛擬網卡與宿主機真實網卡聚合綁定

2. PTP 方案：類似 Bridge 的簡化版，但是網絡配置更復雜，并且有一些配置在自測過程中發現并沒有太大用處。與 Bridge 主要的不同是 PTP 不使用網橋，而是直接使用 vethpair+路由配置。

通過對比兩種方案的可實施性，最終我們選擇了第一種方案，但是第一種方案在虛擬機環境中經過測試發現偶爾會有宿主機與本機容器不通的現象，建議采用第一種方案的同學盡量不要使用虛擬機環境（懷疑還是網卡混雜設置的問題）。

「分區而治」的網絡改造

K8S 的核心組件 KubeDNS 在啟動時默認會訪問 ClusterIP 段的第一個 IP；如果繼續使用原有的 Nginx-ingress，那么 Nginx-ingress 的容器在啟動時也是使用 ClusterIP 去連接 KubeDNS。而使用 MAC-VLAN 給 KubeDNS 和 Nginx-ingress 分配的都是真實網絡 IP，他們是無法聯通 ClusterIP 的，所以 KubeDNS 和 Nginx-ingress 容器又不能使用 MAC-VLAN 方案，否則容器服務的域名訪問能力將喪失。

綜合考慮之下，最終我們采取了「分區而治」的措施，將不同類別的容器調度到不同的區域，使用不同的網絡方案，大致的圖解如下：         

采用 MAC-VLAN 方案時容器 IP 的分配方案有兩種：DHCP 和 host-local。考慮到公司目前沒有統一的 DHCP 和 IPAM 服務器為容器分配 IP，開發環境的機器數量不多，我們就采用了人工參與每個節點的網絡 IP 段分配。

綜上，此次改造后的網絡架構圖大致如下：

效果

可以看到與第一次網絡改造的架構圖對比：

• 宿主機 1 和宿主機 2 上已經拋棄了 Kube-proxy 和 Flannel 這些虛擬網絡的組件

• 宿主機 1 和宿主機 2 這些業務容器節點直接使用了公司公共 DNS 設施

• 辦公區本地 consumer 服務在注冊中心拿到 provider 的 IP 后，可以直接連接消費，反之亦可

• K8S 集群分為了虛擬網絡區 (運行 K8S  集群管理組件) 和真實網絡區 (運行業務容器)

此次改造的優勢和不足總結為：

優點：

• 遠程 debug

• 辦公網與集群內服務間的 RPC,TCP 通訊在二層網絡中打通

• 網絡延遲大大降低

• 支持多機房容災部署

缺點：

• 工程量大

• 需要耗費大量真實 IP 地址

• 集群規模很大時，存在 ARP 廣播風暴和交換機 MAC 表超限風險

讀到這里，這篇“Kubernetes網絡的原理是什么”文章已經介紹完畢，想要掌握這篇文章的知識點還需要大家自己動手實踐使用過才能領會，如果想了解更多相關內容的文章，歡迎關注億速云行業資訊頻道。