共計 6816 個字符，預計需要花費 18 分鐘才能閱讀完成。

這篇文章將為大家詳細講解有關 kubernetes 設計理念是什么，丸趣 TV 小編覺得挺實用的，因此分享給大家做個參考，希望大家閱讀完這篇文章后可以有所收獲。

一、kubernetes 設計理念與分布式系統

API 設計原則：

對于云計算系統，系統 API 實際上處于系統設計的統領地位，K8S 集群系統每支持一項新功能，引入一項新技術，一定會新引入對應的 API 對象，支持對該功能的管理操作。

1. 所有 API 應該是聲明式的。聲明式操作相對于命令式操作，對于重復操作的效果更加穩定，這對于容易出現數據丟失或重復的分布式環境而言很重要。另外聲明式操作更容易被用戶使用，對用戶隱藏細節，同時保留系統未來持續優化的可能性。

2.API 對象是彼此互補而且可組合的。提倡 API 對象盡量實現面向對象的設計要求，達到“高內聚，低耦合”，對業務模塊有個合適的分解。本質上 K8S 這種分布式系統管理平臺，也是一種業務系統，只不過它的業務就是調度和管理容器服務。

3. 高層 API 以操作意圖為設計基礎。高層設計一定是從業務出發，而不是技術的角度。針對 K8S 的高層 API 設計，一定是以 K8S 的業務為基礎出發，也就是以系統調度管理容器的操作意圖為設計基礎。

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

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

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

7.API 對象狀態不能依賴于網絡連接。在分布式環境下，網絡連接斷開是經常發生的事情，要保證 API 對象狀態能應對網絡的不穩定性，API 對象的狀態就不能依賴于網絡連接狀態。

8. 盡量避免讓操作機制依賴于全局狀態，因為在分布式系統中要保證全局狀態的同步是比較困難的。

控制機制設計原則：

1. 控制邏輯應該只依賴于當前狀態。

為了保證分布式系統的穩定可靠，對于經常出現局部錯誤的分布式系統，如果控制邏輯只依賴當前狀態，那么就非常容易將一個暫時出現故障的系統恢復到正常狀態，因為你只要將該系統重置到某個穩定狀態，就可以自信的知道系統的所有控制邏輯會開始按照正常方式運行。

2. 假設任何錯誤的可能，并做容錯處理。

在一個分布式系統中出現局部和臨時錯誤是大概率事件。錯誤可能來自于物理系統故障，外部系統故障也可能來自于系統自身的代碼錯誤，依靠自己實現的代碼不會出錯來保證系統穩定其實也是難以實現的，因此要設計對任何可能錯誤的容錯處理。

3. 盡量避免復雜狀態機，控制邏輯不要依賴于無法監控的內部狀態。

因為分布式系統各個子系統都是不能嚴格通過程序內部保持同步的，所以如果兩個子系統的控制邏輯如果互相有影響，那么子系統就一定要能互相訪問到影響控制邏輯的狀態，否則，就等同于系統里存在不確定的控制邏輯。

4. 假設任何操作都可能被任何操作對象拒絕，甚至被錯誤解析。

由于分布式系統的復雜性以及各子系統的相對獨立性，不同子系統經常來自不同的開發團隊，所以不能奢望任何操作被另一個子系統以正確的方式處理，要保證出現錯誤的時候，操作級別的錯誤不會影響到系統穩定性。

5. 每個模塊都可以在出錯后自動恢復。

由于分布式系統中無法保證系統各個模塊是始終連接的，因此每個模塊要有自我修復的能力，保證不會因為連接不到其他模塊而自我崩潰。

6. 每個模塊都可以在必要時優雅地降級服務。

即要求在設計實現模塊時劃分清楚基本功能和高級功能，保證基本功能不會依賴高級功能，這樣同時就保證了不會因為高級功能出現故障而導致整個模塊崩潰。根據這種理念實現的系統，也更容易快速地增加新的高級功能，以為不必擔心引入高級功能影響原有的基本功能。

二、kubernetes 核心技術概念和 API 對象

API 對象是 K8s 集群中的管理操作單元。K8s 集群系統每支持一項新功能，引入一項新技術，一定會新引入對應的 API 對象，支持對該功能的管理操作。例如副本集 Replica Set 對應的 API 對象是 RS。

每個 API 對象都有 3 大類屬性：元數據 metadata、規范 spec 和狀態 status。元數據是用來標識 API 對象的，每個對象都至少有 3 個元數據：namespace，name 和 uid；除此以外還有各種各樣的標簽 labels 用來標識和匹配不同的對象，例如用戶可以用標簽 env 來標識區分不同的服務部署環境，分別用 env=dev、env=testing、env=production 來標識開發、測試、生產的不同服務。規范描述了用戶期望 K8s 集群中的分布式系統達到的理想狀態（Desired State），例如用戶可以通過復制控制器 Replication Controller 設置期望的 Pod 副本數為 3；status 描述了系統實際當前達到的狀態（Status），例如系統當前實際的 Pod 副本數為 2；那么復制控制器當前的程序邏輯就是自動啟動新的 Pod，爭取達到副本數為 3。

K8s 中所有的配置都是通過 API 對象的 spec 去設置的，也就是用戶通過配置系統的理想狀態來改變系統，這是 k8s 重要設計理念之一，即所有的操作都是聲明式（Declarative）的而不是命令式（Imperative）的。聲明式操作在分布式系統中的好處是穩定，不怕丟操作或運行多次，例如設置副本數為 3 的操作運行多次也還是一個結果，而給副本數加 1 的操作就不是聲明式的，運行多次結果就錯了。

1.Pod

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

Pod 是 K8s 集群中所有業務類型的基礎，可以看作運行在 K8s 集群中的小機器人，不同類型的業務就需要不同類型的小機器人去執行。目前 K8s 中的業務主要可以分為長期伺服型（long-running）、批處理型（batch）、節點后臺支撐型（node-daemon）和有狀態應用型（stateful application）；分別對應的小機器人控制器為 Deployment、Job、DaemonSet 和 PetSet，本文后面會一一介紹。

2. 復制控制器（Replication Controller，RC）

RC 是 K8s 集群中最早的保證 Pod 高可用的 API 對象。通過監控運行中的 Pod 來保證集群中運行指定數目的 Pod 副本。指定的數目可以是多個也可以是 1 個；少于指定數目，RC 就會啟動運行新的 Pod 副本；多于指定數目，RC 就會殺死多余的 Pod 副本。即使在指定數目為 1 的情況下，通過 RC 運行 Pod 也比直接運行 Pod 更明智，因為 RC 也可以發揮它高可用的能力，保證永遠有 1 個 Pod 在運行。RC 是 K8s 較早期的技術概念，只適用于長期伺服型的業務類型，比如控制小機器人提供高可用的 Web 服務。

3. 副本集（Replica Set，RS）

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

4. 部署 (Deployment)

部署表示用戶對 K8s 集群的一次更新操作。部署是一個比 RS 應用模式更廣的 API 對象，可以是創建一個新的服務，更新一個新的服務，也可以是滾動升級一個服務。滾動升級一個服務，實際是創建一個新的 RS，然后逐漸將新 RS 中副本數增加到理想狀態，將舊 RS 中的副本數減小到 0 的復合操作；這樣一個復合操作用一個 RS 是不太好描述的，所以用一個更通用的 Deployment 來描述。以 K8s 的發展方向，未來對所有長期伺服型的的業務的管理，都會通過 Deployment 來管理。

5. 服務（Service）

RC、RS 和 Deployment 只是保證了支撐服務的微服務 Pod 的數量，但是沒有解決如何訪問這些服務的問題。一個 Pod 只是一個運行服務的實例，隨時可能在一個節點上停止，在另一個節點以一個新的 IP 啟動一個新的 Pod，因此不能以確定的 IP 和端口號提供服務。要穩定地提供服務需要服務發現和負載均衡能力。服務發現完成的工作，是針對客戶端訪問的服務，找到對應的的后端服務實例。

在 K8S 集群中，客戶端需要訪問的服務就是 Service 對象。每個 Service 會對應一個集群內部有效的虛擬 IP，  集群內部通過虛擬 IP 訪問一個服務。在 K8S 集群中微服務的負載均衡是通過 kube-proxy 實現的。kube-proxy 是 K8S 集群內部的負載均衡器。它是一個分布式代理服務器，在 K8S 的每個節點上都有一個。這一特性體現了它的伸縮性優勢，需要訪問服務的節點越多，提供負載均衡能力的 kube-proxy 就越多，高可用節點也隨之增多。

6. 任務（Job）

Job 是 K8S 用來控制批處理型任務的 API 對象。批處理業務與長期伺服 long-running 業務的主要區別是批處理業務的運行有頭有尾，而長期伺服業務在用戶不停止的情況下永遠運行。Job 管理的 Pod 根據用戶的設置把任務成功完成就自動退出了。成功完成的標志根據不同的 spec.completions 策略而不同：單 Pod 型任務有一個 Pod 成功就標志完成；定數成功型任務保證有 N 個任務全部成功；工作隊列型任務根據應用確認的全局成功而標志成功。

7. 后臺支撐服務集（DaemonSet）

后臺支撐型服務的核心關注點在 K8S 集群中的節點（物理機或虛擬機），要保證每個節點上都有一個此類 Pod 運行。節點可能是所有集群節點也可能是通過 nodeSelector 選定的一些特定節點。典型的后臺支撐服務包括存儲、日志、監控等，在每個節點上支持 K8S 集群運行的服務。

8. 有狀態服務集（PetSet）

RC 和 RS 主要是控制提供無狀態服務的, 其所控制的 Pod 的名字是隨機設置的，一個 Pod 出故障了就被丟棄，在另一個地方重啟一個新 Pod，  名字變了、名字和啟動在哪兒都不重要，重要的只是 Pod 總數; 而 PetSet 是用來控制有狀態服務，PetSet 中的每個 Pod 的名字都是事先確定的，不能更改。PetSet 中 Pod 的名字是用來關聯與該 Pod 的對應狀態。

9. 集群聯邦（Federation）

K8s 在 1.3 版本里發布了 beta 版的 Federation 功能。在云計算環境中，服務的作用距離范圍從近到遠一般可以有：同主機（Host，Node）、跨主機同可用區（Available Zone）、跨可用區同地區（Region）、跨地區同服務商（Cloud Service Provider）、跨云平臺。K8s 的設計定位是單一集群在同一個地域內，因為同一個地區的網絡性能才能滿足 K8s 的調度和計算存儲連接要求。而聯合集群服務就是為提供跨 Region 跨服務商 K8s 集群服務而設計的。

每個 K8s Federation 有自己的分布式存儲、API Server 和 Controller Manager。用戶可以通過 Federation 的 API Server 注冊該 Federation 的成員 K8s Cluster。當用戶通過 Federation 的 API Server 創建、更改 API 對象時，Federation API Server 會在自己所有注冊的子 K8s Cluster 都創建一份對應的 API 對象。在提供業務請求服務時，K8s Federation 會先在自己的各個子 Cluster 之間做負載均衡，而對于發送到某個具體 K8s Cluster 的業務請求，會依照這個 K8s Cluster 獨立提供服務時一樣的調度模式去做 K8s Cluster 內部的負載均衡。而 Cluster 之間的負載均衡是通過域名服務的負載均衡來實現的。

所有的設計都盡量不影響 K8s Cluster 現有的工作機制，這樣對于每個子 K8s 集群來說，并不需要更外層的有一個 K8s Federation，也就是意味著所有現有的 K8s 代碼和機制不需要因為 Federation 功能有任何變化。

10. 存儲卷（Volume）

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

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

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

PV 和 PVC 使得 K8s 集群具備了存儲的邏輯抽象能力，使得在配置 Pod 的邏輯里可以忽略對實際后臺存儲技術的配置，而把這項配置的工作交給 PV 的配置者，即集群的管理者。存儲的 PV 和 PVC 的這種關系，跟計算的 Node 和 Pod 的關系是非常類似的；PV 和 Node 是資源的提供者，根據集群的基礎設施變化而變化，由 K8s 集群管理員配置；而 PVC 和 Pod 是資源的使用者，根據業務服務的需求變化而變化，有 K8s 集群的使用者即服務的管理員來配置。

12. 節點（Node）

K8S 集群中的計算能力由 Node 提供，最初 Node 稱為服務節點 Minion,  后來改名為 node。K8s 集群中的 Node 相當于 Mesos 集群中的 slave 節點，是所有 Pod 運行所在的工作主機，可以是物理機也可以是虛擬機，工作主機的統一特征是上面要運行 kubelet 管理節點上運行的容器。

13. 密鑰對象（Secret）

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

14. 用戶帳戶（User Account）和服務帳戶（Service Account）

用戶帳戶為人提供賬戶標識，而服務賬戶為計算機進程和 K8s 集群中運行的 Pod 提供賬戶標識。用戶帳戶和服務帳戶的一個區別是作用范圍；用戶帳戶對應的是人的身份，人的身份與服務的 namespace 無關，所以用戶賬戶是跨 namespace 的；而服務帳戶對應的是一個運行中程序的身份，與特定 namespace 是相關的。

15. 名字空間（Namespace）

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

16.RBAC 訪問授權（Role-based Access Control, RBAC）

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

17.Conclusion 總結

從 K8S 的系統架構、技術概念和設計理念上可以看到兩個最核心的設計理念：容錯性和易擴展性。容錯性是保證 K8S 系統穩定性和安全生的基礎，易擴展性是保證 K8S 對用戶更加友好，是快速迭代增加新功能的基礎。

關于“kubernetes 設計理念是什么”這篇文章就分享到這里了，希望以上內容可以對大家有一定的幫助，使各位可以學到更多知識，如果覺得文章不錯，請把它分享出去讓更多的人看到。