如何做容器化集群管理？保障容器能被有序訪問是關(guān)鍵

原標(biāo)題：如何做容器化集群管理？保障容器能被有序訪問是關(guān)鍵

在上一篇《容器化實(shí)踐指南 | 邁出容器化的第一步：集群管理（上）》中，我們介紹了Kubernetes的節(jié)點(diǎn)如何構(gòu)成一個(gè)集群。本篇將在此基礎(chǔ)上，繼續(xù)介紹Kubernetes集群的容器網(wǎng)絡(luò)架構(gòu)。

當(dāng)Kubernetes集群完成搭建后，用戶的容器就可以運(yùn)行在眾多的工作節(jié)點(diǎn)之中，那么接下來就需要確保這些容器之間可以互相訪問或接受來自外部的訪問。雖然我們?cè)诖罱簳r(shí)就已經(jīng)確保了所有工作節(jié)點(diǎn)在網(wǎng)絡(luò)上是互通的，但是由于同一個(gè)節(jié)點(diǎn)上可能同時(shí)運(yùn)行多個(gè)容器，并且容器本身也隨時(shí)可能在節(jié)點(diǎn)之間移動(dòng)，因此Kubernetes需要一套容器網(wǎng)絡(luò)方案來保障訪問某個(gè)指定容器的流量可以正確地到達(dá)該容器，并且不同容器在接收請(qǐng)求時(shí)不會(huì)出現(xiàn)路由沖突。

Kubernetes網(wǎng)絡(luò)基本的部署調(diào)度單元：Pod

在說明常見的容器網(wǎng)絡(luò)方案之前，我們需要先理解一個(gè)Kubernetes中最基礎(chǔ)的概念：Pod。

簡單來說，Kubernetes中的基本管理單元并不是一個(gè)個(gè)獨(dú)立的容器，而是一個(gè)或多個(gè)相關(guān)容器組成的容器組，稱為Pod。通常情況下，一個(gè)Pod即用戶部署的一個(gè)服務(wù)單元，比如一個(gè)數(shù)據(jù)庫服務(wù)、一個(gè)Web服務(wù)等。如果用戶的一個(gè)服務(wù)單元中存在多個(gè)獨(dú)立運(yùn)行的組件，那么這些組件就可以部署在該P(yáng)od的不同容器中，從而在組件解耦的基礎(chǔ)上便于對(duì)多個(gè)容器進(jìn)行統(tǒng)一管理。

Pod在英文中的原意是豌豆莢，也非常形象地表達(dá)出了Pod（豆莢）與容器（豆子）之間的關(guān)系。

關(guān)于Pod的管理未來我們將會(huì)進(jìn)行更多的闡述，單從容器網(wǎng)絡(luò)的角度來看，每一個(gè)Pod即是一個(gè)獨(dú)立的最終訪問單元。因此Kubernetes的網(wǎng)絡(luò)架構(gòu)中有一個(gè)最基本的設(shè)計(jì)原則：每個(gè)Pod擁有唯一的IP地址。這個(gè)Pod IP將被Pod中的所有容器共享，而集群內(nèi)的其它Pod則可以通過該P(yáng)od IP正確訪問到對(duì)應(yīng)容器。

在理解這個(gè)基本原則之后，我們也就不難理解，容器網(wǎng)絡(luò)方案需要解決的問題其實(shí)包括以下3個(gè)：

• 同一個(gè)Pod中的多個(gè)容器如何通訊
• 同一個(gè)工作節(jié)點(diǎn)上的Pod之間如何通訊
• 跨不同工作節(jié)點(diǎn)的Pod之間如何通訊

同一個(gè)Pod中的多個(gè)容器間通訊

在Kubernetes的設(shè)計(jì)中，一個(gè)Pod內(nèi)的所有容器共享同一個(gè)網(wǎng)絡(luò)命名空間（Network Namespace，后文中簡稱為netns），因此它們之間可以直接通過"localhost" + 端口互相訪問。

但需要注意的是，由于Pod內(nèi)的容器共享同一個(gè)netns，因此為了避免訪問沖突，這些容器各自使用的端口必須唯一。比如說容器A占用了80端口，那么同一個(gè)Pod中的容器B就不能再使用該端口了。

為了便于理解，我們通過一個(gè)簡單的例子說明：

• 我們創(chuàng)建一個(gè)Pod，Pod中存在兩個(gè)容器，其中一個(gè)運(yùn)行Nginx作為反向代理，另外一個(gè)運(yùn)行簡單的Web應(yīng)用程序
• 可以定義Nginx的容器端口為80，定義Web應(yīng)用程序的容器端口為9000，假設(shè)外部訪問該P(yáng)od的請(qǐng)求都使用80端口
• 在Nginx容器中通過配置文件定義：通過80端口輸入的請(qǐng)求將被轉(zhuǎn)發(fā)到本地端口9000
• 所有訪問該P(yáng)od 80端口的請(qǐng)求，都將被發(fā)往Nginx容器，然后再被轉(zhuǎn)發(fā)到Web應(yīng)用容器的9000端口

同一個(gè)工作節(jié)點(diǎn)上的Pod間通訊

在Kubernetes集群中的每一個(gè)工作節(jié)點(diǎn)（針對(duì)Linux操作系統(tǒng)），都會(huì)有一個(gè)根網(wǎng)絡(luò)命名空間（root netns），工作節(jié)點(diǎn)上的根網(wǎng)絡(luò)設(shè)備（eth0）就在這個(gè)root netns下。對(duì)于每一個(gè)部署在節(jié)點(diǎn)上的Pod，其自身都有一個(gè)獨(dú)立的netns（即前文提到的由Pod內(nèi)所有容器共享的網(wǎng)絡(luò)命名空間），Pod本身不需要感知到節(jié)點(diǎn)主機(jī)上真實(shí)的網(wǎng)絡(luò)設(shè)備，而是擁有自己的虛擬根網(wǎng)絡(luò)設(shè)備（同樣叫做eth0）。

Pod自身的netns通過一個(gè)Linux虛擬網(wǎng)絡(luò)設(shè)備 veth 連接到root netns中，該虛擬網(wǎng)絡(luò)設(shè)備通常被命名為veth***，在節(jié)點(diǎn)中通過ifconfig或者ip a等命令就可以列出該節(jié)點(diǎn)上所有的veth。同時(shí)每個(gè)節(jié)點(diǎn)中會(huì)創(chuàng)建一個(gè)專用的以太網(wǎng)橋（通常稱為 cbr0），這個(gè)網(wǎng)橋的作用類似于交換機(jī)，通過mac尋址，將訪問節(jié)點(diǎn)內(nèi)Pod IP的請(qǐng)求投遞到正確的物理地址。

當(dāng)一個(gè)網(wǎng)絡(luò)數(shù)據(jù)包要從Pod1發(fā)送到Pod2，它會(huì)經(jīng)歷以下流程：

• 首先數(shù)據(jù)由Pod1中netns的網(wǎng)絡(luò)接口eth0離開，通過veth-pod1進(jìn)入root netns
• 然后數(shù)據(jù)被轉(zhuǎn)到網(wǎng)橋cbr0中，cbr0通過ARP請(qǐng)求詢問：“誰擁有這個(gè)IP？”
• verth-pod2答復(fù)說“我擁有這個(gè)IP”，于是cbr0將數(shù)據(jù)包投遞給verth-pod2
• 最后數(shù)據(jù)包通過verth-pod2，被轉(zhuǎn)發(fā)到Pod2的netns

跨不同工作節(jié)點(diǎn)的Pod間通訊

最復(fù)雜的情況就是在不同節(jié)點(diǎn)上的Pod需要互相通訊，由于Pod本身會(huì)經(jīng)常在不同節(jié)點(diǎn)間漂移，因此Pod對(duì)應(yīng)的IP地址也需要?jiǎng)討B(tài)地路由到不同節(jié)點(diǎn)上。

在公有云環(huán)境下，最常用的方案就是直接通過VPC所提供的路由表功能幫助網(wǎng)絡(luò)流量到達(dá)正確的目的地。由于VPC內(nèi)的所有流量都通過VPC本身提供的虛擬交換機(jī)進(jìn)行轉(zhuǎn)發(fā)，當(dāng)一個(gè)Pod需要訪問另一個(gè)Pod時(shí)，如果節(jié)點(diǎn)發(fā)現(xiàn)訪問對(duì)象的IP地址不在本節(jié)點(diǎn)上，流量就會(huì)通過節(jié)點(diǎn)的根網(wǎng)絡(luò)設(shè)備發(fā)送到VPC中的虛擬交換機(jī)，交換機(jī)再通過路由表規(guī)則將流量正確轉(zhuǎn)發(fā)到目標(biāo)Pod IP所在的節(jié)點(diǎn)上，再由節(jié)點(diǎn)內(nèi)的netns轉(zhuǎn)發(fā)到目的Pod。

百度云容器引擎CCE即采用了這種方案，CCE服務(wù)將會(huì)幫助用戶動(dòng)態(tài)維護(hù)路由表規(guī)則，將容器網(wǎng)絡(luò)中的地址通過路由表規(guī)則映射給集群內(nèi)的各個(gè)節(jié)點(diǎn)IP，從而確保訪問Pod的流量轉(zhuǎn)發(fā)到正確的節(jié)點(diǎn)中。這種方案無需經(jīng)過額外的Overlay網(wǎng)絡(luò)層，因此具備較高的網(wǎng)絡(luò)性能。

如果用戶不在公有云環(huán)境使用Kubernetes，或者不具備自動(dòng)更新路由表規(guī)則的能力，就需要在Kubernetes中集成其它的網(wǎng)絡(luò)方案，其中最常見的包括Flannel和Calico。

• Flannel是一種overlay網(wǎng)絡(luò)方案。簡單來講，就是通過在節(jié)點(diǎn)中部署一個(gè)叫做flanneld的進(jìn)程來構(gòu)建一個(gè)跨節(jié)點(diǎn)的容器網(wǎng)絡(luò)空間，該進(jìn)程通過etcd來管理所有Pod的地址資源，記錄每個(gè)Pod所在的節(jié)點(diǎn)地址，然后將節(jié)點(diǎn)內(nèi)通過cbr0向外發(fā)送的數(shù)據(jù)包再次打包，利用集群網(wǎng)絡(luò)將數(shù)據(jù)包發(fā)送到目標(biāo)flanneld上，從而實(shí)現(xiàn)Pod跨節(jié)點(diǎn)的通訊。但是由于flannel方案本身引入了多個(gè)網(wǎng)絡(luò)組件，且在通訊過程中需要對(duì)數(shù)據(jù)進(jìn)行再次打包，因此會(huì)引入一些網(wǎng)絡(luò)的時(shí)延損耗。

• Calico方案則是利用每個(gè)節(jié)點(diǎn)的Linux Kernel來實(shí)現(xiàn)一個(gè)vRoute進(jìn)行數(shù)據(jù)轉(zhuǎn)發(fā)，每個(gè)vRoute通過BGP協(xié)議把自己所在節(jié)點(diǎn)上運(yùn)行的Pod路由信息向整個(gè)Calico網(wǎng)絡(luò)內(nèi)傳播，這樣保證最終所有的Pod間的通訊都可以直接通過IP路由的方式實(shí)現(xiàn)。Calico網(wǎng)絡(luò)方案直接利用節(jié)點(diǎn)所在的網(wǎng)絡(luò)結(jié)構(gòu)，不需要額外的隧道或者Overlay網(wǎng)絡(luò)，因此同樣具備較高的網(wǎng)絡(luò)性能。但是Calico本身的部署相對(duì)來講比較復(fù)雜，對(duì)用戶的要求較高。

下期內(nèi)容預(yù)告

本期我們介紹了容器網(wǎng)絡(luò)所解決的問題以及常見的方案，希望可以幫助大家更好地理解Kubernetes的網(wǎng)絡(luò)架構(gòu)。下期我們將帶來集群管理的最后一部分內(nèi)容：存儲(chǔ)管理。敬請(qǐng)期待！

關(guān)注百度云微信公眾號(hào)，了解和體驗(yàn)百度云容器引擎CCE。

生成海報(bào)

免責(zé)聲明：本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準(zhǔn)確性及可靠性，但不保證有關(guān)資料的準(zhǔn)確性及可靠性，讀者在使用前請(qǐng)進(jìn)一步核實(shí)，并對(duì)任何自主決定的行為負(fù)責(zé)。本網(wǎng)站對(duì)有關(guān)資料所引致的錯(cuò)誤、不確或遺漏，概不負(fù)任何法律責(zé)任。任何單位或個(gè)人認(rèn)為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識(shí)產(chǎn)權(quán)或存在不實(shí)內(nèi)容時(shí)，應(yīng)及時(shí)向本網(wǎng)站提出書面權(quán)利通知或不實(shí)情況說明，并提供身份證明、權(quán)屬證明及詳細(xì)侵權(quán)或不實(shí)情況證明。本網(wǎng)站在收到上述法律文件后，將會(huì)依法盡快聯(lián)系相關(guān)文章源頭核實(shí)，溝通刪除相關(guān)內(nèi)容或斷開相關(guān)鏈接。