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和雲提供商管理等。

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)

4、服務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的生態系統，並通過整合相關的解決方案來滿足上述需求。

3

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

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兼容的群集存儲。

4

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

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

2. 核心APIs

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

4. 委託的信任API和控制器（用戶授予訪問API /控制器，以代表用戶執行操作），無論是在集群範圍內還是在更小的範圍內

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

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

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

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

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

• 使系統更加安全

• 為集群中的每一個人，啟用新的「生產質量」API

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

• 運行一個向用戶提供API的託管工作負載（spark、資料庫、etcd）

• 它們被分為三大類：

1、集群所需的（因此必須在內核附近運行，並在存在故障時導致操作權衡）

2、暴露於所有集群用戶（必須正確地租用）

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

如果管理員可以很容易地被誘騙，在擴展期間安裝新的群集級安全規則，那麼分層被破壞，並且系統是脆弱的。

英文原文：

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

本文譯者：

季向遠，

北京神舟航天軟體技術有限公司產品經理。

本文版權歸原作者所有。

拓展閱讀：

《

如何簡潔優雅地實現Kubernetes的服務暴露》

《

15分鐘快速了解如何在Kubernetes中配置健康檢查》

《

Kubernetes容器調度策略》

About Rancher Labs

Rancher Labs由矽谷雲計算泰斗、CloudStack之父梁勝創建，致力於打造創新的開源軟體，幫助企業在生產環境中運行容器與Kubernetes。旗艦產品Rancher是一個開源的企業級Kubernetes平台，是業界首個且唯一可以管理所有雲上、所有發行版、所有Kubernetes集群的平台。解決了生產環境中企業用戶可能面臨的基礎設施不同的困境，改善Kubernetes原生UI易用性不佳以及學習曲線陡峭的問題，是企業落地Kubernetes的不二之選。

Rancher在全球已有9000萬次下載和超過20000個生產節點部署，且在全球範圍內已經擁有包含迪斯尼、IBM、樂高、美國農業部、SONY、中國平安、海航集團在內數百家大中型政府及企業客戶。

Rancher北上深招聘進行時