Kubernetes系統架構演進過程與背後驅動的緣由

帶你瞭解Kubernetes架構的設計意圖、Kubernetes系統的架構開發演進過程，以及背後的驅動緣由。

---

一、背景

各類平臺都會遇到一個不可迴避的問題，即平臺應該包含什麼和不包含什麼，Kubernetes也同樣。Kubernetes做爲一個部署和管理容器的平臺，Kubernetes不能也不該該試圖解決用戶的全部問題。Kubernetes必須提供一些基本功能，用戶能夠在這些基本功能的基礎上運行容器化的應用程序或構建它們的擴展。本文旨在明確Kubernetes架構的設計意圖，描述Kubernetes的演進歷程和將來的開發藍圖。

本文中，咱們將描述Kubernetes系統的架構開發演進過程，以及背後的驅動緣由。對於但願擴展或者定製kubernetes系統的開發者，其應該使用此文檔做爲嚮導，以明確能夠在哪些地方，以及如何進行加強功能的實現。若是應用開發者須要開發一個大型的、可移植的和符合未來發展的kubernetes應用，也應該參考此文檔，以瞭解Kubernetes未來的演化和發展。

從邏輯上來看，kubernetes的架構分爲以下幾個層次：

核心層（Nucleus）： 提供標準的API和執行機制，包括基本的REST機制，安全、Pod、容器、網絡接口和存儲卷管理，經過接口可以對這些API和執進行擴展，核心層是必需的，它是系統最核心的一部分。

應用管理層（Application Management Layer )：提供基本的部署和路由，包括自愈能力、彈性擴容、服務發現、負載均衡和流量路由。此層即爲一般所說的服務編排，這些功能都提供了默認的實現，可是容許進行一致性的替換。

治理層（The Governance Layer）：提供高層次的自動化和策略執行，包括單一和多租戶、度量、智能擴容和供應、受權方案、網絡方案、配額方案、存儲策略表達和執行。這些都是可選的，也能夠經過其它解決方案實現。

接口層（The Interface Layer）：提供公共的類庫、工具、用戶界面和與Kubernetes API交互的系統。

生態層（The Ecosystem）：包括與Kubernetes相關的全部內容，嚴格上來講這些並非Kubernetes的組成部分。包括CI/CD、中間件、日誌、監控、數據處理、PaaS、serverless/FaaS系統、工做流、容器運行時、鏡像倉庫、Node和雲提供商管理等。

二、系統分層

就像Linux擁有內核（kernel）、核心系統類庫、和可選的用戶級工具，kubernetes也擁有功能和工具的層次。對於開發者來講，理解這些層次是很是重要的。kubernetes APIs、概念和功能都在下面的層級圖中獲得體現。

2.1 核心層：API和執行（The Nucleus: API and Execution）

核心層包含最核心的API和執行機。

這些API和功能由上游的kubernetes代碼庫實現，由最小特性集和概念集所組成，這些特徵和概念是系統上層所必需的。

這些由上游KubNeNETs代碼庫實現的API和函數包括創建系統的高階層所需的最小特徵集和概念集。這些內容被明確的地指定和記錄，而且每一個容器化的應用都會使用它們。開發人員能夠安全地假設它們是一直存在的，這些內容應該是穩定和乏味的。

2.1.1 API和集羣控制面板

Kubernetes集羣提供了相似REST API的集，經過Kubernetes API server對外進行暴露，支持持久化資源的增刪改查操做。這些API做爲控制面板的樞紐。

遵循Kubernetes API約定(路徑約定、標準元數據等)的REST API可以自動從共享API服務(認證、受權、審計日誌)中收益，通用客戶端代碼可以與它們進行交互。

做爲系統的最娣層，須要支持必要的擴展機制，以支持高層添加功能。另外，須要支持單租戶和多租戶的應用場景。核心層也須要提供足夠的彈性，以支持高層能擴展新的範圍，而不須要在安全模式方面進行妥協。

若是沒有下面這些基礎的API機和語義，Kubernetes將不可以正常工做：

認證（Authentication）: 認證機制是很是關鍵的一項工做，在Kubernetes中須要經過服務器和客戶端雙方的認證經過。API server 支持基本認證模式 (用戶命名/密碼) (注意，在未來會被放棄)， X.509客戶端證書模式，OpenID鏈接令牌模式，和不記名令牌模式。經過kubeconfig支持，客戶端可以使用上述各類認證模式。第三方認證系統能夠實現TokenReview API，並經過配置認證webhook來調用，經過非標準的認證機制能夠限制可用客戶端的數量。

一、The TokenReview API (與hook的機制同樣) 可以啓用外部認證檢查，例如Kubelet

二、Pod身份標識經過」service accounts「提供

三、The ServiceAccount API，包括經過控制器建立的默認ServiceAccount保密字段，並經過接入許可控制器進行注入。

受權（Authorization）：第三方受權系統能夠實現SubjectAccessReview API，並經過配置受權webhook進行調用。

一、SubjectAccessReview (與hook的機制同樣), LocalSubjectAccessReview, 和SelfSubjectAccessReview APIs能啓用外部的許可檢查，諸如Kubelet和其它控制器。

REST 語義、監控、持久化和一致性保證、API版本控制、違約、驗證

一、NIY：須要被解決的API缺陷：

二、混淆違約行爲

三、缺乏保障

四、編排支持

五、支持事件驅動的自動化

六、乾淨卸載

NIY： 內置的准入控制語義、同步准入控制鉤子、異步資源初始化 — 發行商系統集成商，和集羣管理員實現額外的策略和自動化

NIY：API註冊和發行、包括API聚合、註冊額外的API、發行支持的API、得到支持的操做、有效載荷和結果模式的詳細信息。

NIY：ThirdPartyResource和ThirdPartyResourceData APIs (或她們的繼承者)，支持第三方存儲和擴展API。

NIY：The Componentstatuses API的可擴展和高可用的替代，以肯定集羣是否徹底體現和操做是否正確：ExternalServiceProvider (組件註冊)

The Endpoints API，組件增持須要，API服務器端點的自我發佈，高可用和應用層目標發行

The Namespace API，用戶資源的範圍，命名空間生命週期(例如：大量刪除)

The Event API，用於對重大事件的發生進行報告，例如狀態改變和錯誤，以及事件垃圾收集

NIY：級聯刪除垃圾收集器、finalization, 和orphaning

NIY： 須要內置的add-on的管理器 ，從而可以自動添加自宿主的組件和動態配置到集羣，在運行的集羣中提取出功能。

一、Add-ons應該是一個集羣服務，做爲集羣的一部分進行管理

二、它們能夠運行在kube-system命名空間，這麼就不會與用戶的命名進行衝突

API server做爲集羣的網關。根據定義，API server必需可以被集羣外的客戶端訪問，而Node和Pod是不被集羣外的客戶端訪問的。客戶端認證API server，並使用API server做爲堡壘和代理/通道來經過/proxy和/portforward API訪問Node和Pod等Clients authenticate the API server and also use it

TBD：The CertificateSigningRequest API，可以啓用認證建立，特別是kubele證書。

理想狀況下，核心層API server江僅僅支持最小的必需的API，額外的功能經過聚合、鉤子、初始化器、和其它擴展機制來提供。注意，中心化異步控制器以名爲Controller Manager的獨立進程運行，例如垃圾收集。

API server依賴下面的外部組件：

持久化狀態存儲 (etcd，或相對應的其它系統；可能會存在多個實例)

API server能夠依賴：

身份認證提供者

The TokenReview API實現者 實現者

The SubjectAccessReview API實現者

2.1.2 執行

在Kubernetes中最重要的控制器是kubelet，它是Pod和Node API的主要實現者，沒有這些API的話，Kubernetes將僅僅只是由鍵值對存儲（後續，API機最終可能會被做爲一個獨立的項目）支持的一個增刪改查的REST應用框架。

Kubernetes默認執行獨立的應用容器和本地模式。

Kubernetes提供管理多個容器和存儲卷的Pod，Pod在Kubernetes中做爲最基本的執行單元。

Kubelet API語義包括：

The Pod API，Kubernetes執行單元，包括：

一、Pod可行性准入控制基於Pod API中的策略(資源請求、Node選擇器、node/pod affinity and anti-affinity, taints and tolerations)。API准入控制能夠拒絕Pod或添加額外的調度約束，但Kubelet纔是決定Pod最終被運行在哪一個Node上的決定者，而不是schedulers or DaemonSets。

二、容器和存儲卷語義和生命週期

三、Pod IP地址分配(每一個Pod要求一個可路由的IP地址)

四、將Pod鏈接至一個特定安全範圍的機制(i.e., ServiceAccount)

五、存儲捲來源：

5.一、emptyDir

5.二、hostPath

5.三、secret

5.四、configMap

5.五、downwardAPI

5.六、NIY：容器和鏡像存儲卷 (and deprecate gitRepo)

5.七、NIY：本地存儲，對於開發和生產應用清單不須要複雜的模板或獨立配置

5.八、flexVolume (應該替換內置的cloud-provider-specific存儲卷)

六、子資源：綁定、狀態、執行、日誌、attach、端口轉發、代理

• NIY：可用性和引導API 資源檢查點

• 容器鏡像和日誌生命週期

• The Secret API，啓用第三方加密管理

• The ConfigMap API，用於組件配置和Pod引用

• The Node API，Pod的宿主

一、在一些配置中，能夠僅僅對集羣管理員可見

• Node和pod網絡，業績它們的控制(路由控制器)

• Node庫存、健康、和可達性(node控制器)

一、Cloud-provider-specific node庫存功能應該被分紅特定提供者的控制器

• pod終止垃圾收集

• 存儲卷控制器

一、Cloud-provider-specific attach/detach邏輯應該被分紅特定提供者的控制器，須要一種方式從API中提取特定提供者的存儲捲來源。

• The PersistentVolume API

一、NIY：至少被本地存儲所支持

• The PersistentVolumeClaim API

中心化異步功能，諸如由Controller Manager執行的pod終止垃圾收集。

當前，控制過濾器和kubelet調用「雲提供商」接口來詢問來自於基礎設施層的信息，並管理基礎設施資源。然而，kubernetes正在努力將這些觸摸點（問題）提取到外部組件中，不可知足的應用程序/容器/OS級請求（例如，PODS，PersistentVolumeClaims）做爲外部「動態供應」系統的信號，這將使基礎設施可以知足這些請求，並使用基礎設施資源（例如，Node、和PersistentVolumes）在Kubernetes進行表示，這樣Kubernetes能夠將請求和基礎設施資源綁定在一塊兒。

對於kubelet，它依賴下面的可擴展組件：

• 鏡像註冊

• 容器運行時接口實現

• 容器網絡接口實現

• FlexVolume 實現（」CVI」 in the diagram）

以及可能依賴：

• NIY：第三方加密管理系統(例如：Vault)

• NIY：憑證建立和轉換控制器

2.2 應用層：部署和路由

應用管理和組合層，提供自愈、擴容、應用生命週期管理、服務發現、負載均衡和路由— 也即服務編排和service fabric。這些API和功能是全部Kubernetes分發所須要的，Kubernetes應該提供這些API的默認實現，固然可使用替代的實現方案。沒有應用層的API，大部分的容器化應用將不能運行。

Kubernetes’s API提供相似IaaS的以容器爲中心的基礎單元，以及生命週期控制器，以支持全部工做負載的編排(自愈、擴容、更新和終止)。這些應用管理、組合、發現、和路由API和功能包括：

• 默認調度，在Pod API中實現調度策略：資源請求、nodeSelector、node和pod affinity/anti-affinity、taints and tolerations. 調度可以做爲一個獨立的進度在集羣內或外運行。

• NIY：從新調度器 ，反應和主動刪除已調度的POD，以便它們能夠被替換並從新安排到其餘Node

• 持續運行應用：這些應用類型應該可以經過聲明式更新、級聯刪除、和孤兒/領養支持發佈(回滾)。除了DaemonSet，應該能支持水平擴容。

一、The Deployment API，編排更新無狀態的應用，包括子資源(狀態、擴容和回滾)

二、The DaemonSet API，集羣服務，包括子資源(狀態)

三、The StatefulSet API，有狀態應用，包括子資源(狀態、擴容)

四、The PodTemplate API，由DaemonSet和StatefulSet用來記錄變動歷史

• 終止批量應用：這些應該包括終止jobs的自動剔除(NIY)

一、The Job API (GC discussion)

二、The CronJob API

• 發現、負載均衡和路由

一、The Service API，包括集羣IP地址分配，修復服務分配映射，經過kube-proxy或者對等的功能實現服務的負載均衡，自動化建立端點，維護和刪除。NIY：負載均衡服務是可選的，若是被支持的化，則須要經過一致性的測試。

二、The Ingress API，包括internal L7 (NIY)

三、服務DNS。DNS使用official Kubernetes schema。

應用層能夠依賴：

• 身份提供者 (集羣的身份和/或應用身份)

• NIY：雲提供者控制器實現

• Ingress controller(s)

• 調度器和從新調度器的替代解決方案

• DNS服務替代解決方案

• kube-proxy替代解決方案

• 工做負載控制器替代解決方案和/或輔助，特別是用於擴展發佈策略

2.3 治理層：自動化和策略執行

策略執行和高層自動化。這些API和功能是運行應用的可選功能，應該挺其它的解決方案實現。

每一個支持的API/功能應用做爲企業操做、安全和治理場景的一部分。

須要爲集羣提供可能的配置和發現默認策略，至少支持以下的用例：

• 單一租戶/單一用戶集羣

• 多租戶集羣

• 生產和開發集羣

• Highly tenanted playground cluster

• 用於將計算/應用服務轉售給他人的分段集羣

須要關注的內容：

一、資源使用

二、Node內部分割

三、最終用戶

四、管理員

五、服務質量（DoS）

自動化APIs和功能：

• 度量APIs (水平/垂直自動擴容的調度任務表)

• 水平Pod自動擴容API

• NIY：垂直Pod自動擴容API(s)

• 集羣自動化擴容和Node供應

• The PodDisruptionBudget API

• 動態存儲卷供應，至少有一個出廠價來源類型

一、The StorageClass API，至少有一個默認存儲卷類型的實現

• 動態負載均衡供應

• NIY：PodPreset API

• NIY：service broker/catalog APIs

• NIY：Template和TemplateInstance APIs

策略APIs和功能：

受權：ABAC和RBAC受權策略方案

一、RBAC，實現下面的API：Role, RoleBinding, ClusterRole, ClusterRoleBinding

• The LimitRange API

• The ResourceQuota API

• The PodSecurityPolicy API

• The ImageReview API

• The NetworkPolicy API

管理層依賴：

• 網絡策略執行機制

• 替換、水平和垂直Pod擴容

• 集羣自動擴容和Node提供者

• 動態存儲卷提供者

• 動態負載均衡提供者

• 度量監控pipeline，或者它的替換

• 服務代理

2.4 接口層：類庫和工具

這些機制被建議用於應用程序版本的分發，用戶也能夠用其進行下載和安裝。它們包括Kubernetes官方項目開發的通用的類庫、工具、系統、界面，它們能夠用來發布。

• Kubectl — kubectl做爲不少客戶端工具中的一種，Kubernetes的目標是使Kubectl更薄，經過將經常使用的非平凡功能移動到API中。這是必要的，以便於跨Kubernetes版本的正確操做，並促進API的擴展性，以保持以API爲中心的Kubernetes生態系統模型，並簡化其它客戶端，尤爲是非GO客戶端。

• 客戶端類庫(例如：client-go, client-python)

• 集羣聯邦(API server, controllers, kubefed)

• Dashboard

• Helm

這些組件依賴：

• Kubectl擴展

• Helm擴展

2.5 生態

在有許多領域，已經爲Kubernetes定義了明確的界限。雖然，Kubernetes必須提供部署和管理容器化應用須要的通用功能。但做爲通常規則，在對Kubernete通用編排功能進行補足的功能領域，Kubernetes保持了用戶的選擇。特別是那些有本身的競爭優點的區域，特別是可以知足不一樣需求和偏好的衆多解決方案。Kubernetes能夠爲這些解決方案提供插件API，或者能夠公開由多個後端實現的通用API，或者公開此類解決方案能夠針對的API。有時，功能能夠與Kubernetes乾淨地組合在而不須要顯式接口。

此外，若是考慮成爲Kubernetes的一部分，組件就須要遵循Kubernetes設計約定。例如，主要接口使用特定域語言的系統（例如，Puppet、Open Policy Agent）與Kubenetes API的方法不兼容，能夠與Kubernetes一塊兒使用，但不會被認爲是Kubernetes的一部分。相似地，被設計用來支持多平臺的解決方案可能不會遵循Kubernetes API協議，所以也不會被認爲是Kubernetes的一部分。

• 內部的容器鏡像：Kubernetes不提供容器鏡像的內容。 若是某些內容被設計部署在容器鏡像中，則其不該該直接被考慮做爲Kubernetes的一部分。例如，基於特定語言的框架。

• 在Kubernetes的頂部

一、持久化集成和部署(CI/CD)：Kubernetes不提供從源代碼到鏡像的能力。Kubernetes 不部署源代碼和不構建應用。用戶和項目能夠根據自身的須要選擇持久化集成和持久化部署工做流，Kubernetes的目標是方便CI/CD的使用，而不是命令它們如何工做。

二、應用中間件：Kubernetes不提供應用中間件做爲內置的基礎設施，例如：消息隊列和SQL數據庫。然而，能夠提供通用目的的機制使其可以被容易的提供、發現和訪問。理想的狀況是這些組件僅僅運行在Kubernetes上。

三、日誌和監控：Kubernetes自己不提供日誌聚合和綜合應用監控的能力，也沒有遙測分析和警報系統，雖然日誌和監控的機制是Kubernetes集羣必不可少的部分。

四、數據處理平臺：在數據處理平臺方面，Spark和Hadoop是還有名的兩個例子，但市場中還存在不少其它的系統。

五、特定應用運算符：Kubernetes支持通用類別應用的工做負載管理。

六、平臺即服務 Paas：Kubernetes爲Paas提供基礎。

七、功能即服務 FaaS：與PaaS相似，但Faa侵入容器和特定語言的應用框架。

八、工做量編排： 「工做流」是一個很是普遍的和多樣化的領域，一般針對特定的用例場景（例如：數據流圖、數據驅動處理、部署流水線、事件驅動自動化、業務流程執行、iPAAS）和特定輸入和事件來源的解決方案，而且一般須要經過編寫代碼來實現。

九、配置特定領域語言：特定領域的語言不利於分層高級的API和工具，它們一般具備有限的可表達性、可測試性、熟悉性和文檔性。它們複雜的配置生成，它們傾向於在互操做性和可組合性間進行折衷。它們使依賴管理複雜化，並常常顛覆性的抽象和封裝。

十、Kompose：Kompose是一個適配器工具，它有助於從Docker Compose遷移到Kubernetes ，並提供簡單的用例。Kompose不遵循Kubernetes約定，而是基於手動維護的DSL。

十一、ChatOps：也是一個適配器工具，用於聊天服務。

• 支撐Kubernetes

一、容器運行時：Kubernetes自己不提供容器運行時環境，可是其提供了接口，能夠來插入所選擇的容器運行時。

二、鏡像倉庫：Kubernetes自己不提供容器的鏡像，可經過Harbor、Nexus和docker registry等搭建鏡像倉庫，覺得集羣拉取須要的容器鏡像。

三、集羣狀態存儲：用於存儲集羣運行狀態，例如默認使用Etcd，但也可使用其它存儲系統。

四、網絡：與容器運行時同樣，Kubernetes提供了接入各類網絡插件的容器網絡接口（CNI）。

五、文件存儲：本地文件系統和網絡存儲

六、Node管理：Kubernetes既不提供也不採用任何綜合的機器配置、維護、管理或自愈系統。一般針對不一樣的公有/私有云，針對不一樣的操做系統，針對可變的和不可變的基礎設施。

七、雲提供者：IaaS供應和管理。

八、集羣建立和管理：社區已經開發了不少的工具，利潤minikube、kubeadm、bootkube、kube-aws、kops、kargo, kubernetes-anywhere等待。 從工具的多樣性能夠看出，集羣部署和管理（例如，升級）沒有一成不變的解決方案。也就是說，常見的構建塊（例如，安全的Kubelet註冊）和方法（特別是自託管）將減小此類工具中所需的自定義編排的數量。

後續，但願經過創建Kubernetes的生態系統，並經過整合相關的解決方案來知足上述需求。

矩陣管理

選項、可配置的默認、擴展、插件、附加組件、特定於提供者的功能、版本管理、特徵發現和依賴性管理。

Kubernetes不只僅是一個開源的工具箱，並且是一個典型集羣或者服務的運行環境。 Kubernetes但願大多數用戶和用例可以使用上游版本，這意味着Kubernetes須要足夠的可擴展性，而不須要經過重建來處理各類場景。

雖然在可擴展性方面的差距是代碼分支的主要驅動力，而上游集羣生命週期管理解決方案中的差距是當前Kubernetes分發的主要驅動因素，可選特徵的存在（例如，alpha API、提供者特定的API）、可配置性、插件化和可擴展性使概念不可避免。

然而，爲了使用戶有可能在Kubernetes上部署和管理他們的應用程序，爲了使開發人員可以在Kubernetes集羣上構建構建Kubernetes擴展，他們必須可以對Kubernetes集羣或分發提供一個假設。在基本假設失效的狀況下，須要找到一種方法來發現可用的功能，並表達功能需求（依賴性）以供使用。

集羣組件，包括add-ons，應該經過組件註冊 API進行註冊和經過/componentstatuses進行發現。

啓用內置API、聚合API和註冊的第三方資源，應該能夠經過發現和OpenAPI（Savigj.JSON）端點來發現。如上所述，LoadBalancer類型服務的雲服務提供商應該肯定負載均衡器API是否存在。

相似於StorageClass，擴展和它們的選項應該經過FoeClass資源進行註冊。可是，使用參數描述、類型（例如，整數與字符串）、用於驗證的約束（例如，ranger或regexp）和默認值，從擴展API中引用fooClassName。這些API應該配置/暴露相關的特徵的存在，例如動態存儲卷供應（由非空的storageclass.provisioner字段指示），以及標識負責的控制器。須要至少爲調度器類、ingress控制器類、Flex存儲卷類和計算資源類（例如GPU、其餘加速器）添加這樣的API。

假設咱們將現有的網絡存儲卷轉換爲flex存儲卷，這種方法將會覆蓋存儲捲來源。在未來，API應該只提供通用目的的抽象，即便與LoadBalancer服務同樣，抽象並不須要在全部的環境中都實現（即，API不須要迎合最低公共特性）。

NIY：須要爲註冊和發現開發下面的機制：

• 准入控制插件和hooks(包括內置的APIs)

• 身份認證插件

• 受權插件和hooks

• 初始化和終結器

• 調度器擴展

• Node標籤和集羣拓撲

NIY：單個API和細粒度特徵的激活/失活能夠經過如下機制解決：

• 全部組件的配置正在從命令行標誌轉換爲版本化配置。

• 打算將大部分配置數據存儲在配置映射(ConfigMaps)中，以便於動態從新配置、漸進發布和內省性。

• 全部/多個組件共同的配置應該被分解到它本身的配置對象中。這應該包括特徵網關機制。

• 應該爲語義意義上的設置添加API，例如，在無響應節點上刪除Pod以前須要等待的默認時間長度。

NIY：版本管理操做的問題，取決於多個組件的升級（包括在HA集羣中的相同組件的副本），應該經過如下方式來解決：

爲全部新的特性建立flag網關

老是在它們出現的第一個小版本中，默認禁用這些特性，

提供啓用特性的配置補丁；

在接下來的小版本中默認啓用這些特性

NIY：咱們還須要一個機制來警告過期的節點，和/或潛在防止Master升級（除了補丁發佈），直到/除非Node已經升級。

NIY：字段級版本管理將有助於大量激活新的和/或alpha API字段的解決方案，防止不良寫入過期的客戶端對新字段的阻塞，以及非alpha API的演進，而不須要成熟的API定義的擴散。

Kubernetes API server忽略不支持的資源字段和查詢參數，但不忽略未知的/未註冊的API（注意禁用未實現的/不活動的API）。這有助於跨多個版本的集羣重用配置，但每每會帶來意外。Kubctl支持使用服務器的Wagger/OpenAPI規範進行可選驗證。這樣的可選驗證，應該由服務器（NYY）提供。此外，爲方便用戶，共享資源清單應該指定Kubernetes版本最小的要求，這可能會被kubectl和其餘客戶端驗證。

服務目錄機制（NIY）應該可以斷言應用級服務的存在，例如S3兼容的羣集存儲。

與安全相關的系統分層

爲了正確地保護Kubernetes集羣並使其可以安全擴展，一些基本概念須要由系統的組件進行定義和約定。最好從安全的角度把Kubernetes看做是一系列的環，每一個層都賦予連續的層功能去行動。

1. 用於存儲核心API的一個或者多個數據存儲系統(etcd)

2. 核心APIs

3. 高度可信賴資源的APIs(system policies)

4. 委託的信任API和控制器（用戶授予訪問API /控制器，以表明用戶執行操做），不管是在集羣範圍內仍是在更小的範圍內

5. 在不一樣範圍，運行不受信任/做用域API和控制器和用戶工做負載

當較低層依賴於更高的層時，它會使安全模型崩潰，並使系統變得更加複雜。管理員能夠選擇這樣作以得到操做簡單性，但這必須是有意識的選擇。一個簡單的例子是etcd：能夠將數據寫入etcd的任何組件如今都在整個集羣上，任何參與者（能夠破壞高度信任的資源）都幾乎能夠進行逐步升級。爲每一層的進程，將上面的層劃分紅不一樣的機器集（etcd-> apiservers +控制器->核心安全擴展->委託擴展- >用戶工做負載），即便有些可能在實踐中崩潰。

若是上面描述的層定義了同心圓，那麼它也應該可能存在重疊或獨立的圓-例如，管理員能夠選擇一個替代的祕密存儲解決方案，集羣工做負載能夠訪問，可是平臺並不隱含地具備訪問權限。這些圓圈的交點每每是運行工做負載的機器，而且節點必須沒有比正常功能所需的特權更多的特權。

最後，在任何層經過擴展添加新的能力，應該遵循最佳實踐來傳達該行爲的影響。

當一個能力經過擴展被添加到系統時，它有什麼目的？

使系統更加安全

爲集羣中的每個人，啓用新的「生產質量」API

在集羣的子集上自動完成一個公共任務

運行一個向用戶提供API的託管工做負載（spark、數據庫、etcd）

它們被分爲三大類：

一、集羣所需的（所以必須在內核附近運行，並在存在故障時致使操做權衡）

二、暴露於全部集羣用戶（必須正確地租用）

三、暴露於集羣用戶的子集（像傳統的「應用程序」工做負載運行）

若是管理員能夠很容易地被誘騙，在擴展期間安裝新的羣集級安全規則，那麼分層被破壞，而且系統是脆弱的。

英文原文：

https://github.com/kubernetes/community/blob/master/contributors/devel/architectural-roadmap.md

本文譯者：

季向遠，北京神舟航天軟件技術有限公司產品經理。

本文版權歸原做者全部。本文版權歸原做者全部。