k8s已經(jīng)成為了絕對熱門的技術(shù),，一個上點規(guī)模的公司,，如果不搞k8s，都不好意思出去見人,。安裝k8s要突破種種網(wǎng)絡(luò)阻礙,，但更大的阻礙還在后面...

我發(fā)現(xiàn)，很多k8s的文章,，根本不說人話,，包括那要命的官網(wǎng)。

要弄明白k8s的細(xì)節(jié),，需要知道k8s是個什么東西,。它的主要功能，就是容器的調(diào)度--也就是把部署實例,，根據(jù)整體資源的使用狀況,，部署到任何地方。先不要扯別的,，那會擾亂視線,，增加復(fù)雜性。

注意任何這兩個字,，預(yù)示著你并不能夠通過常規(guī)的IP,、端口方式訪問部署的實例。復(fù)雜性由此而生。

我們學(xué)k8s,，就要看它要調(diào)度哪些資源,。以傳統(tǒng)的感覺來看，無非就是cpu,、內(nèi)存,、網(wǎng)絡(luò)、io等,。在了解怎么對這些資源調(diào)度之前,，先要搞懂什么叫Pod，這可是k8s的核心概念之一,。

搞不懂Pod,，就沒法玩k8s。

本文的腦圖,，可以在這里在線查看：http://mind./mind/cloud-k8s

1. Pod

pod是k8s調(diào)度的最小單元,，包含一個或者多個容器（這里的容器你可以暫時認(rèn)為是docker）。

Pod擁有一個唯一的IP地址,，在包含多個容器的時候,，依然是擁有一個IP地址，它是怎么辦到的呢,？

xjjdog之前寫過兩篇Docker原理的文章,，指出其中兩個使用到的底層技術(shù)，就是namespace和cgroup,，k8s在使用多個容器的時候,，用到的就是共享namespace，這樣Pod里的容器就可以通過localhost通信了,，就像兩個進程一樣,。同理的，Pod 可以掛載多個共享的存儲卷（Volume）,，這時內(nèi)部的各個容器就可以訪問共享的 Volume 進行數(shù)據(jù)的讀寫,。

一些邊車(Sidecar)，以及存活探針等,，也是以容器的形式,，存在于Pod中的。所以Pod是一個大雜燴,，它取代了docker容器的一部分工作（這既是Pause容器的職責(zé)）,，比如創(chuàng)建一些共享的net namespace等。

那如何表示,、聲明一個Pod呢？又如何指定這些容器與Pod的關(guān)系呢？k8s選用了yaml這種配置方式,，初衷是避免過度的API設(shè)計,。

很好，這又引入了另外一個問題,，那就是yml文件的膨脹,。所有的k8s運維，都有過被yml文件給支配的恐懼,。

沒有銀彈,，只不過把問題轉(zhuǎn)移到另外一個場景罷了。

聲明一個Pod,，就是寫yml文件,。一個Pod的yml樣例，可能長得像下面這樣,。

注意kind這個選項,，這將是k8s概念膨脹的噩夢！k8s的各種配置,，基本上都是圍著這里轉(zhuǎn),。哦對了，要讓這些yml文件生效,，你需要用到kubectl 命令,，就像這樣。

kubectl create -f ./bcmall.yaml

訪問一個Pod,，可以通過它的IP,，也可以通過內(nèi)部的域名（這時候就需要CoreDNS）。當(dāng)這么用的時候,，其實Pod的表現(xiàn),，就相當(dāng)于一臺普通的機器，里面的容器就是一堆進程而已,。

2. 探針和鉤子

一個Pod被調(diào)度之后,，就要進行初始化。初始化肯定是得有一個反饋的,，否則都不知道最終有沒有啟動成功,。這些健康檢查的功能，叫做探針（Probe）,，一個比較怪異的英文名詞,。

常見的有l(wèi)ivenessProbe、readinessProbe,、startupProbe等三種探針,。

livenessProbe有點像心跳,，如果判定不在線了，就會把它干掉,；readinessProbe一般表示就緒狀態(tài),，也比較像心跳，證明你的服務(wù)在正常跑著,；startupProbe用于判斷容器是否已經(jīng)啟動好,，避免一些超時等，比如你的JVM啟動完畢了,，才能對外提供服務(wù),。

一般，花費120s startupProbe的啟動實踐,，每隔5s檢測一下livenessProbe,，每隔10s檢測一下readinessProbe,是常用的操作。

這些信息,，也是在yml中配置的,，具體的配置層次如何，這里不羅嗦,，您就查文檔去吧,。

再說一下鉤子（Hook）。主要有PostStart和PreStop兩種,。PostStart 可以在容器啟動之后就執(zhí)行,，PreStop 則在容器被終止之前被執(zhí)行。這沒什么神奇的,，就是執(zhí)行一些shell腳本而已,，只不過比較常用，就提升到了關(guān)鍵字的級別,。

我們來看看它長什么樣子,。由于這些配置文件大同小異，后面就不再貼這樣的代碼了,。

3. 高可用引起的名詞爆炸

上面說到,，yaml的復(fù)雜性，是由于kind的種類多所引起的,。首先我們要接觸的,，就是ReplicaSet。

我們需要多個副本,，才能做高可用,。

原因很簡單，一個Pod就相當(dāng)于一臺機器,，當(dāng)?shù)糁?，就無法提供服務(wù)了,，這是哪門子的高可用？所以對等的Pod,，要有多份才行,。

ReplicaSet簡稱RS,，可以讓你的Pod數(shù)量一直保持在某個水平,。但它在操作起來還是有點麻煩了，所以一般使用更加高級的Deployment,。Deployment可以實現(xiàn)一些滾動升級的需求,，但前提是你需要在spec.template.metadata.labels中設(shè)置了相應(yīng)的鍵值對。

k8s的一些過濾工作,，都是通過labels來實現(xiàn)的,。這其實是一種非常折衷的做法，因為它本身并沒有做一些類似于sql查詢之類的工作,，就只能在這一堆map的鍵值對上做文章,。比如這樣：

kubectl get pod -n demo -l app=nginx,version=v1

是不是很魔幻的寫法？不要緊,，習(xí)慣了就好了,。

這些yml配置，通常都是一環(huán)套一環(huán)的,，還會有交叉引用,，所以也會有優(yōu)先級。高階的kind會直接順帶把低階的kind一起創(chuàng)建了,，屬于一個級聯(lián)關(guān)系,。

一切不過是yml文件包了一層而已。

好了,，我們要接觸下一個kind：service了,。

為什么需要Service？因為我們上面創(chuàng)建的Pod,，哪怕是Deployment創(chuàng)建的Pod,，你訪問它都要費些功夫。雖然Pod有IP,，但如果它重啟了,，或者銷毀了，IP就會動態(tài)變化,。因為Pod是被調(diào)度的,，它并不知道自己會被調(diào)度到哪一臺機器。

Service這個東西,，就是要提供一種非IP的訪問途徑,，使得不論Pod在哪里,，我們都能訪問的到它。

如圖所示,，通過Labels的過濾,，可以把多個Pod歸結(jié)為一類，然后以某種類型對外暴露服務(wù),。Service說白了也是一個組合后的東西,。

對外訪問的類型，這里要著重說明一下,，因為它重要,，所以要敲黑板。主要有4種：

• ClusterIP 創(chuàng)建一個虛擬的IP,，唯一且不可修改,。所有訪問該IP的請求，都將被iptables轉(zhuǎn)發(fā)到后端,。這是默認(rèn)的行為,，就是一個coredns的插件
• NodePort 提供一個靜態(tài)端口（NodePort）來暴露服務(wù)，主要使用的技術(shù)是NAT
• LoadBalancer  LoadBalancer主要用于做外部的服務(wù)發(fā)現(xiàn),，即暴露給集群外部的訪問
• ExternalName 使用較少,，感興趣的可以自行了解

但是等等。k8s是如何實現(xiàn)跨主機的Pod相互訪問的呢,？

在單個Node上的Pod相互訪問可以理解,，直接通過docker0網(wǎng)橋分配的IP，就可相互訪問,。

那k8s的底層網(wǎng)絡(luò)是真么設(shè)置的呢,？答案可能令人沮喪。k8s本身并不負(fù)責(zé)網(wǎng)絡(luò)管理,，也不為容器提供具體的網(wǎng)絡(luò)設(shè)置,，它是通過CNI（容器網(wǎng)絡(luò)接口）來實現(xiàn)的。在不同的Node之上,，不同的Pod訪問就費了點勁,，這正是CNI的工作。常用的CNI插件有：Flannel,、Calico,、Canal、Weave,。

沒錯,，又是一堆名詞，而且各個都很難搞,。

網(wǎng)絡(luò)方面是k8s最復(fù)雜的知識點,，框架也奇多,，后面的文章會專門進行介紹。

4. 內(nèi)部組件

在開啟更多的Kind之前,，我們來看一下k8s的內(nèi)部組件,。

下面這張圖，就是官網(wǎng)的一張圖片,，說明了k8s的一系列必要的組件,。其中，etcd根本就不是這個體系里的,，但k8s的一些持久化狀態(tài),，需要有個地方存，就引入了這么一個組件,，用來存儲配置信息。

其中左半部分,，是k8s自身的組件,；右半部分，就在每個Node（也就是物理機）上的守護進程,。它們的作用如下：

• kube-apiserver 提供Rest接口,，屬于k8s的靈魂，所有的認(rèn)證,、授權(quán),、訪問控制、服務(wù)發(fā)現(xiàn)等功能,，都通過它來暴露
• kube-scheduler 一看就是個調(diào)度組件,，實際上它的作用也是這樣。它會監(jiān)聽未調(diào)度的 Pod,，實現(xiàn)你指定的目標(biāo)
• kube-controller-manager 負(fù)責(zé)維護整個k8s集群的狀態(tài),。注意是k8s集群的狀態(tài)，它不管Pod
• kubelet  這是個守護進程,，用來和apiserver通信,，匯報自己Node的狀態(tài)；一些調(diào)度命令,，也是通過kubelet來接收執(zhí)行任務(wù)
• kube-proxy kube-proxy其實就是管理service的訪問入口,包括集群內(nèi)Pod到Service的訪問和集群外訪問service,。我們上面提到的四種模式，就是通過proxy進行轉(zhuǎn)發(fā)的

這些組件的職責(zé),，已經(jīng)是非常非常清楚了,。難點還是在多種Kind概念上。

5. 更多概念

圖中的這些概念,，本質(zhì)上都是在Pod之上,，又包了一層,。層次越高，功能越抽象,，依賴的配置也越多,。下面將挑主要的進行介紹。

• StatefulSet Deployment部署后的實例,，它的id都是隨機的,，比如bcmall-deployment-5d45f98bd9，它是無狀態(tài)的,。與此對用的是StatefulSet,，生成的實例名稱是類似bcmall-deployment-1這樣的。它具備固定的網(wǎng)絡(luò)標(biāo)記,，比如主機名,，域名等，可以按照順序來部署和擴展,，非常適合類似MySQL這樣的實例部署
• DaemonSet 用于確保集群中的每一個節(jié)點只運行特定的pod副本,，通常用于實現(xiàn)系統(tǒng)級后臺任務(wù)
• configMap和Secret 顧名思義，就是做配置用的,，因為容器或多或少會需要外部傳入一些環(huán)境變量,。可以用來實現(xiàn)業(yè)務(wù)配置的統(tǒng)一管理,， 允許將配置文件與鏡像文件分離,，以使容器化的應(yīng)用程序具有可移植性
• PV和PVC  業(yè)務(wù)運行就需要存儲，可以通過PV進行定義,。PV的生命周期獨立于Pod的生命周期,，就是一段網(wǎng)絡(luò)存儲；PVC是用戶對于存儲的需求：Pod消耗節(jié)點資源,，PVC消耗PV資源,，PVC和PV是一一對應(yīng)的。沒錯,，它們都是通過yml文件聲明的
• **StorageClass ** 可以實現(xiàn)動態(tài)PV,，是更進一步的封裝
• Job 只要完成就立即退出，不需要重啟或重建
• Cronjob 周期性任務(wù)控制,，不需要持續(xù)后臺運行
• CRD

6. 資源限制

很好,，我們終于要聊一點資源限制方面的內(nèi)容了。k8s的資源限制,，仍然是通過cgroup來實現(xiàn)的,。

k8s提供了requests和limits 兩種類型參數(shù)對資源進行預(yù)分配和使用限制。

不要被這兩個詞給迷惑了。requests就相當(dāng)于JVM參數(shù)中的-Xms,，limits就相當(dāng)于-Xmx,。所以，如果你類比著把這兩個值設(shè)置成一樣的,，是一種最佳的實踐方式,。

只是它的設(shè)置有點怪異：

內(nèi)存的單位是Mi，而cpu的單位是m,，要多別扭有多別扭,，但它是有原因的。

m是毫核的意思,。比如,，我們的操作系統(tǒng)有4核，把它乘以1000,，那就是總CPU資源是4000毫核,。如果你想要你的應(yīng)用最多占用1/4核，那就設(shè)置成250m,。

再來看內(nèi)存,，Mi是MiB的意思，我也搞不懂為啥不用MB,，而使用Mi，可能是想讓你印象深刻吧（MB和MiB還真不一樣）,。

若內(nèi)存使用超出限制,，會引發(fā)系統(tǒng)的OOM機制，但CPU不會,，頂多會影響系統(tǒng)運行罷了,。

k8s還提供了叫做LimitRange和ResourceQuota的Kind，用來限定CPU和Memory的申請范圍,，功能更加高級,。

7. 集群搭建工具

k8s的集群搭建，常見的有kind,，minikube,，kubeadm，rancher2等,。其中rancher2可以說是相對來說比較容易的方式,。它考慮了一些網(wǎng)絡(luò)不通的因素，有一些推薦的代理選項,，對于新手來說,，拿來嘗嘗鮮還是很好用的。

但在正常的使用中,，還是推薦你使用kubeadm這個工具,，這是官方維護和推薦的搭建工具,，并做到了向下兼容，按照官方的指引,，只需要kubeadm init就能搭建完畢,。至于什么監(jiān)控、日志等,，反倒是好處理的了,。

k8s最麻煩的有三點：

• yml文件概念爆炸
• 網(wǎng)絡(luò)方案多樣、復(fù)雜
• 權(quán)限,、證書配置繁瑣

搞懂了這三個方面,，可以說玩轉(zhuǎn)k8s就沒問題了。