帶你了解Kubernetes架構的設計意圖、Kubernetes系統的架構開發演進過程，以及背后的驅動原因。

1、背景
各種平臺都會遇到一個不可回避的問題，即平臺應該包含什么和不包含什么，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和云提供商管理等。
2、系統分層
就像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來調用，通過非標準的認證機制可以限制可用客戶端的數量。
1、The TokenReview API (與hook的機制一樣) 能夠啟用外部認證檢查，例如Kubelet
2、Pod身份標識通過”service accounts“提供
3、The ServiceAccount API，包括通過控制器創建的默認ServiceAccount保密字段，并通過接入許可控制器進行注入。
授權（Authorization）：第三方授權系統可以實現SubjectAccessReview API，并通過配置授權webhook進行調用。
1、SubjectAccessReview (與hook的機制一樣), LocalSubjectAccessReview, 和SelfSubjectAccessReview APIs能啟用外部的許可檢查，諸如Kubelet和其它控制器。
REST 語義、監控、持久化和一致性保證、API版本控制、違約、驗證
1、NIY：需要被解決的API缺陷：
2、混淆違約行為
3、缺少保障
4、編排支持
5、支持事件驅動的自動化
6、干凈卸載
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的管理器 ，從而能夠自動添加自宿主的組件和動態配置到集群，在運行的集群中提取出功能。
1、Add-ons應該是一個集群服務，作為集群的一部分進行管理
2、它們可以運行在kube-system命名空間，這么就不會與用戶的命名進行沖突
API server作為集群的網關。根據定義，API server必需能夠被集群外的客戶端訪問，而Node和Pod是不被集群外的客戶端訪問的?？蛻舳苏J證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執行單元，包括：
1、Pod可行性準入控制基于Pod API中的策略(資源請求、Node選擇器、node/pod affinity and anti-affinity, taints and tolerations)。API準入控制可以拒絕Pod或添加額外的調度約束，但Kubelet才是決定Pod最終被運行在哪個Node上的決定者，而不是schedulers or DaemonSets。
2、容器和存儲卷語義和生命周期
3、Pod IP地址分配(每個Pod要求一個可路由的IP地址)
4、將Pod連接至一個特定安全范圍的機制(i.e., ServiceAccount)
5、存儲卷來源：
5.1、emptyDir
5.2、hostPath
5.3、secret
5.4、configMap
5.5、downwardAPI
5.6、NIY：容器和鏡像存儲卷 (and deprecate gitRepo)
5.7、NIY：本地存儲，對于開發和生產應用清單不需要復雜的模板或獨立配置
5.8、flexVolume (應該替換內置的cloud-provider-specific存儲卷)
6、子資源：綁定、狀態、執行、日志、attach、端口轉發、代理 NIY：可用性和引導API 資源檢查點 容器鏡像和日志生命周期 The Secret API，啟用第三方加密管理 The ConfigMap API，用于組件配置和Pod引用 The Node API，Pod的宿主
1、在一些配置中，可以僅僅對集群管理員可見 Node和pod網絡，業績它們的控制(路由控制器) Node庫存、健康、和可達性(node控制器)
1、Cloud-provider-specific node庫存功能應該被分成特定提供者的控制器 pod終止垃圾收集 存儲卷控制器
1、Cloud-provider-specific attach/detach邏輯應該被分成特定提供者的控制器，需要一種方式從API中提取特定提供者的存儲卷來源。 The PersistentVolume API
1、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，應該能支持水平擴容。
1、The Deployment API，編排更新無狀態的應用，包括子資源(狀態、擴容和回滾)
2、The DaemonSet API，集群服務，包括子資源(狀態)
3、The StatefulSet API，有狀態應用，包括子資源(狀態、擴容)
4、The PodTemplate API，由DaemonSet和StatefulSet用來記錄變更歷史 終止批量應用：這些應該包括終止jobs的自動剔除(NIY)
1、The Job API (GC discussion)
2、The CronJob API 發現、負載均衡和路由
1、The Service API，包括集群IP地址分配，修復服務分配映射，通過kube-proxy或者對等的功能實現服務的負載均衡，自動化創建端點，維護和刪除。NIY：負載均衡服務是可選的，如果被支持的化，則需要通過一致性的測試。
2、The Ingress API，包括internal L7 (NIY)
3、服務DNS。DNS使用official Kubernetes schema。
應用層可以依賴： 身份提供者 (集群的身份和/或應用身份) NIY：云提供者控制器實現 Ingress controller(s) 調度器和重新調度器的替代解決方案 DNS服務替代解決方案 kube-proxy替代解決方案 工作負載控制器替代解決方案和/或輔助，特別是用于擴展發布策略
2.3 治理層：自動化和策略執行
策略執行和高層自動化。這些API和功能是運行應用的可選功能，應該挺其它的解決方案實現。
每個支持的API/功能應用作為企業操作、安全和治理場景的一部分。
需要為集群提供可能的配置和發現默認策略，至少支持如下的用例： 單一租戶/單一用戶集群 多租戶集群 生產和開發集群 Highly tenanted playground cluster 用于將計算/應用服務轉售給他人的分段集群
需要關注的內容：
1、資源使用
2、Node內部分割
3、最終用戶
4、管理員
5、服務質量（DoS）
自動化APIs和功能： 度量APIs (水平/垂直自動擴容的調度任務表) 水平Pod自動擴容API NIY：垂直Pod自動擴容API(s) 集群自動化擴容和Node供應 The PodDisruptionBudget API 動態存儲卷供應，至少有一個出廠價來源類型
1、The StorageClass API，至少有一個默認存儲卷類型的實現 動態負載均衡供應 NIY：PodPreset API NIY：service broker/catalog APIs NIY：Template和TemplateInstance APIs
策略APIs和功能：
授權：ABAC和RBAC授權策略方案
1、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的頂部
1、持久化集成和部署(CI/CD)：Kubernetes不提供從源代碼到鏡像的能力。Kubernetes 不部署源代碼和不構建應用。用戶和項目可以根據自身的需要選擇持久化集成和持久化部署工作流，Kubernetes的目標是方便CI/CD的使用，而不是命令它們如何工作。
2、應用中間件：Kubernetes不提供應用中間件作為內置的基礎設施，例如：消息隊列和SQL數據庫。然而，可以提供通用目的的機制使其能夠被容易的提供、發現和訪問。理想的情況是這些組件僅僅運行在Kubernetes上。
3、日志和監控：Kubernetes本身不提供日志聚合和綜合應用監控的能力，也沒有遙測分析和警報系統，雖然日志和監控的機制是Kubernetes集群必不可少的部分。
4、數據處理平臺：在數據處理平臺方面，Spark和Hadoop是還有名的兩個例子，但市場中還存在很多其它的系統。
5、特定應用運算符：Kubernetes支持通用類別應用的工作負載管理。
6、平臺即服務 Paas：Kubernetes為Paas提供基礎。
7、功能即服務 FaaS：與PaaS類似，但Faa侵入容器和特定語言的應用框架。
8、工作量編排： “工作流”是一個非常廣泛的和多樣化的領域，通常針對特定的用例場景（例如：數據流圖、數據驅動處理、部署流水線、事件驅動自動化、業務流程執行、iPAAS）和特定輸入和事件來源的解決方案，并且通常需要通過編寫代碼來實現。
9、配置特定領域語言：特定領域的語言不利于分層高級的API和工具，它們通常具有有限的可表達性、可測試性、熟悉性和文檔性。它們復雜的配置生成，它們傾向于在互操作性和可組合性間進行折衷。它們使依賴管理復雜化，并經常顛覆性的抽象和封裝。
10、Kompose：Kompose是一個適配器工具，它有助于從Docker Compose遷移到Kubernetes ，并提供簡單的用例。Kompose不遵循Kubernetes約定，而是基于手動維護的DSL。
11、ChatOps：也是一個適配器工具，用于聊天服務。 支撐Kubernetes
1、容器運行時：Kubernetes本身不提供容器運行時環境，但是其提供了接口，可以來插入所選擇的容器運行時。
2、鏡像倉庫：Kubernetes本身不提供容器的鏡像，可通過Harbor、Nexus和docker registry等搭建鏡像倉庫，以為集群拉取需要的容器鏡像。
3、集群狀態存儲：用于存儲集群運行狀態，例如默認使用Etcd，但也可以使用其它存儲系統。
4、網絡：與容器運行時一樣，Kubernetes提供了接入各種網絡插件的容器網絡接口（CNI）。
5、文件存儲：本地文件系統和網絡存儲
6、Node管理：Kubernetes既不提供也不采用任何綜合的機器配置、維護、管理或自愈系統。通常針對不同的公有/私有云，針對不同的操作系統，針對可變的和不可變的基礎設施。
7、云提供者：IaaS供應和管理。
8、集群創建和管理：社區已經開發了很多的工具，利潤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看作是一系列的環，每個層都賦予連續的層功能去行動。 用于存儲核心API的一個或者多個數據存儲系統(etcd) 核心APIs 高度可信賴資源的APIs(system policies) 委托的信任API和控制器（用戶授予訪問API /控制器，以代表用戶執行操作），無論是在集群范圍內還是在更小的范圍內 在不同范圍，運行不受信任/作用域API和控制器和用戶工作負載
當較低層依賴于更高的層時，它會使安全模型崩潰，并使系統變得更加復雜。管理員可以選擇這樣做以獲得操作簡單性，但這必須是有意識的選擇。一個簡單的例子是etcd：可以將數據寫入etcd的任何組件現在都在整個集群上，任何參與者（可以破壞高度信任的資源）都幾乎可以進行逐步升級。為每一層的進程，將上面的層劃分成不同的機器集（etcd-> apiservers +控制器->核心安全擴展->委托擴展- >用戶工作負載），即使有些可能在實踐中崩潰。
如果上面描述的層定義了同心圓，那么它也應該可能存在重疊或獨立的圓-例如，管理員可以選擇一個替代的秘密存儲解決方案，集群工作負載可以訪問，但是平臺并不隱含地具有訪問權限。這些圓圈的交點往往是運行工作負載的機器，并且節點必須沒有比正常功能所需的特權更多的特權。
最后，在任何層通過擴展添加新的能力，應該遵循最佳實踐來傳達該行為的影響。
當一個能力通過擴展被添加到系統時，它有什么目的？
使系統更加安全
為集群中的每一個人，啟用新的“生產質量”API
在集群的子集上自動完成一個公共任務
運行一個向用戶提供API的托管工作負載（spark、數據庫、etcd）
它們被分為三大類：
1、集群所需的（因此必須在內核附近運行，并在存在故障時導致操作權衡）
2、暴露于所有集群用戶（必須正確地租用）
3、暴露于集群用戶的子集（像傳統的“應用程序”工作負載運行）
如果管理員可以很容易地被誘騙，在擴展期間安裝新的群集級安全規則，那么分層被破壞，并且系統是脆弱的。 英文原文： https://github.com/kubernetes/community/blob/master/contributors/devel/architectural-roadmap.md 本文譯者： 季向遠，北京神舟航天軟件技術有限公司產品經理。 本文版權歸原作者所有。本文版權歸原作者所有。