Kubernetes設(shè)計(jì)理念與分布式系統(tǒng)

分析和理解Kubernetes的設(shè)計(jì)理念可以使我們更深入地了解Kubernetes系統(tǒng)，更好地利用它管理分布式部署的云原生應(yīng)用，另一方面也可以讓我們借鑒其在分布式系統(tǒng)設(shè)計(jì)方面的經(jīng)驗(yàn)儒旬。

分層架構(gòu)

Kubernetes設(shè)計(jì)理念和功能其實(shí)就是一個(gè)類似Linux的分層架構(gòu)旷太，如下圖所示

圖片 - 分層架構(gòu)示意圖

核心層：Kubernetes最核心的功能谱轨，對外提供API構(gòu)建高層的應(yīng)用，對內(nèi)提供插件式應(yīng)用執(zhí)行環(huán)境

應(yīng)用層：部署（無狀態(tài)應(yīng)用访递、有狀態(tài)應(yīng)用、批處理任務(wù)同辣、集群應(yīng)用等）和路由（服務(wù)發(fā)現(xiàn)拷姿、DNS解析等）

管理層：系統(tǒng)度量（如基礎(chǔ)設(shè)施、容器和網(wǎng)絡(luò)的度量）旱函，自動(dòng)化（如自動(dòng)擴(kuò)展响巢、動(dòng)態(tài)Provision等）以及策略管理（RBAC、Quota棒妨、PSP踪古、NetworkPolicy等）

接口層：kubectl命令行工具奈辰、客戶端SDK以及集群聯(lián)邦

生態(tài)系統(tǒng)：在接口層之上的龐大容器集群管理調(diào)度的生態(tài)系統(tǒng)溜腐，可以劃分為兩個(gè)范疇

Kubernetes外部：日志、監(jiān)控恨统、配置管理纷纫、CI枕扫、CD、Workflow辱魁、FaaS烟瞧、OTS應(yīng)用、ChatOps等

Kubernetes內(nèi)部：CRI染簇、CNI参滴、CVI、鏡像倉庫剖笙、Cloud Provider卵洗、集群自身的配置和管理等

API設(shè)計(jì)原則

對于云計(jì)算系統(tǒng)，系統(tǒng)API實(shí)際上處于系統(tǒng)設(shè)計(jì)的統(tǒng)領(lǐng)地位，正如本文前面所說过蹂，Kubernetes集群系統(tǒng)每支持一項(xiàng)新功能十绑，引入一項(xiàng)新技術(shù)，一定會(huì)新引入對應(yīng)的API對象酷勺，支持對該功能的管理操作本橙，理解掌握的API，就好比抓住了Kubernetes系統(tǒng)的牛鼻子脆诉。Kubernetes系統(tǒng)API的設(shè)計(jì)有以下幾條原則：

所有API應(yīng)該是聲明式的甚亭。正如前文所說，聲明式的操作击胜，相對于命令式操作亏狰，對于重復(fù)操作的效果是穩(wěn)定的，這對于容易出現(xiàn)數(shù)據(jù)丟失或重復(fù)的分布式環(huán)境來說是很重要的偶摔。另外暇唾，聲明式操作更容易被用戶使用，可以使系統(tǒng)向用戶隱藏實(shí)現(xiàn)的細(xì)節(jié)辰斋，隱藏實(shí)現(xiàn)的細(xì)節(jié)的同時(shí)策州，也就保留了系統(tǒng)未來持續(xù)優(yōu)化的可能性。此外宫仗，聲明式的API够挂，同時(shí)隱含了所有的API對象都是名詞性質(zhì)的，例如Service藕夫、Volume這些API都是名詞孽糖，這些名詞描述了用戶所期望得到的一個(gè)目標(biāo)分布式對象。

API對象是彼此互補(bǔ)而且可組合的汁胆。這里面實(shí)際是鼓勵(lì)A(yù)PI對象盡量實(shí)現(xiàn)面向?qū)ο笤O(shè)計(jì)時(shí)的要求梭姓，即“高內(nèi)聚，松耦合”嫩码，對業(yè)務(wù)相關(guān)的概念有一個(gè)合適的分解誉尖，提高分解出來的對象的可重用性。事實(shí)上铸题，Kubernetes這種分布式系統(tǒng)管理平臺(tái)铡恕，也是一種業(yè)務(wù)系統(tǒng)，只不過它的業(yè)務(wù)就是調(diào)度和管理容器服務(wù)丢间。

高層API以操作意圖為基礎(chǔ)設(shè)計(jì)探熔。如何能夠設(shè)計(jì)好API，跟如何能用面向?qū)ο蟮姆椒ㄔO(shè)計(jì)好應(yīng)用系統(tǒng)有相通的地方烘挫，高層設(shè)計(jì)一定是從業(yè)務(wù)出發(fā)诀艰，而不是過早的從技術(shù)實(shí)現(xiàn)出發(fā)柬甥。因此，針對Kubernetes的高層API設(shè)計(jì)其垄，一定是以Kubernetes的業(yè)務(wù)為基礎(chǔ)出發(fā)苛蒲，也就是以系統(tǒng)調(diào)度管理容器的操作意圖為基礎(chǔ)設(shè)計(jì)。

低層API根據(jù)高層API的控制需要設(shè)計(jì)绿满。設(shè)計(jì)實(shí)現(xiàn)低層API的目的臂外，是為了被高層API使用，考慮減少冗余喇颁、提高重用性的目的漏健，低層API的設(shè)計(jì)也要以需求為基礎(chǔ)，要盡量抵抗受技術(shù)實(shí)現(xiàn)影響的誘惑橘霎。

盡量避免簡單封裝蔫浆，不要有在外部API無法顯式知道的內(nèi)部隱藏的機(jī)制。簡單的封裝茎毁，實(shí)際沒有提供新的功能克懊，反而增加了對所封裝API的依賴性。內(nèi)部隱藏的機(jī)制也是非常不利于系統(tǒng)維護(hù)的設(shè)計(jì)方式七蜘，例如StatefulSet和ReplicaSet，本來就是兩種Pod集合墙懂，那么Kubernetes就用不同API對象來定義它們橡卤，而不會(huì)說只用同一個(gè)ReplicaSet，內(nèi)部通過特殊的算法再來區(qū)分這個(gè)ReplicaSet是有狀態(tài)的還是無狀態(tài)损搬。

API操作復(fù)雜度與對象數(shù)量成正比碧库。這一條主要是從系統(tǒng)性能角度考慮，要保證整個(gè)系統(tǒng)隨著系統(tǒng)規(guī)模的擴(kuò)大巧勤，性能不會(huì)迅速變慢到無法使用嵌灰，那么最低的限定就是API的操作復(fù)雜度不能超過O(N)，N是對象的數(shù)量颅悉，否則系統(tǒng)就不具備水平伸縮性了沽瞭。

API對象狀態(tài)不能依賴于網(wǎng)絡(luò)連接狀態(tài)。由于眾所周知剩瓶，在分布式環(huán)境下驹溃，網(wǎng)絡(luò)連接斷開是經(jīng)常發(fā)生的事情，因此要保證API對象狀態(tài)能應(yīng)對網(wǎng)絡(luò)的不穩(wěn)定延曙，API對象的狀態(tài)就不能依賴于網(wǎng)絡(luò)連接狀態(tài)豌鹤。

盡量避免讓操作機(jī)制依賴于全局狀態(tài)，因?yàn)樵诜植际较到y(tǒng)中要保證全局狀態(tài)的同步是非常困難的枝缔。

控制機(jī)制設(shè)計(jì)原則

控制邏輯應(yīng)該只依賴于當(dāng)前狀態(tài)布疙。這是為了保證分布式系統(tǒng)的穩(wěn)定可靠，對于經(jīng)常出現(xiàn)局部錯(cuò)誤的分布式系統(tǒng)，如果控制邏輯只依賴當(dāng)前狀態(tài)灵临，那么就非常容易將一個(gè)暫時(shí)出現(xiàn)故障的系統(tǒng)恢復(fù)到正常狀態(tài)截型，因?yàn)槟阒灰獙⒃撓到y(tǒng)重置到某個(gè)穩(wěn)定狀態(tài)，就可以自信的知道系統(tǒng)的所有控制邏輯會(huì)開始按照正常方式運(yùn)行俱诸。

假設(shè)任何錯(cuò)誤的可能菠劝，并做容錯(cuò)處理。在一個(gè)分布式系統(tǒng)中出現(xiàn)局部和臨時(shí)錯(cuò)誤是大概率事件睁搭。錯(cuò)誤可能來自于物理系統(tǒng)故障赶诊，外部系統(tǒng)故障也可能來自于系統(tǒng)自身的代碼錯(cuò)誤，依靠自己實(shí)現(xiàn)的代碼不會(huì)出錯(cuò)來保證系統(tǒng)穩(wěn)定其實(shí)也是難以實(shí)現(xiàn)的园骆，因此要設(shè)計(jì)對任何可能錯(cuò)誤的容錯(cuò)處理舔痪。

盡量避免復(fù)雜狀態(tài)機(jī)，控制邏輯不要依賴無法監(jiān)控的內(nèi)部狀態(tài)锌唾。因?yàn)榉植际较到y(tǒng)各個(gè)子系統(tǒng)都是不能嚴(yán)格通過程序內(nèi)部保持同步的锄码，所以如果兩個(gè)子系統(tǒng)的控制邏輯如果互相有影響，那么子系統(tǒng)就一定要能互相訪問到影響控制邏輯的狀態(tài)晌涕，否則滋捶，就等同于系統(tǒng)里存在不確定的控制邏輯。

假設(shè)任何操作都可能被任何操作對象拒絕余黎，甚至被錯(cuò)誤解析重窟。由于分布式系統(tǒng)的復(fù)雜性以及各子系統(tǒng)的相對獨(dú)立性，不同子系統(tǒng)經(jīng)常來自不同的開發(fā)團(tuán)隊(duì)惧财，所以不能奢望任何操作被另一個(gè)子系統(tǒng)以正確的方式處理巡扇，要保證出現(xiàn)錯(cuò)誤的時(shí)候，操作級別的錯(cuò)誤不會(huì)影響到系統(tǒng)穩(wěn)定性垮衷。

每個(gè)模塊都可以在出錯(cuò)后自動(dòng)恢復(fù)厅翔。由于分布式系統(tǒng)中無法保證系統(tǒng)各個(gè)模塊是始終連接的，因此每個(gè)模塊要有自我修復(fù)的能力搀突，保證不會(huì)因?yàn)檫B接不到其他模塊而自我崩潰刀闷。

每個(gè)模塊都可以在必要時(shí)優(yōu)雅地降級服務(wù)。所謂優(yōu)雅地降級服務(wù)描姚，是對系統(tǒng)魯棒性的要求涩赢，即要求在設(shè)計(jì)實(shí)現(xiàn)模塊時(shí)劃分清楚基本功能和高級功能，保證基本功能不會(huì)依賴高級功能轩勘，這樣同時(shí)就保證了不會(huì)因?yàn)楦呒壒δ艹霈F(xiàn)故障而導(dǎo)致整個(gè)模塊崩潰筒扒。根據(jù)這種理念實(shí)現(xiàn)的系統(tǒng)，也更容易快速地增加新的高級功能绊寻，因?yàn)椴槐負(fù)?dān)心引入高級功能影響原有的基本功能花墩。

Kubernetes的核心技術(shù)概念和API對象

API對象是Kubernetes集群中的管理操作單元悬秉。Kubernetes集群系統(tǒng)每支持一項(xiàng)新功能，引入一項(xiàng)新技術(shù)冰蘑，一定會(huì)新引入對應(yīng)的API對象和泌，支持對該功能的管理操作。例如副本集Replica Set對應(yīng)的API對象是RS祠肥。

每個(gè)API對象都有3大類屬性：元數(shù)據(jù)metadata武氓、規(guī)范spec和狀態(tài)status。元數(shù)據(jù)是用來標(biāo)識(shí)API對象的仇箱，每個(gè)對象都至少有3個(gè)元數(shù)據(jù)：namespace县恕，name和uid；除此以外還有各種各樣的標(biāo)簽labels用來標(biāo)識(shí)和匹配不同的對象剂桥，例如用戶可以用標(biāo)簽env來標(biāo)識(shí)區(qū)分不同的服務(wù)部署環(huán)境忠烛，分別用env=dev、env=testing权逗、env=production來標(biāo)識(shí)開發(fā)美尸、測試、生產(chǎn)的不同服務(wù)斟薇。規(guī)范描述了用戶期望Kubernetes集群中的分布式系統(tǒng)達(dá)到的理想狀態(tài)（Desired State）师坎，例如用戶可以通過復(fù)制控制器Replication Controller設(shè)置期望的Pod副本數(shù)為3；status描述了系統(tǒng)實(shí)際當(dāng)前達(dá)到的狀態(tài)（Status）堪滨，例如系統(tǒng)當(dāng)前實(shí)際的Pod副本數(shù)為2屹耐；那么復(fù)制控制器當(dāng)前的程序邏輯就是自動(dòng)啟動(dòng)新的Pod，爭取達(dá)到副本數(shù)為3椿猎。

Kubernetes中所有的配置都是通過API對象的spec去設(shè)置的，也就是用戶通過配置系統(tǒng)的理想狀態(tài)來改變系統(tǒng)寿弱，這是Kubernetes重要設(shè)計(jì)理念之一犯眠，即所有的操作都是聲明式（Declarative）的而不是命令式（Imperative）的。聲明式操作在分布式系統(tǒng)中的好處是穩(wěn)定症革，不怕丟操作或運(yùn)行多次筐咧，例如設(shè)置副本數(shù)為3的操作運(yùn)行多次也還是一個(gè)結(jié)果，而給副本數(shù)加1的操作就不是聲明式的噪矛，運(yùn)行多次結(jié)果就錯(cuò)了量蕊。

Pod

Kubernetes有很多技術(shù)概念，同時(shí)對應(yīng)很多API對象艇挨，最重要的也是最基礎(chǔ)的是Pod残炮。Pod是在Kubernetes集群中運(yùn)行部署應(yīng)用或服務(wù)的最小單元，它是可以支持多容器的缩滨。Pod的設(shè)計(jì)理念是支持多個(gè)容器在一個(gè)Pod中共享網(wǎng)絡(luò)地址和文件系統(tǒng)势就，可以通過進(jìn)程間通信和文件共享這種簡單高效的方式組合完成服務(wù)泉瞻。Pod對多容器的支持是K8最基礎(chǔ)的設(shè)計(jì)理念。比如你運(yùn)行一個(gè)操作系統(tǒng)發(fā)行版的軟件倉庫苞冯，一個(gè)Nginx容器用來發(fā)布軟件袖牙，另一個(gè)容器專門用來從源倉庫做同步，這兩個(gè)容器的鏡像不太可能是一個(gè)團(tuán)隊(duì)開發(fā)的舅锄，但是他們一塊兒工作才能提供一個(gè)微服務(wù)鞭达；這種情況下，不同的團(tuán)隊(duì)各自開發(fā)構(gòu)建自己的容器鏡像皇忿，在部署的時(shí)候組合成一個(gè)微服務(wù)對外提供服務(wù)畴蹭。

Pod是Kubernetes集群中所有業(yè)務(wù)類型的基礎(chǔ)，可以看作運(yùn)行在K8集群中的小機(jī)器人禁添，不同類型的業(yè)務(wù)就需要不同類型的小機(jī)器人去執(zhí)行撮胧。目前Kubernetes中的業(yè)務(wù)主要可以分為長期伺服型（long-running）、批處理型（batch）老翘、節(jié)點(diǎn)后臺(tái)支撐型（node-daemon）和有狀態(tài)應(yīng)用型（stateful application）芹啥；分別對應(yīng)的小機(jī)器人控制器為Deployment、Job铺峭、DaemonSet和StatefulSet墓怀，本文后面會(huì)一一介紹。

副本控制器（Replication Controller卫键，RC）

RC是Kubernetes集群中最早的保證Pod高可用的API對象傀履。通過監(jiān)控運(yùn)行中的Pod來保證集群中運(yùn)行指定數(shù)目的Pod副本。指定的數(shù)目可以是多個(gè)也可以是1個(gè)莉炉；少于指定數(shù)目钓账，RC就會(huì)啟動(dòng)運(yùn)行新的Pod副本；多于指定數(shù)目絮宁，RC就會(huì)殺死多余的Pod副本梆暮。即使在指定數(shù)目為1的情況下，通過RC運(yùn)行Pod也比直接運(yùn)行Pod更明智绍昂，因?yàn)镽C也可以發(fā)揮它高可用的能力啦粹，保證永遠(yuǎn)有1個(gè)Pod在運(yùn)行。RC是Kubernetes較早期的技術(shù)概念窘游，只適用于長期伺服型的業(yè)務(wù)類型唠椭，比如控制小機(jī)器人提供高可用的Web服務(wù)。

副本集（Replica Set忍饰，RS）

RS是新一代RC贪嫂，提供同樣的高可用能力，區(qū)別主要在于RS后來居上喘批，能支持更多種類的匹配模式撩荣。副本集對象一般不單獨(dú)使用铣揉，而是作為Deployment的理想狀態(tài)參數(shù)使用。

部署（Deployment）

部署表示用戶對Kubernetes集群的一次更新操作餐曹。部署是一個(gè)比RS應(yīng)用模式更廣的API對象逛拱，可以是創(chuàng)建一個(gè)新的服務(wù)，更新一個(gè)新的服務(wù)台猴，也可以是滾動(dòng)升級一個(gè)服務(wù)朽合。滾動(dòng)升級一個(gè)服務(wù)，實(shí)際是創(chuàng)建一個(gè)新的RS饱狂，然后逐漸將新RS中副本數(shù)增加到理想狀態(tài)曹步，將舊RS中的副本數(shù)減小到0的復(fù)合操作；這樣一個(gè)復(fù)合操作用一個(gè)RS是不太好描述的休讳，所以用一個(gè)更通用的Deployment來描述讲婚。以Kubernetes的發(fā)展方向，未來對所有長期伺服型的的業(yè)務(wù)的管理俊柔，都會(huì)通過Deployment來管理筹麸。

服務(wù)（Service）

RC、RS和Deployment只是保證了支撐服務(wù)的微服務(wù)Pod的數(shù)量雏婶，但是沒有解決如何訪問這些服務(wù)的問題物赶。一個(gè)Pod只是一個(gè)運(yùn)行服務(wù)的實(shí)例，隨時(shí)可能在一個(gè)節(jié)點(diǎn)上停止留晚，在另一個(gè)節(jié)點(diǎn)以一個(gè)新的IP啟動(dòng)一個(gè)新的Pod酵紫，因此不能以確定的IP和端口號(hào)提供服務(wù)。要穩(wěn)定地提供服務(wù)需要服務(wù)發(fā)現(xiàn)和負(fù)載均衡能力错维。服務(wù)發(fā)現(xiàn)完成的工作奖地，是針對客戶端訪問的服務(wù)，找到對應(yīng)的的后端服務(wù)實(shí)例赋焕。在K8集群中鹉动，客戶端需要訪問的服務(wù)就是Service對象。每個(gè)Service會(huì)對應(yīng)一個(gè)集群內(nèi)部有效的虛擬IP宏邮，集群內(nèi)部通過虛擬IP訪問一個(gè)服務(wù)。在Kubernetes集群中微服務(wù)的負(fù)載均衡是由Kube-proxy實(shí)現(xiàn)的缸血。Kube-proxy是Kubernetes集群內(nèi)部的負(fù)載均衡器蜜氨。它是一個(gè)分布式代理服務(wù)器，在Kubernetes的每個(gè)節(jié)點(diǎn)上都有一個(gè)捎泻；這一設(shè)計(jì)體現(xiàn)了它的伸縮性優(yōu)勢飒炎，需要訪問服務(wù)的節(jié)點(diǎn)越多，提供負(fù)載均衡能力的Kube-proxy就越多笆豁，高可用節(jié)點(diǎn)也隨之增多郎汪。與之相比赤赊，我們平時(shí)在服務(wù)器端做個(gè)反向代理做負(fù)載均衡，還要進(jìn)一步解決反向代理的負(fù)載均衡和高可用問題煞赢。

任務(wù)（Job）

Job是Kubernetes用來控制批處理型任務(wù)的API對象抛计。批處理業(yè)務(wù)與長期伺服業(yè)務(wù)的主要區(qū)別是批處理業(yè)務(wù)的運(yùn)行有頭有尾，而長期伺服業(yè)務(wù)在用戶不停止的情況下永遠(yuǎn)運(yùn)行照筑。Job管理的Pod根據(jù)用戶的設(shè)置把任務(wù)成功完成就自動(dòng)退出了吹截。成功完成的標(biāo)志根據(jù)不同的spec.completions策略而不同：單Pod型任務(wù)有一個(gè)Pod成功就標(biāo)志完成；定數(shù)成功型任務(wù)保證有N個(gè)任務(wù)全部成功凝危；工作隊(duì)列型任務(wù)根據(jù)應(yīng)用確認(rèn)的全局成功而標(biāo)志成功波俄。

后臺(tái)支撐服務(wù)集（DaemonSet）

長期伺服型和批處理型服務(wù)的核心在業(yè)務(wù)應(yīng)用，可能有些節(jié)點(diǎn)運(yùn)行多個(gè)同類業(yè)務(wù)的Pod蛾默，有些節(jié)點(diǎn)上又沒有這類Pod運(yùn)行懦铺；而后臺(tái)支撐型服務(wù)的核心關(guān)注點(diǎn)在Kubernetes集群中的節(jié)點(diǎn)（物理機(jī)或虛擬機(jī)），要保證每個(gè)節(jié)點(diǎn)上都有一個(gè)此類Pod運(yùn)行支鸡。節(jié)點(diǎn)可能是所有集群節(jié)點(diǎn)也可能是通過nodeSelector選定的一些特定節(jié)點(diǎn)冬念。典型的后臺(tái)支撐型服務(wù)包括，存儲(chǔ)苍匆，日志和監(jiān)控等在每個(gè)節(jié)點(diǎn)上支持Kubernetes集群運(yùn)行的服務(wù)刘急。

有狀態(tài)服務(wù)集（StatefulSet）

Kubernetes在1.3版本里發(fā)布了Alpha版的PetSet功能，在1.5版本里將PetSet功能升級到了Beta版本浸踩，并重新命名為StatefulSet叔汁，最終在1.9版本里成為正式GA版本。在云原生應(yīng)用的體系里检碗，有下面兩組近義詞据块；第一組是無狀態(tài)（stateless）、牲畜（cattle）折剃、無名（nameless）另假、可丟棄（disposable）；第二組是有狀態(tài)（stateful）怕犁、寵物（pet）边篮、有名（having name）、不可丟棄（non-disposable）奏甫。RC和RS主要是控制提供無狀態(tài)服務(wù)的戈轿，其所控制的Pod的名字是隨機(jī)設(shè)置的，一個(gè)Pod出故障了就被丟棄掉阵子，在另一個(gè)地方重啟一個(gè)新的Pod思杯，名字變了、名字和啟動(dòng)在哪兒都不重要挠进，重要的只是Pod總數(shù)色乾；而StatefulSet是用來控制有狀態(tài)服務(wù)誊册，StatefulSet中的每個(gè)Pod的名字都是事先確定的，不能更改暖璧。StatefulSet中Pod的名字的作用案怯，并不是《千與千尋》的人性原因，而是關(guān)聯(lián)與該P(yáng)od對應(yīng)的狀態(tài)漆撞。

對于RC和RS中的Pod殴泰，一般不掛載存儲(chǔ)或者掛載共享存儲(chǔ)，保存的是所有Pod共享的狀態(tài)浮驳，Pod像牲畜一樣沒有分別（這似乎也確實(shí)意味著失去了人性特征）悍汛；對于StatefulSet中的Pod，每個(gè)Pod掛載自己獨(dú)立的存儲(chǔ)至会，如果一個(gè)Pod出現(xiàn)故障离咐，從其他節(jié)點(diǎn)啟動(dòng)一個(gè)同樣名字的Pod，要掛載上原來Pod的存儲(chǔ)繼續(xù)以它的狀態(tài)提供服務(wù)奉件。

適合于StatefulSet的業(yè)務(wù)包括數(shù)據(jù)庫服務(wù)MySQL和PostgreSQL宵蛀，集群化管理服務(wù)ZooKeeper、etcd等有狀態(tài)服務(wù)县貌。StatefulSet的另一種典型應(yīng)用場景是作為一種比普通容器更穩(wěn)定可靠的模擬虛擬機(jī)的機(jī)制术陶。傳統(tǒng)的虛擬機(jī)正是一種有狀態(tài)的寵物，運(yùn)維人員需要不斷地維護(hù)它煤痕，容器剛開始流行時(shí)梧宫，我們用容器來模擬虛擬機(jī)使用，所有狀態(tài)都保存在容器里摆碉，而這已被證明是非常不安全塘匣、不可靠的。使用StatefulSet巷帝，Pod仍然可以通過漂移到不同節(jié)點(diǎn)提供高可用忌卤，而存儲(chǔ)也可以通過外掛的存儲(chǔ)來提供高可靠性，StatefulSet做的只是將確定的Pod與確定的存儲(chǔ)關(guān)聯(lián)起來保證狀態(tài)的連續(xù)性楞泼。

集群聯(lián)邦（Federation）

Kubernetes在1.3版本里發(fā)布了beta版的Federation功能驰徊。在云計(jì)算環(huán)境中，服務(wù)的作用距離范圍從近到遠(yuǎn)一般可以有：同主機(jī)（Host堕阔，Node）辣垒、跨主機(jī)同可用區(qū)（Available Zone）、跨可用區(qū)同地區(qū)（Region）印蔬、跨地區(qū)同服務(wù)商（Cloud Service Provider）、跨云平臺(tái)脱衙。Kubernetes的設(shè)計(jì)定位是單一集群在同一個(gè)地域內(nèi)侥猬，因?yàn)橥粋€(gè)地區(qū)的網(wǎng)絡(luò)性能才能滿足Kubernetes的調(diào)度和計(jì)算存儲(chǔ)連接要求例驹。而聯(lián)合集群服務(wù)就是為提供跨Region跨服務(wù)商Kubernetes集群服務(wù)而設(shè)計(jì)的。

每個(gè)Kubernetes Federation有自己的分布式存儲(chǔ)退唠、API Server和Controller Manager鹃锈。用戶可以通過Federation的API Server注冊該Federation的成員Kubernetes Cluster。當(dāng)用戶通過Federation的API Server創(chuàng)建瞧预、更改API對象時(shí)屎债，F(xiàn)ederation API Server會(huì)在自己所有注冊的子Kubernetes Cluster都創(chuàng)建一份對應(yīng)的API對象。在提供業(yè)務(wù)請求服務(wù)時(shí)垢油，Kubernetes Federation會(huì)先在自己的各個(gè)子Cluster之間做負(fù)載均衡盆驹，而對于發(fā)送到某個(gè)具體Kubernetes Cluster的業(yè)務(wù)請求，會(huì)依照這個(gè)Kubernetes Cluster獨(dú)立提供服務(wù)時(shí)一樣的調(diào)度模式去做Kubernetes Cluster內(nèi)部的負(fù)載均衡滩愁。而Cluster之間的負(fù)載均衡是通過域名服務(wù)的負(fù)載均衡來實(shí)現(xiàn)的躯喇。

Federation V1的設(shè)計(jì)是盡量不影響Kubernetes Cluster現(xiàn)有的工作機(jī)制，這樣對于每個(gè)子Kubernetes集群來說硝枉，并不需要更外層的有一個(gè)Kubernetes Federation廉丽，也就是意味著所有現(xiàn)有的Kubernetes代碼和機(jī)制不需要因?yàn)镕ederation功能有任何變化。

目前正在開發(fā)的Federation V2妻味，在保留現(xiàn)有Kubernetes API的同時(shí)正压，會(huì)開發(fā)新的Federation專用的API接口，詳細(xì)內(nèi)容可以在這里找到责球。

存儲(chǔ)卷（Volume）

Kubernetes集群中的存儲(chǔ)卷跟Docker的存儲(chǔ)卷有些類似焦履，只不過Docker的存儲(chǔ)卷作用范圍為一個(gè)容器，而Kubernetes的存儲(chǔ)卷的生命周期和作用范圍是一個(gè)Pod棕诵。每個(gè)Pod中聲明的存儲(chǔ)卷由Pod中的所有容器共享裁良。Kubernetes支持非常多的存儲(chǔ)卷類型，特別的校套，支持多種公有云平臺(tái)的存儲(chǔ)价脾，包括AWS，Google和Azure云笛匙；支持多種分布式存儲(chǔ)包括GlusterFS和Ceph侨把；也支持較容易使用的主機(jī)本地目錄emptyDir, hostPath和NFS。Kubernetes還支持使用Persistent Volume Claim即PVC這種邏輯存儲(chǔ)妹孙，使用這種存儲(chǔ)秋柄，使得存儲(chǔ)的使用者可以忽略后臺(tái)的實(shí)際存儲(chǔ)技術(shù)（例如AWS，Google或GlusterFS和Ceph）蠢正，而將有關(guān)存儲(chǔ)實(shí)際技術(shù)的配置交給存儲(chǔ)管理員通過Persistent Volume來配置骇笔。

持久存儲(chǔ)卷（Persistent Volume，PV）和持久存儲(chǔ)卷聲明（Persistent Volume Claim，PVC）

PV和PVC使得Kubernetes集群具備了存儲(chǔ)的邏輯抽象能力笨触，使得在配置Pod的邏輯里可以忽略對實(shí)際后臺(tái)存儲(chǔ)技術(shù)的配置懦傍，而把這項(xiàng)配置的工作交給PV的配置者，即集群的管理者芦劣。存儲(chǔ)的PV和PVC的這種關(guān)系粗俱，跟計(jì)算的Node和Pod的關(guān)系是非常類似的；PV和Node是資源的提供者虚吟，根據(jù)集群的基礎(chǔ)設(shè)施變化而變化寸认，由Kubernetes集群管理員配置；而PVC和Pod是資源的使用者串慰，根據(jù)業(yè)務(wù)服務(wù)的需求變化而變化偏塞，有Kubernetes集群的使用者即服務(wù)的管理員來配置。

節(jié)點(diǎn)（Node）

Kubernetes集群中的計(jì)算能力由Node提供模庐，最初Node稱為服務(wù)節(jié)點(diǎn)Minion烛愧，后來改名為Node。Kubernetes集群中的Node也就等同于Mesos集群中的Slave節(jié)點(diǎn)掂碱，是所有Pod運(yùn)行所在的工作主機(jī)怜姿，可以是物理機(jī)也可以是虛擬機(jī)。不論是物理機(jī)還是虛擬機(jī)疼燥，工作主機(jī)的統(tǒng)一特征是上面要運(yùn)行kubelet管理節(jié)點(diǎn)上運(yùn)行的容器沧卢。

密鑰對象（Secret）

Secret是用來保存和傳遞密碼、密鑰醉者、認(rèn)證憑證這些敏感信息的對象但狭。使用Secret的好處是可以避免把敏感信息明文寫在配置文件里。在Kubernetes集群中配置和使用服務(wù)不可避免的要用到各種敏感信息實(shí)現(xiàn)登錄撬即、認(rèn)證等功能立磁，例如訪問AWS存儲(chǔ)的用戶名密碼。為了避免將類似的敏感信息明文寫在所有需要使用的配置文件中剥槐，可以將這些信息存入一個(gè)Secret對象唱歧，而在配置文件中通過Secret對象引用這些敏感信息。這種方式的好處包括：意圖明確粒竖，避免重復(fù)颅崩，減少暴漏機(jī)會(huì)。

用戶帳戶（User Account）和服務(wù)帳戶（Service Account）

顧名思義蕊苗，用戶帳戶為人提供賬戶標(biāo)識(shí)沿后，而服務(wù)賬戶為計(jì)算機(jī)進(jìn)程和Kubernetes集群中運(yùn)行的Pod提供賬戶標(biāo)識(shí)。用戶帳戶和服務(wù)帳戶的一個(gè)區(qū)別是作用范圍朽砰；用戶帳戶對應(yīng)的是人的身份尖滚，人的身份與服務(wù)的namespace無關(guān)喉刘，所以用戶賬戶是跨namespace的；而服務(wù)帳戶對應(yīng)的是一個(gè)運(yùn)行中程序的身份漆弄，與特定namespace是相關(guān)的饱搏。

命名空間（Namespace）

命名空間為Kubernetes集群提供虛擬的隔離作用，Kubernetes集群初始有兩個(gè)命名空間置逻，分別是默認(rèn)命名空間default和系統(tǒng)命名空間kube-system，除此以外备绽，管理員可以可以創(chuàng)建新的命名空間滿足需要券坞。

RBAC訪問授權(quán)

Kubernetes在1.3版本中發(fā)布了alpha版的基于角色的訪問控制（Role-based Access Control，RBAC）的授權(quán)模式肺素。相對于基于屬性的訪問控制（Attribute-based Access Control恨锚，ABAC），RBAC主要是引入了角色（Role）和角色綁定（RoleBinding）的抽象概念倍靡。在ABAC中猴伶，Kubernetes集群中的訪問策略只能跟用戶直接關(guān)聯(lián)；而在RBAC中塌西，訪問策略可以跟某個(gè)角色關(guān)聯(lián)他挎，具體的用戶在跟一個(gè)或多個(gè)角色相關(guān)聯(lián)。顯然捡需，RBAC像其他新功能一樣办桨，每次引入新功能，都會(huì)引入新的API對象站辉，從而引入新的概念抽象呢撞，而這一新的概念抽象一定會(huì)使集群服務(wù)管理和使用更容易擴(kuò)展和重用。

總結(jié)

從Kubernetes的系統(tǒng)架構(gòu)饰剥、技術(shù)概念和設(shè)計(jì)理念殊霞，我們可以看到Kubernetes系統(tǒng)最核心的兩個(gè)設(shè)計(jì)理念：一個(gè)是容錯(cuò)性，一個(gè)是易擴(kuò)展性汰蓉。容錯(cuò)性實(shí)際是保證Kubernetes系統(tǒng)穩(wěn)定性和安全性的基礎(chǔ)绷蹲，易擴(kuò)展性是保證Kubernetes對變更友好，可以快速迭代增加新功能的基礎(chǔ)古沥。

按照分布式系統(tǒng)一致性算法Paxos發(fā)明人計(jì)算機(jī)科學(xué)家Leslie Lamport的理念瘸右，一個(gè)分布式系統(tǒng)有兩類特性：安全性Safety和活性Liveness。安全性保證系統(tǒng)的穩(wěn)定岩齿，保證系統(tǒng)不會(huì)崩潰太颤，不會(huì)出現(xiàn)業(yè)務(wù)錯(cuò)誤，不會(huì)做壞事盹沈，是嚴(yán)格約束的龄章；活性使得系統(tǒng)可以提供功能吃谣，提高性能，增加易用性做裙，讓系統(tǒng)可以在用戶“看到的時(shí)間內(nèi)”做些好事岗憋，是盡力而為的。Kubernetes系統(tǒng)的設(shè)計(jì)理念正好與Lamport安全性與活性的理念不謀而合锚贱，也正是因?yàn)镵ubernetes在引入功能和技術(shù)的時(shí)候仔戈，非常好地劃分了安全性和活性，才可以讓Kubernetes能有這么快版本迭代拧廊，快速引入像RBAC监徘、Federation和PetSet這種新功能