Kubernetes系統架構演進過程與背後驅動的原因
帶你瞭解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是不被叢集外的客戶端訪問的。客戶端認證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、暴露於叢集使用者的子集（像傳統的“應用程式”工作負載執行）
如果管理員可以很容易地被誘騙，在擴充套件期間安裝新的群集級安全規則，那麼分層被破壞，並且系統是脆弱的。
英文原文：
ofollow,noindex" target="_blank">https://github.com/kubernetes/ ... ap.md
本文譯者：
季向遠，北京神舟航天軟體技術有限公司產品經理。
本文版權歸原作者所有。本文版權歸原作者所有。