《兩地書》--Kubernetes(K8s)基礎知識(docker容器技術)

　　大家都知道歷史上有段佳話叫“司馬相如和卓文君”。“皚如山上雪，皎若雲間月”。卓文君這麼美，卻也抵不過多情女兒薄情郎。

　　司馬相如因一首《子虛賦》得漢武帝賞識，飛黃騰達之後便要與卓文君“故來相決絕”，寄來給家鄉留守的妻子一封《兩地書》，上面只有一行數字：“一二三四五六七八九十百千萬。”意義是：無億，我已經無意於你啦。

　　卓文君看了這封信也不示弱，回了一首《怨郎詩》，司馬相如看了發現雖然我是靠寫詩吃飯的。要說寫詩還是我媳婦厲害，於是親自將卓文君迎回長安。

　　卓文君其實是個二婚。頭婚的丈夫結婚不久就死了。這估計也是司馬相如後來想對她始亂終棄的原因之一。但是文君老奶奶是有實力的。人家第一敢連夜私奔，第二還hold得住老公。就我這文采，你想不要我，你大Boss漢武帝都會不高興的。

　　正是卓文君的才智，不僅成就了她自己，更成就了他老公。詩聖杜甫都用“茂陵多病後，尚愛卓文君”來贊美他們的愛情。如果司馬相如娶了別人，那曲《鳳求凰》就可以看出，骨子裡胡蘭成一樣的人物。

　　今天的主題不是愛情不是詩，咱們用《兩地書》來談談K8s基礎知識關鍵詞：

　　一個目標：容器操作；兩地三中心；四層服務發現；五種Pod共用資源；六個CNI常用插件；七層負載均衡；八種隔離維度；九個網路模型原則；十類IP地址；百級產品線；千級物理機；萬級容器；相如無億，K8s有億：億級日服務人次。

一個目標：容器操作
Kubernetes(k8s)是自動化容器操作的開源平臺。這些容器操作包括：部署，調度和節點集群間擴展。
具體功能：
自動化容器部署和複製。
實時彈性收縮容器規模。
容器編排成組，並提供容器間的負載均衡。
調度：容器在哪個機器上運行。
組成：
kubectl:客戶端命令行工具，作為整個系統的操作入口。
kube-apiserver:以REST API服務形式提供介面，作為整個系統的控制入口。
kube-controller-manager:執行整個系統的後臺任務，包括節點狀態狀況、Pod個數、Pods和Service的關聯等。
kube-scheduler:負責節點資源管理，接收來自kube-apiserver創建Pods任務，並分配到某個節點。
etcd:負責節點間的服務發現和配置共用。
kube-proxy:運行在每個計算節點上，負責Pod網路代理。定時從etcd獲取到service信息來做相應的策略。
kubelet:運行在每個計算節點上，作為agent，接收分配該節點的Pods任務及管理容器，周期性獲取容器狀態，反饋給kube-apiserver。
DNS：一個可選的DNS服務，用於為每個Service對象創建DNS記錄，這樣所有的Pod就可以通過DNS訪問服務了。
下麵是K8s的架構拓撲圖：

兩地三中心
兩地三中心包括本地生產中心、本地災備中心、異地災備中心。

兩地三中心要解決的一個重要問題就是數據一致性問題。k8s使用etcd組件作為一個高可用、強一致性的服務發現存儲倉庫。用於配置共用和服務發現。
它作為一個受到Zookeeper和doozer啟發而催生的項目。除了擁有他們的所有功能之外，還擁有以下4個特點：
簡單：基於http+json的api讓你用curl命令就可以輕鬆使用。
安全：可選SSL客戶認證機制。
快速：每個實例每秒支持一千次寫操作。
可信：使用Raft演算法充分實現了分散式。

四層服務發現
先一張圖解釋一下網路七層協議：

k8s提供了兩種方式進行服務發現：
環境變數：當創建一個Pod的時候，kubelet會在該Pod中註入集群內所有Service的相關環境變數。需要註意的是，要想一個Pod中註入某個Service的環境變數，則必須Service要先比該Pod創建。這一點，幾乎使得這種方式進行服務發現不可用。
比如，一個ServiceName為redis-master的Service，對應的ClusterIP:Port為10.0.0.11:6379，則對應的環境變數為：

DNS：可以通過cluster add-on的方式輕鬆的創建KubeDNS來對集群內的Service進行服務發現。
以上兩種方式，一個是基於tcp，眾所周知，DNS是基於UDP的，它們都是建立在四層協議之上。

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

同一個Pod里的容器之間僅需通過localhost就能互相通信。一個Pod中的應用容器共用五種資源：
PID命名空間：Pod中的不同應用程式可以看到其他應用程式的進程ID。
網路命名空間：Pod中的多個容器能夠訪問同一個IP和埠範圍。
IPC命名空間：Pod中的多個容器能夠使用SystemV IPC或POSIX消息隊列進行通信。
UTS命名空間：Pod中的多個容器共用一個主機名。
Volumes(共用存儲捲)：Pod中的各個容器可以訪問在Pod級別定義的Volumes。
Pod的生命周期通過Replication Controller來管理；通過模板進行定義，然後分配到一個Node上運行，在Pod所包含容器運行結束後，Pod結束。
Kubernetes為Pod設計了一套獨特的網路配置，包括：為每個Pod分配一個IP地址，使用Pod名作為榮期間通信的主機名等。

六個CNI常用插件
CNI(Container Network Interface)容器網路介面，是Linux容器網路配置的一組標準和庫，用戶需要根據這些標準和庫來開發自己的容器網路插件。CNI只專註解決容器網路連接和容器銷毀時的資源釋放，提供一套框架，所以CNI可以支持大量不同的網路模式，並且容易實現。
下麵用一張圖表示六個CNI常用插件：

七層負載均衡
提負載均衡就不得不先提伺服器之間的通信。
IDC(Internet Data Center),也可稱 數據中心、機房，用來放置伺服器。IDC網路是伺服器間通信的橋梁。

上圖裡畫了很多網路設備，它們都是幹啥用的呢？
路由器、交換機、MGW/NAT都是網路設備，按照性能、內外網劃分不同的角色。
內網接入交換機：也稱為TOR(top of rack),是伺服器接入網路的設備。每台內網接入交換機下聯40-48台伺服器，使用一個掩碼為/24的網段作為伺服器內網網段。
內網核心交換機：負責IDC內各內網接入交換機的流量轉發及跨IDC流量轉發。
MGW/NAT：MGW即LVS用來做負載均衡，NAT用於內網設備訪問外網時做地址轉換。
外網核心路由器：通過靜態互聯運營商或BGP互聯美團統一外網平臺。
先說說各層負載均衡：
二層負載均衡：基於MAC地址的二層負載均衡。
三層負載均衡：基於IP地址的負載均衡。
四層負載均衡：基於IP+埠的負載均衡。
七層負載均衡：基於URL等應用層信息的負載均衡。
這裡用一張圖來說說四層和七層負載均衡的區別：

上面四層服務發現講的主要是k8s原生的kube-proxy方式。K8s關於服務的暴露主要是通過NodePort方式，通過綁定minion主機的某個埠，然後進行pod的請求轉發和負載均衡，但這種方式有下麵的缺陷：
Service可能有很多個，如果每個都綁定一個node主機埠的話，主機需要開放外圍的埠進行服務調用，管理混亂。
無法應用很多公司要求的防火牆規則。
理想的方式是通過一個外部的負載均衡器，綁定固定的埠，比如80，然後根據功能變數名稱或者服務名向後面的Service ip轉發，Nginx很好的解決了這個需求，但問題是如果有的心得服務加入，如何去修改Nginx的配置，並且載入這些配置？Kubernetes給出的方案就是Ingress。這是一個基於7層的方案。

八種隔離維度

K8s集群調度這邊需要對上面從上到下從粗粒度到細粒度的隔離做相應的調度策略。

九個網路模型原則
K8s網路模型要符合4個基礎原則，3個網路要求原則，1個架構原則，1個IP原則。
每個Pod都擁有一個獨立的IP地址，而且假定所有Pod都在一個可以直接連通的、扁平的網路空間中，不管是否運行在同一Node上都可以通過Pod的IP來訪問。
K8s中的Pod的IP是最小粒度IP。同一個Pod內所有的容器共用一個網路堆棧，該模型稱為IP-per-Pod模型。
Pod由docker0實際分配的IP，Pod內部看到的IP地址和埠與外部保持一致。同一個Pod內的不同容器共用網路，可以通過localhost來訪問對方的埠，類似同一個VM內不同的進程。
IP-per-Pod模型從埠分配、功能變數名稱解析、服務發現、負載均衡、應用配置等角度看，Pod可以看做是一臺獨立的VM或物理機。
所有容器都可以不用NAT的方式同別的容器通信。
所有節點都可以在不同NAT方式下同所有容器心痛，反之亦然。
容器的地址和別人看到的地址是同一個地址。
要符合下麵的架構：

由上圖架構引申出來IP概念從集群外部到集群內部

十類IP地址
大家都知道IP地址分為ABCDE類，另外還有5類特殊用途的IP。

1. A類
   1.0.0.0-1226.255.255.255，預設子網掩碼/8，即255.0.0.0
   2.B類
   128.0.0.0-191.255.255.255，預設子網掩碼/16，即255.255.0.0
   3.C類
   192.0.0.0-223.255.255.255，預設子網掩碼/24，即255.255.255.0
   4.D類
   224.0.0.0-239.255.255.255，一般用於組播
   5.E類
   240.0.0.0-255.255.255.255(其中255.255.255.255為全網廣播地址),E類地址一般用於研究用途
2. 0.0.0.0
   嚴格來說，0.0.0.0已經不是一個真正意義上的IP地址了。它表示的是這樣一個集合：所有不清楚的主機和目的網路。這裡的不清楚是指在本機的路由表裡沒有特定條目指明如何到達。作為預設路由。
   7.127.0.0.1
   本機地址
3. 224.0.0.1
   組播地址。如果你的主機開啟了IRDP（internet路由發現，使用組播功能），那麼你的主機路由表中應該有這樣一條路由。
4. 169.254.x.x
   使用了DHCP功能自動獲取了IP的主機，DHCP伺服器發生故障，或響應時間太長而超出了一個系統規定的時間，系統會為你分配這樣一個IP，代表網路不能正常運行。

5. 10.xxx、172.16.x.x~172.31.x.x、192.168.x.x
   私有地址，大量用於企業內部。保留這樣的地址是為了避免亦或是哪個接入公網時引起地址混亂。

   百級產品線接入；千級物理機部署；萬級容器儲備；億級日服務人次是我們的近期目標，歡迎新美大兄弟部門試用(^__^)

關於作者

曉靜，20歲時畢業於東北大學電腦系。在畢業後的第一家公司由於出眾的語言天賦，在1年的時間里從零開始學日語並以超高分通過了國際日語一級考試，擔當兩年日語翻譯的工作。後就職於人人網，轉型做互聯網開發。中國科學院心理學研究生。有近百個技術發明專利，創業公司合伙人。有日本東京，美國矽谷技術支持經驗。目前任美團點評技術專家（歡迎關註靜兒的個人技術公眾號：編程一生 ）,心法文章可參考我的《自動化管理之新人培養》