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

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

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

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

1. Kubernetes Pod 設(shè)計(jì)

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

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

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

2. 挑戰(zhàn)

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

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

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

第一階段：Kubernetes + Flannel

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

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

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

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

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

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

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

•  UDP：通常用于 debug

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

• 我們?cè)诩旱?middleware 空間下以 nodeport 的方式部署了 VPN Server，并給客戶端分配了 10.140 的網(wǎng)段

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

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

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

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

優(yōu)點(diǎn)：

• 快速實(shí)現(xiàn)

• 工程量小

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

不足：

• 操作略繁瑣，如使用時(shí)需要申請(qǐng)證書，安裝客戶端軟件；每次使用前需要先打開(kāi) OpenVPN

• 是一種中間方案，沒(méi)有從本質(zhì)上解決問(wèn)題

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

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

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

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

關(guān)于 CNI

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

CNI 的網(wǎng)絡(luò)分類和主流的實(shí)現(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  及其帶來(lái)的問(wèn)題

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

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

在 MAC-VLAN 場(chǎng)景下，K8S 容器訪問(wèn)可能會(huì)遇到一些問(wèn)題，比如配置 MAC-VLAN 后，容器不能訪問(wèn) parent 接口的 IP。

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

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

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

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

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

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

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

      

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

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

效果

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

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

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

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

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

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

優(yōu)點(diǎn)：

• 遠(yuǎn)程 debug

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

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

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

缺點(diǎn)：

• 工程量大

• 需要耗費(fèi)大量真實(shí) IP 地址

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

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

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

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

廣告

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