Kubernetes網(wǎng)絡(luò)的原理是什么

本文小編為大家詳細(xì)介紹“Kubernetes網(wǎng)絡(luò)的原理是什么”，內(nèi)容詳細(xì)，步驟清晰，細(xì)節(jié)處理妥當(dāng)，希望這篇“Kubernetes網(wǎng)絡(luò)的原理是什么”文章能幫助大家解決疑惑，下面跟著小編的思路慢慢深入，一起來學(xué)習(xí)新知識吧。

為伊美等地區(qū)用戶提供了全套網(wǎng)頁設(shè)計制作服務(wù)，及伊美網(wǎng)站建設(shè)行業(yè)解決方案。主營業(yè)務(wù)為網(wǎng)站設(shè)計制作、網(wǎng)站設(shè)計、伊美網(wǎng)站設(shè)計，以傳統(tǒng)方式定制建設(shè)網(wǎng)站，并提供域名空間備案等一條龍服務(wù)，秉承以專業(yè)、用心的態(tài)度為用戶提供真誠的服務(wù)。我們深信只要達(dá)到每一位用戶的要求，就會得到認(rèn)可，從而選擇與我們長期合作。這樣，我們也可以走得更遠(yuǎn)！

Part.1 Kubernetes 網(wǎng)絡(luò)原理及挑戰(zhàn)

1. Kubernetes Pod 設(shè)計

Pod 是 Kubernetes 的基本調(diào)度單元，我們可以將 Pod 認(rèn)為是容器的一種延伸擴(kuò)展，一個 Pod 也是一個隔離體，而 Pod 內(nèi)部又包含一組共享的容器。

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

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

2. 挑戰(zhàn)

Pod 的 IP 是在 Kubernetes 集群內(nèi)的，是虛擬且局域的。這就帶來一個問題，Pod IP 在集群內(nèi)部訪問沒有問題，但在實際項目開發(fā)中，難免會有真實網(wǎng)絡(luò)環(huán)境下的應(yīng)用需要訪問 Kubernetes 集群里的容器，這就需要我們做一些額外的工作。

本文將結(jié)合我們開發(fā)環(huán)境下基于 K8S 容器網(wǎng)絡(luò)演進(jìn)的過程，介紹在 Pod IP 為虛擬或真實 IP 情況下的幾種直接訪問 Pod IP 的解決方案。

Part.2 基于 Kubernetes 的容器網(wǎng)絡(luò)演進(jìn)

第一階段：Kubernetes + Flannel

最早，我們的網(wǎng)絡(luò)設(shè)計方案只服務(wù)于大交通業(yè)務(wù)。初期大交通的 Java 應(yīng)用是部署在物理機(jī)上的，團(tuán)隊內(nèi)部容器相關(guān)的底層基礎(chǔ)設(shè)施幾乎為 0。為了更加平穩(wěn)地實現(xiàn)容器化的落地，中間我們沒有直接把服務(wù)全部遷移到 K8S 中去，而是經(jīng)歷了一段混跑。

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

Flannel 是為 K8S 設(shè)計的一個非常簡潔的多節(jié)點三層網(wǎng)絡(luò)方案，主要用于解決容器的跨主機(jī)通信問題，是一個比較大一統(tǒng)的方案。它的設(shè)計目的是為集群中的所有節(jié)點重新規(guī)劃 IP 地址的使用規(guī)則，從而使得不同節(jié)點上的容器能夠獲得「同屬一個內(nèi)網(wǎng)」且「不重復(fù)的」IP 地址，并讓屬于不同節(jié)點上的容器能夠直接通過內(nèi)網(wǎng) IP 通信。

Flannel 的原理是為每個 host 分配一個 subnet，容器從此 subnet 中分配 IP，這些 IP 可以在 host 間路由，容器間無需 NAT 和 port  mapping 就可以跨主機(jī)通信。每個 subnet 都是從一個更大的 IP 池中劃分的，F(xiàn)lannel 會在每個 host 上面運行一個守護(hù)進(jìn)程 flanneld，其職責(zé)就是從大池子中分配 subnet，為了各個主機(jī)間共享信息。Flannel 用 ETCD 存放網(wǎng)絡(luò)配置、已分配的 subnet、host 的 IP 等信息。

Flannel 的節(jié)點間有三種通信方式：

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

• Host-gw：二層網(wǎng)絡(luò)配置，不支持云環(huán)境，通過在 host 的路由表中直接創(chuàng)建到其他主機(jī) subnet 的路由條目

•  UDP：通常用于 debug

我們在所有的業(yè)務(wù)物理機(jī)上都部署了 Flannel，并且啟動 Flanneld 服務(wù)，使之加入 K8S 虛擬網(wǎng)絡(luò)，這樣物理機(jī)上的服務(wù)與 K8S 里的容器服務(wù)在互相調(diào)用時，就可以通過 Flannel+Kube-proxy 的虛擬網(wǎng)絡(luò)。整體結(jié)構(gòu)圖如下：

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

• 當(dāng)客戶端通過 172.18.12.21:30030 撥通 VPN 時，客戶端與 VPN Server 間的網(wǎng)絡(luò)被打通

• 因為 VPN Server 本身處于集群虛擬網(wǎng)絡(luò)環(huán)境中，所以其他容器的 IP 對于 vpn server 是可見的，因此撥通 VPN 后，VPN 客戶端就可以直接對集群內(nèi)的 Pod 進(jìn)行訪問

改造后開發(fā)環(huán)境與機(jī)房 K8S 集群之間的網(wǎng)絡(luò)架構(gòu)圖如下所示：

通過在 K8S 集群里架設(shè) OpenVPN，我們暫時解決了辦公區(qū)對機(jī)房 K8S 集群的 RPC 通訊問題。該方案的優(yōu)缺點如下：

優(yōu)點：

• 快速實現(xiàn)

• 工程量小

• 網(wǎng)絡(luò)隔離，證書驗證更安全

不足：

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

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

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

為了更好地支持 Java 業(yè)務(wù)的微服務(wù)改造，避免重復(fù)造輪子，我們構(gòu)建了統(tǒng)一的 Java 基礎(chǔ)平臺，之前的網(wǎng)絡(luò)方案也面向更多的部門提供服務(wù)。

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

為了快速滿足不同業(yè)務(wù)場景下對于 K8S 網(wǎng)絡(luò)功能的需求，我們開始深入研究 CNI。

關(guān)于 CNI

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

CNI 的網(wǎng)絡(luò)分類和主流的實現(xiàn)工具主要包括：

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

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

MAC-VLAN  及其帶來的問題

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

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

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

通過調(diào)研，發(fā)現(xiàn)有以下兩種解決方案：

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

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

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

「分區(qū)而治」的網(wǎng)絡(luò)改造

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

綜合考慮之下，最終我們采取了「分區(qū)而治」的措施，將不同類別的容器調(diào)度到不同的區(qū)域，使用不同的網(wǎng)絡(luò)方案，大致的圖解如下：         

      

采用 MAC-VLAN 方案時容器 IP 的分配方案有兩種：DHCP 和 host-local?？紤]到公司目前沒有統(tǒng)一的 DHCP 和 IPAM 服務(wù)器為容器分配 IP，開發(fā)環(huán)境的機(jī)器數(shù)量不多，我們就采用了人工參與每個節(jié)點的網(wǎng)絡(luò) IP 段分配。

綜上，此次改造后的網(wǎng)絡(luò)架構(gòu)圖大致如下：

效果

可以看到與第一次網(wǎng)絡(luò)改造的架構(gòu)圖對比：

• 宿主機(jī) 1 和宿主機(jī) 2 上已經(jīng)拋棄了 Kube-proxy 和 Flannel 這些虛擬網(wǎng)絡(luò)的組件

• 宿主機(jī) 1 和宿主機(jī) 2 這些業(yè)務(wù)容器節(jié)點直接使用了公司公共 DNS 設(shè)施

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

• K8S 集群分為了虛擬網(wǎng)絡(luò)區(qū) (運行 K8S  集群管理組件) 和真實網(wǎng)絡(luò)區(qū) (運行業(yè)務(wù)容器)

此次改造的優(yōu)勢和不足總結(jié)為：

優(yōu)點：

• 遠(yuǎn)程 debug

• 辦公網(wǎng)與集群內(nèi)服務(wù)間的 RPC,TCP 通訊在二層網(wǎng)絡(luò)中打通

• 網(wǎng)絡(luò)延遲大大降低

• 支持多機(jī)房容災(zāi)部署

缺點：

• 工程量大

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

• 集群規(guī)模很大時，存在 ARP 廣播風(fēng)暴和交換機(jī) MAC 表超限風(fēng)險

讀到這里，這篇“Kubernetes網(wǎng)絡(luò)的原理是什么”文章已經(jīng)介紹完畢，想要掌握這篇文章的知識點還需要大家自己動手實踐使用過才能領(lǐng)會，如果想了解更多相關(guān)內(nèi)容的文章，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道。

新聞標(biāo)題：Kubernetes網(wǎng)絡(luò)的原理是什么
當(dāng)前鏈接：http://bm7419.com/article48/pphgep.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供商城網(wǎng)站、定制開發(fā)、、網(wǎng)站策劃、搜索引擎優(yōu)化、用戶體驗

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)