目錄：

• 一個目標(biāo)：容器操作
• 兩地三中心
• 四層服務(wù)發(fā)現(xiàn)
• 五種Pod共享資源
• 六個CNI常用插件
• 七層負(fù)載均衡
• 八種隔離維度
• 九個網(wǎng)絡(luò)模型原則
  
  

一個目標(biāo)：容器操作；兩地三中心；四層服務(wù)發(fā)現(xiàn)；五種Pod共享資源；六個CNI常用插件；七層負(fù)載均衡；八種隔離維度；九個網(wǎng)絡(luò)模型原則；十類IP地址；百級產(chǎn)品線；千級物理機；萬級容器；相如無億，K8s有億：億級日服務(wù)人次。

一個目標(biāo)：容器操作

Kubernetes（k8s）是自動化容器操作的開源平臺。這些容器操作包括：部署、調(diào)度和節(jié)點集群間擴展。

具體功能：

• 自動化容器部署和復(fù)制。
• 實時彈性收縮容器規(guī)模。
• 容器編排成組，并提供容器間的負(fù)載均衡。

調(diào)度：容器在哪個機器上運行。

組成：

• kubectl:客戶端命令行工具，作為整個系統(tǒng)的操作入口。
• kube-apiserver:以REST API服務(wù)形式提供接口，作為整個系統(tǒng)的控制入口。
• kube-controller-manager:執(zhí)行整個系統(tǒng)的后臺任務(wù)，包括節(jié)點狀態(tài)狀況、Pod個數(shù)、Pods和Service的關(guān)聯(lián)等。
• kube-scheduler:負(fù)責(zé)節(jié)點資源管理，接收來自kube-apiserver創(chuàng)建Pods任務(wù)，并分配到某個節(jié)點。
• etcd:負(fù)責(zé)節(jié)點間的服務(wù)發(fā)現(xiàn)和配置共享。
• kube-proxy:運行在每個計算節(jié)點上，負(fù)責(zé)Pod網(wǎng)絡(luò)代理。定時從etcd獲取到service信息來做相應(yīng)的策略。
• kubelet:運行在每個計算節(jié)點上，作為agent，接收分配該節(jié)點的Pods任務(wù)及管理容器，周期性獲取容器狀態(tài)，反饋給kube-apiserver。
• DNS：一個可選的DNS服務(wù)，用于為每個Service對象創(chuàng)建DNS記錄，這樣所有的Pod就可以通過DNS訪問服務(wù)了。

下面是K8s的架構(gòu)拓?fù)鋱D：

兩地三中心

兩地三中心包括本地生產(chǎn)中心、本地災(zāi)備中心、異地災(zāi)備中心。

兩地三中心要解決的一個重要問題就是數(shù)據(jù)一致性問題。k8s使用etcd組件作為一個高可用、強一致性的服務(wù)發(fā)現(xiàn)存儲倉庫。用于配置共享和服務(wù)發(fā)現(xiàn)。

它作為一個受到Zookeeper和doozer啟發(fā)而催生的項目。除了擁有他們的所有功能之外，還擁有以下4個特點：

• 簡單：基于http+json的api讓你用curl命令就可以輕松使用。
• 安全：可選SSL客戶認(rèn)證機制。
• 快速：每個實例每秒支持一千次寫操作。
• 可信：使用Raft算法充分實現(xiàn)了分布式。

四層服務(wù)發(fā)現(xiàn)

先一張圖解釋一下網(wǎng)絡(luò)七層協(xié)議：

k8s提供了兩種方式進行服務(wù)發(fā)現(xiàn)：

環(huán)境變量：當(dāng)創(chuàng)建一個Pod的時候，kubelet會在該Pod中注入集群內(nèi)所有Service的相關(guān)環(huán)境變量。需要注意的是，要想一個Pod中注入某個Service的環(huán)境變量，則必須Service要先比該Pod創(chuàng)建。這一點，幾乎使得這種方式進行服務(wù)發(fā)現(xiàn)不可用。

比如，一個ServiceName為redis-master的Service，對應(yīng)的ClusterIP:Port為10.0.0.11:6379，則對應(yīng)的環(huán)境變量為：

DNS：可以通過cluster add-on的方式輕松的創(chuàng)建KubeDNS來對集群內(nèi)的Service進行服務(wù)發(fā)現(xiàn)。

以上兩種方式，一個是基于tcp，眾所周知，DNS是基于UDP的，它們都是建立在四層協(xié)議之上。

五種Pod共享資源

Pod是K8s最基本的操作單元，包含一個或多個緊密相關(guān)的容器，一個Pod可以被一個容器化的環(huán)境看作應(yīng)用層的“邏輯宿主機”；一個Pod中的多個容器應(yīng)用通常是緊密耦合的，Pod在Node上被創(chuàng)建、啟動或者銷毀；每個Pod里運行著一個特殊的被稱之為Volume掛載卷，因此他們之間通信和數(shù)據(jù)交換更為高效，在設(shè)計時我們可以充分利用這一特性將一組密切相關(guān)的服務(wù)進程放入同一個Pod中。

同一個Pod里的容器之間僅需通過localhost就能互相通信。

一個Pod中的應(yīng)用容器共享五種資源：

• PID命名空間：Pod中的不同應(yīng)用程序可以看到其他應(yīng)用程序的進程ID。
• 網(wǎng)絡(luò)命名空間：Pod中的多個容器能夠訪問同一個IP和端口范圍。
• IPC命名空間：Pod中的多個容器能夠使用SystemV IPC或POSIX消息隊列進行通信。
• UTS命名空間：Pod中的多個容器共享一個主機名。
• Volumes(共享存儲卷)：Pod中的各個容器可以訪問在Pod級別定義的Volumes。

Pod的生命周期通過Replication Controller來管理；通過模板進行定義，然后分配到一個Node上運行，在Pod所包含容器運行結(jié)束后，Pod結(jié)束。

Kubernetes為Pod設(shè)計了一套獨特的網(wǎng)絡(luò)配置，包括：為每個Pod分配一個IP地址，使用Pod名作為榮期間通信的主機名等。

六個CNI常用插件

CNI(Container Network Interface)容器網(wǎng)絡(luò)接口，是Linux容器網(wǎng)絡(luò)配置的一組標(biāo)準(zhǔn)和庫，用戶需要根據(jù)這些標(biāo)準(zhǔn)和庫來開發(fā)自己的容器網(wǎng)絡(luò)插件。CNI只專注解決容器網(wǎng)絡(luò)連接和容器銷毀時的資源釋放，提供一套框架，所以CNI可以支持大量不同的網(wǎng)絡(luò)模式，并且容易實現(xiàn)。

下面用一張圖表示六個CNI常用插件：

七層負(fù)載均衡

提負(fù)載均衡就不得不先提服務(wù)器之間的通信。

IDC(Internet Data Center),也可稱 數(shù)據(jù)中心、機房，用來放置服務(wù)器。IDC網(wǎng)絡(luò)是服務(wù)器間通信的橋梁。

上圖里畫了很多網(wǎng)絡(luò)設(shè)備，它們都是干啥用的呢？

路由器、交換機、MGW/NAT都是網(wǎng)絡(luò)設(shè)備，按照性能、內(nèi)外網(wǎng)劃分不同的角色。

• 內(nèi)網(wǎng)接入交換機：也稱為TOR(top of rack),是服務(wù)器接入網(wǎng)絡(luò)的設(shè)備。每臺內(nèi)網(wǎng)接入交換機下聯(lián)40-48臺服務(wù)器，使用一個掩碼為/24的網(wǎng)段作為服務(wù)器內(nèi)網(wǎng)網(wǎng)段。
• 內(nèi)網(wǎng)核心交換機：負(fù)責(zé)IDC內(nèi)各內(nèi)網(wǎng)接入交換機的流量轉(zhuǎn)發(fā)及跨IDC流量轉(zhuǎn)發(fā)。
• MGW/NAT：MGW即LVS用來做負(fù)載均衡，NAT用于內(nèi)網(wǎng)設(shè)備訪問外網(wǎng)時做地址轉(zhuǎn)換。
• 外網(wǎng)核心路由器：通過靜態(tài)互聯(lián)運營商或BGP互聯(lián)美團統(tǒng)一外網(wǎng)平臺。

先說說各層負(fù)載均衡：

• 二層負(fù)載均衡：基于MAC地址的二層負(fù)載均衡。
• 三層負(fù)載均衡：基于IP地址的負(fù)載均衡。
• 四層負(fù)載均衡：基于IP+端口的負(fù)載均衡。
• 七層負(fù)載均衡：基于URL等應(yīng)用層信息的負(fù)載均衡。

這里用一張圖來說說四層和七層負(fù)載均衡的區(qū)別：

上面四層服務(wù)發(fā)現(xiàn)講的主要是k8s原生的kube-proxy方式。K8s關(guān)于服務(wù)的暴露主要是通過NodePort方式，通過綁定minion主機的某個端口，然后進行pod的請求轉(zhuǎn)發(fā)和負(fù)載均衡，但這種方式有下面的缺陷：

• Service可能有很多個，如果每個都綁定一個node主機端口的話，主機需要開放外圍的端口進行服務(wù)調(diào)用，管理混亂。
• 無法應(yīng)用很多公司要求的防火墻規(guī)則。

理想的方式是通過一個外部的負(fù)載均衡器，綁定固定的端口，比如80，然后根據(jù)域名或者服務(wù)名向后面的Service ip轉(zhuǎn)發(fā)，Nginx很好的解決了這個需求，但問題是如果有的心得服務(wù)加入，如何去修改Nginx的配置，并且加載這些配置？Kubernetes給出的方案就是Ingress。這是一個基于7層的方案。

八種隔離維度

K8s集群調(diào)度這邊需要對上面從上到下從粗粒度到細粒度的隔離做相應(yīng)的調(diào)度策略。

九個網(wǎng)絡(luò)模型原則

K8s網(wǎng)絡(luò)模型要符合4個基礎(chǔ)原則，3個網(wǎng)絡(luò)要求原則，1個架構(gòu)原則，1個IP原則。

每個Pod都擁有一個獨立的IP地址，而且假定所有Pod都在一個可以直接連通的、扁平的網(wǎng)絡(luò)空間中，不管是否運行在同一Node上都可以通過Pod的IP來訪問。

K8s中的Pod的IP是最小粒度IP。同一個Pod內(nèi)所有的容器共享一個網(wǎng)絡(luò)堆棧，該模型稱為IP-per-Pod模型。

• Pod由docker0實際分配的IP
• Pod內(nèi)部看到的IP地址和端口與外部保持一致
• 同一個Pod內(nèi)的不同容器共享網(wǎng)絡(luò)，可以通過localhost來訪問對方的端口，類似同一個VM內(nèi)不同的進程。

IP-per-Pod模型從端口分配、域名解析、服務(wù)發(fā)現(xiàn)、負(fù)載均衡、應(yīng)用配置等角度看，Pod可以看做是一臺獨立的VM或物理機。

• 所有容器都可以不用NAT的方式同別的容器通信。
• 所有節(jié)點都可以在不同NAT方式下同所有容器心痛，反之亦然。
• 容器的地址和別人看到的地址是同一個地址。

要符合下面的架構(gòu)：

由上圖架構(gòu)引申出來IP概念從集群外部到集群內(nèi)部

作者：stackpush

來源：blog.csdn.net/huakai_sun/article/details/82378856