kubernetes設(shè)計(jì)理念是什么

這篇文章將為大家詳細(xì)講解有關(guān)kubernetes設(shè)計(jì)理念是什么，小編覺得挺實(shí)用的，因此分享給大家做個(gè)參考，希望大家閱讀完這篇文章后可以有所收獲。

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

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

對(duì)于云計(jì)算系統(tǒng)，系統(tǒng)API實(shí)際上處于系統(tǒng)設(shè)計(jì)的統(tǒng)領(lǐng)地位，K8S集群系統(tǒng)每支持一項(xiàng)新功能，引入一項(xiàng)新技術(shù)，一定會(huì)新引入對(duì)應(yīng)的API對(duì)象，支持對(duì)該功能的管理操作。

1.所有API應(yīng)該是聲明式的。聲明式操作相對(duì)于命令式操作，對(duì)于重復(fù)操作的效果更加穩(wěn)定，這對(duì)于容易出現(xiàn)數(shù)據(jù)丟失或重復(fù)的分布式環(huán)境而言很重要。另外聲明式操作更容易被用戶使用，對(duì)用戶隱藏細(xì)節(jié)，同時(shí)保留系統(tǒng)未來持續(xù)優(yōu)化的可能性。

2.API對(duì)象是彼此互補(bǔ)而且可組合的。提倡API對(duì)象盡量實(shí)現(xiàn)面向?qū)ο蟮脑O(shè)計(jì)要求，達(dá)到“高內(nèi)聚，低耦合”，對(duì)業(yè)務(wù)模塊有個(gè)合適的分解。本質(zhì)上K8S這種分布式系統(tǒng)管理平臺(tái)，也是一種業(yè)務(wù)系統(tǒng)，只不過它的業(yè)務(wù)就是調(diào)度和管理容器服務(wù)。

3.高層API以操作意圖為設(shè)計(jì)基礎(chǔ)。高層設(shè)計(jì)一定是從業(yè)務(wù)出發(fā)，而不是技術(shù)的角度。針對(duì)K8S的高層API設(shè)計(jì)，一定是以K8S的業(yè)務(wù)為基礎(chǔ)出發(fā)，也就是以系統(tǒng)調(diào)度管理容器的操作意圖為設(shè)計(jì)基礎(chǔ)。

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

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

6.API操作復(fù)雜度與對(duì)象數(shù)量成正比。這條主要是從系統(tǒng)性能角度考慮，要保證系統(tǒng)隨著系統(tǒng)規(guī)模的擴(kuò)大，性能不會(huì)迅速變慢到無法使用，則最低限定就是API的操作復(fù)雜度不能超過O（N）, N是對(duì)象數(shù)量，否則系統(tǒng)就不具備水平伸縮了。

7.API對(duì)象狀態(tài)不能依賴于網(wǎng)絡(luò)連接。在分布式環(huán)境下，網(wǎng)絡(luò)連接斷開是經(jīng)常發(fā)生的事情，要保證API對(duì)象狀態(tài)能應(yīng)對(duì)網(wǎng)絡(luò)的不穩(wěn)定性，API對(duì)象的狀態(tài)就不能依賴于網(wǎng)絡(luò)連接狀態(tài)。

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

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

1.控制邏輯應(yīng)該只依賴于當(dāng)前狀態(tài)。

為了保證分布式系統(tǒng)的穩(wěn)定可靠，對(duì)于經(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)行。

2.假設(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ì)對(duì)任何可能錯(cuò)誤的容錯(cuò)處理。

3.盡量避免復(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)里存在不確定的控制邏輯。

4.假設(shè)任何操作都可能被任何操作對(duì)象拒絕，甚至被錯(cuò)誤解析。

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

5.每個(gè)模塊都可以在出錯(cuò)后自動(dòng)恢復(fù)。

由于分布式系統(tǒng)中無法保證系統(tǒng)各個(gè)模塊是始終連接的，因此每個(gè)模塊要有自我修復(fù)的能力，保證不會(huì)因?yàn)檫B接不到其他模塊而自我崩潰。

6.每個(gè)模塊都可以在必要時(shí)優(yōu)雅地降級(jí)服務(wù)。

即要求在設(shè)計(jì)實(shí)現(xiàn)模塊時(shí)劃分清楚基本功能和高級(jí)功能，保證基本功能不會(huì)依賴高級(jí)功能，這樣同時(shí)就保證了不會(huì)因?yàn)楦呒?jí)功能出現(xiàn)故障而導(dǎo)致整個(gè)模塊崩潰。根據(jù)這種理念實(shí)現(xiàn)的系統(tǒng)，也更容易快速地增加新的高級(jí)功能，以為不必?fù)?dān)心引入高級(jí)功能影響原有的基本功能。

二、kubernetes核心技術(shù)概念和API對(duì)象

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

每個(gè)API對(duì)象都有3大類屬性：元數(shù)據(jù)metadata、規(guī)范spec和狀態(tài)status。元數(shù)據(jù)是用來標(biāo)識(shí)API對(duì)象的，每個(gè)對(duì)象都至少有3個(gè)元數(shù)據(jù)：namespace，name和uid；除此以外還有各種各樣的標(biāo)簽labels用來標(biāo)識(shí)和匹配不同的對(duì)象，例如用戶可以用標(biāo)簽env來標(biāo)識(shí)區(qū)分不同的服務(wù)部署環(huán)境，分別用env=dev、env=testing、env=production來標(biāo)識(shí)開發(fā)、測(cè)試、生產(chǎn)的不同服務(wù)。規(guī)范描述了用戶期望K8s集群中的分布式系統(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，爭(zhēng)取達(dá)到副本數(shù)為3。

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

1.Pod

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

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

2.復(fù)制控制器（Replication Controller，RC）

RC是K8s集群中最早的保證Pod高可用的API對(duì)象。通過監(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是K8s較早期的技術(shù)概念，只適用于長(zhǎng)期伺服型的業(yè)務(wù)類型，比如控制小機(jī)器人提供高可用的Web服務(wù)。

3.副本集（Replica Set，RS）

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

4.部署(Deployment)

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

5.服務(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)完成的工作，是針對(duì)客戶端訪問的服務(wù)，找到對(duì)應(yīng)的的后端服務(wù)實(shí)例。

在K8S集群中，客戶端需要訪問的服務(wù)就是Service對(duì)象。每個(gè)Service會(huì)對(duì)應(yīng)一個(gè)集群內(nèi)部有效的虛擬IP， 集群內(nèi)部通過虛擬IP訪問一個(gè)服務(wù)。在K8S集群中微服務(wù)的負(fù)載均衡是通過kube-proxy實(shí)現(xiàn)的。kube-proxy是K8S集群內(nèi)部的負(fù)載均衡器。它是一個(gè)分布式代理服務(wù)器，在K8S的每個(gè)節(jié)點(diǎn)上都有一個(gè)。這一特性體現(xiàn)了它的伸縮性優(yōu)勢(shì)，需要訪問服務(wù)的節(jié)點(diǎn)越多，提供負(fù)載均衡能力的kube-proxy就越多，高可用節(jié)點(diǎn)也隨之增多。

6.任務(wù)（Job）

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

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

后臺(tái)支撐型服務(wù)的核心關(guān)注點(diǎn)在K8S集群中的節(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)上支持K8S集群運(yùn)行的服務(wù)。

8.有狀態(tài)服務(wù)集（PetSet）

RC和RS主要是控制提供無狀態(tài)服務(wù)的,其所控制的Pod的名字是隨機(jī)設(shè)置的，一個(gè)Pod出故障了就被丟棄，在另一個(gè)地方重啟一個(gè)新Pod， 名字變了、名字和啟動(dòng)在哪兒都不重要，重要的只是Pod總數(shù);而PetSet是用來控制有狀態(tài)服務(wù)，PetSet中的每個(gè)Pod的名字都是事先確定的，不能更改。PetSet中Pod的名字是用來關(guān)聯(lián)與該P(yáng)od的對(duì)應(yīng)狀態(tài)。

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

K8s在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)。K8s的設(shè)計(jì)定位是單一集群在同一個(gè)地域內(nèi)，因?yàn)橥粋€(gè)地區(qū)的網(wǎng)絡(luò)性能才能滿足K8s的調(diào)度和計(jì)算存儲(chǔ)連接要求。而聯(lián)合集群服務(wù)就是為提供跨Region跨服務(wù)商K8s集群服務(wù)而設(shè)計(jì)的。

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

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

10.存儲(chǔ)卷（Volume）

K8s集群中的存儲(chǔ)卷跟Docker的存儲(chǔ)卷有些類似，只不過Docker的存儲(chǔ)卷作用范圍為一個(gè)容器，而K8s的存儲(chǔ)卷的生命周期和作用范圍是一個(gè)Pod。每個(gè)Pod中聲明的存儲(chǔ)卷由Pod中所有的容器共享。K8S支持非常多的存儲(chǔ)卷類型。支持多種公有云平臺(tái)的存儲(chǔ)，包括AWS， Google， Azure云;支持多種分布式存儲(chǔ)包括GlusterFS和Ceph;也支持較容易使用的主機(jī)本地目錄hostPath和NFS.

K8s還支持使用Persistent Volume Claim即PVC這種邏輯存儲(chǔ)，使用這種存儲(chǔ)，使得存儲(chǔ)的使用者可以忽略后臺(tái)的實(shí)際存儲(chǔ)技術(shù)（例如AWS，Google或GlusterFS和Ceph），而將有關(guān)存儲(chǔ)實(shí)際技術(shù)的配置交給存儲(chǔ)管理員通過Persistent Volume來配置。

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

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

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

K8S集群中的計(jì)算能力由Node提供，最初Node稱為服務(wù)節(jié)點(diǎn)Minion, 后來改名為node。K8s集群中的Node相當(dāng)于Mesos集群中的slave節(jié)點(diǎn)，是所有Pod運(yùn)行所在的工作主機(jī)，可以是物理機(jī)也可以是虛擬機(jī)，工作主機(jī)的統(tǒng)一特征是上面要運(yùn)行kubelet管理節(jié)點(diǎn)上運(yùn)行的容器。

13.密鑰對(duì)象（Secret）

Secret是用來保存和傳遞密碼、密鑰、認(rèn)證憑證這些敏感信息對(duì)象的。Secret可以避免敏感信息明文寫在配置文件里。

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

用戶帳戶為人提供賬戶標(biāo)識(shí)，而服務(wù)賬戶為計(jì)算機(jī)進(jìn)程和K8s集群中運(yùn)行的Pod提供賬戶標(biāo)識(shí)。用戶帳戶和服務(wù)帳戶的一個(gè)區(qū)別是作用范圍；用戶帳戶對(duì)應(yīng)的是人的身份，人的身份與服務(wù)的namespace無關(guān)，所以用戶賬戶是跨namespace的；而服務(wù)帳戶對(duì)應(yīng)的是一個(gè)運(yùn)行中程序的身份，與特定namespace是相關(guān)的。

15.名字空間（Namespace）

namespace為k8s集群提供虛擬隔離作用，K8S集群初始有兩個(gè)namespace, default和kube-system, 此外管理員可以創(chuàng)建新namespace以滿足需求。

16.RBAC訪問授權(quán)（Role-based Access Control, RBAC）

k8s在1.3版本中發(fā)布了基于角色的訪問控制的授權(quán)模式。相對(duì)于基于屬性的訪問控制（Attribute-based Access Control, ABAC）, RBAC主要引入了角色Role和角色綁定RoleBinding的概念。

17.Conclusion總結(jié)

從K8S的系統(tǒng)架構(gòu)、技術(shù)概念和設(shè)計(jì)理念上可以看到兩個(gè)最核心的設(shè)計(jì)理念：容錯(cuò)性和易擴(kuò)展性。容錯(cuò)性是保證K8S系統(tǒng)穩(wěn)定性和安全生的基礎(chǔ)，易擴(kuò)展性是保證K8S對(duì)用戶更加友好，是快速迭代增加新功能的基礎(chǔ)。

關(guān)于“kubernetes設(shè)計(jì)理念是什么”這篇文章就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，使各位可以學(xué)到更多知識(shí)，如果覺得文章不錯(cuò)，請(qǐng)把它分享出去讓更多的人看到。