帶你了解Kubernetes架構(gòu)的設(shè)計(jì)意圖、Kubernetes系統(tǒng)的架構(gòu)開發(fā)演進(jìn)過程，以及背后的驅(qū)動(dòng)原因。

1、背景

各種平臺都會(huì)遇到一個(gè)不可回避的問題，即平臺應(yīng)該包含什么和不包含什么，Kubernetes也一樣。Kubernetes作為一個(gè)部署和管理容器的平臺，Kubernetes不能也不應(yīng)該試圖解決用戶的所有問題。Kubernetes必須提供一些基本功能，用戶可以在這些基本功能的基礎(chǔ)上運(yùn)行容器化的應(yīng)用程序或構(gòu)建它們的擴(kuò)展。本文旨在明確Kubernetes架構(gòu)的設(shè)計(jì)意圖，描述Kubernetes的演進(jìn)歷程和未來的開發(fā)藍(lán)圖。

本文中，我們將描述Kubernetes系統(tǒng)的架構(gòu)開發(fā)演進(jìn)過程，以及背后的驅(qū)動(dòng)原因。對于希望擴(kuò)展或者定制kubernetes系統(tǒng)的開發(fā)者，其應(yīng)該使用此文檔作為向?qū)В悦鞔_可以在哪些地方，以及如何進(jìn)行增強(qiáng)功能的實(shí)現(xiàn)。如果應(yīng)用開發(fā)者需要開發(fā)一個(gè)大型的、可移植的和符合將來發(fā)展的kubernetes應(yīng)用，也應(yīng)該參考此文檔，以了解Kubernetes將來的演化和發(fā)展。

從邏輯上來看，kubernetes的架構(gòu)分為如下幾個(gè)層次：

• 核心層(Nucleus)： 提供標(biāo)準(zhǔn)的API和執(zhí)行機(jī)制，包括基本的REST機(jī)制，安全、Pod、容器、網(wǎng)絡(luò)接口和存儲(chǔ)卷管理，通過接口能夠?qū)@些API和執(zhí)進(jìn)行擴(kuò)展，核心層是必需的，它是系統(tǒng)最核心的一部分。
• 應(yīng)用管理層(Application Management Layer )：提供基本的部署和路由，包括自愈能力、彈性擴(kuò)容、服務(wù)發(fā)現(xiàn)、負(fù)載均衡和流量路由。此層即為通常所說的服務(wù)編排，這些功能都提供了默認(rèn)的實(shí)現(xiàn)，但是允許進(jìn)行一致性的替換。
• 治理層(The Governance Layer)：提供高層次的自動(dòng)化和策略執(zhí)行，包括單一和多租戶、度量、智能擴(kuò)容和供應(yīng)、授權(quán)方案、網(wǎng)絡(luò)方案、配額方案、存儲(chǔ)策略表達(dá)和執(zhí)行。這些都是可選的，也可以通過其它解決方案實(shí)現(xiàn)。
• 接口層(The Interface Layer)：提供公共的類庫、工具、用戶界面和與Kubernetes API交互的系統(tǒng)。
• 生態(tài)層(The Ecosystem)：包括與Kubernetes相關(guān)的所有內(nèi)容，嚴(yán)格上來說這些并不是Kubernetes的組成部分。包括CI/CD、中間件、日志、監(jiān)控、數(shù)據(jù)處理、PaaS、serverless/FaaS系統(tǒng)、工作流、容器運(yùn)行時(shí)、鏡像倉庫、Node和云提供商管理等。

2、系統(tǒng)分層

就像Linux擁有內(nèi)核(kernel)、核心系統(tǒng)類庫、和可選的用戶級工具，kubernetes也擁有功能和工具的層次。對于開發(fā)者來說，理解這些層次是非常重要的。kubernetes APIs、概念和功能都在下面的層級圖中得到體現(xiàn)。

2.1 核心層：API和執(zhí)行(The Nucleus: API and Execution)

核心層包含最核心的API和執(zhí)行機(jī)。

這些API和功能由上游的kubernetes代碼庫實(shí)現(xiàn)，由最小特性集和概念集所組成，這些特征和概念是系統(tǒng)上層所必需的。

這些由上游KubNeNETs代碼庫實(shí)現(xiàn)的API和函數(shù)包括建立系統(tǒng)的高階層所需的最小特征集和概念集。這些內(nèi)容被明確的地指定和記錄，并且每個(gè)容器化的應(yīng)用都會(huì)使用它們。開發(fā)人員可以安全地假設(shè)它們是一直存在的，這些內(nèi)容應(yīng)該是穩(wěn)定和乏味的。

2.1.1 API和集群控制面板

Kubernetes集群提供了類似REST API的集，通過Kubernetes API server對外進(jìn)行暴露，支持持久化資源的增刪改查操作。這些API作為控制面板的樞紐。

遵循Kubernetes API約定(路徑約定、標(biāo)準(zhǔn)元數(shù)據(jù)等)的REST API能夠自動(dòng)從共享API服務(wù)(認(rèn)證、授權(quán)、審計(jì)日志)中收益，通用客戶端代碼能夠與它們進(jìn)行交互。

作為系統(tǒng)的最娣層，需要支持必要的擴(kuò)展機(jī)制，以支持高層添加功能。另外，需要支持單租戶和多租戶的應(yīng)用場景。核心層也需要提供足夠的彈性，以支持高層能擴(kuò)展新的范圍，而不需要在安全模式方面進(jìn)行妥協(xié)。

如果沒有下面這些基礎(chǔ)的API機(jī)和語義，Kubernetes將不能夠正常工作：

認(rèn)證(Authentication): 認(rèn)證機(jī)制是非常關(guān)鍵的一項(xiàng)工作，在Kubernetes中需要通過服務(wù)器和客戶端雙方的認(rèn)證通過。API server 支持基本認(rèn)證模式 (用戶命名/密碼) (注意，在將來會(huì)被放棄)， X.509客戶端證書模式，OpenID連接令牌模式，和不記名令牌模式。通過kubeconfig支持，客戶端能夠使用上述各種認(rèn)證模式。第三方認(rèn)證系統(tǒng)可以實(shí)現(xiàn)TokenReview API，并通過配置認(rèn)證webhook來調(diào)用，通過非標(biāo)準(zhǔn)的認(rèn)證機(jī)制可以限制可用客戶端的數(shù)量。

• The TokenReview API (與hook的機(jī)制一樣) 能夠啟用外部認(rèn)證檢查，例如Kubelet
• Pod身份標(biāo)識通過”service accounts“提供
• The ServiceAccount API，包括通過控制器創(chuàng)建的默認(rèn)ServiceAccount保密字段，并通過接入許可控制器進(jìn)行注入。

授權(quán)(Authorization)：第三方授權(quán)系統(tǒng)可以實(shí)現(xiàn)SubjectAccessReview API，并通過配置授權(quán)webhook進(jìn)行調(diào)用。

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

• REST 語義、監(jiān)控、持久化和一致性保證、API版本控制、違約、驗(yàn)證
• NIY：需要被解決的API缺陷：
• 混淆違約行為
• 缺少保障
• 編排支持
• 支持事件驅(qū)動(dòng)的自動(dòng)化
• 干凈卸載

NIY： 內(nèi)置的準(zhǔn)入控制語義、同步準(zhǔn)入控制鉤子、異步資源初始化 — 發(fā)行商系統(tǒng)集成商，和集群管理員實(shí)現(xiàn)額外的策略和自動(dòng)化

NIY：API注冊和發(fā)行、包括API聚合、注冊額外的API、發(fā)行支持的API、獲得支持的操作、有效載荷和結(jié)果模式的詳細(xì)信息。

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

NIY：The Componentstatuses API的可擴(kuò)展和高可用的替代，以確定集群是否完全體現(xiàn)和操作是否正確：ExternalServiceProvider (組件注冊)

The Endpoints API，組件增持需要，API服務(wù)器端點(diǎn)的自我發(fā)布，高可用和應(yīng)用層目標(biāo)發(fā)行

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

The Event API，用于對重大事件的發(fā)生進(jìn)行報(bào)告，例如狀態(tài)改變和錯(cuò)誤，以及事件垃圾收集

NIY：級聯(lián)刪除垃圾收集器、finalization, 和orphaning

NIY： 需要內(nèi)置的add-on的管理器 ，從而能夠自動(dòng)添加自宿主的組件和動(dòng)態(tài)配置到集群，在運(yùn)行的集群中提取出功能。

• Add-ons應(yīng)該是一個(gè)集群服務(wù)，作為集群的一部分進(jìn)行管理
• 它們可以運(yùn)行在kube-system命名空間，這么就不會(huì)與用戶的命名進(jìn)行沖突

API server作為集群的網(wǎng)關(guān)。根據(jù)定義，API server必需能夠被集群外的客戶端訪問，而Node和Pod是不被集群外的客戶端訪問的。客戶端認(rèn)證API server，并使用API server作為堡壘和代理/通道來通過/proxy和/portforward API訪問Node和Pod等Clients authenticate the API server and also use it

TBD：The CertificateSigningRequest API，能夠啟用認(rèn)證創(chuàng)建，特別是kubele證書。

理想情況下，核心層API server江僅僅支持最小的必需的API，額外的功能通過聚合、鉤子、初始化器、和其它擴(kuò)展機(jī)制來提供。注意，中心化異步控制器以名為Controller Manager的獨(dú)立進(jìn)程運(yùn)行，例如垃圾收集。

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

• 持久化狀態(tài)存儲(chǔ) (etcd，或相對應(yīng)的其它系統(tǒng);可能會(huì)存在多個(gè)實(shí)例)
• API server可以依賴：
• 身份認(rèn)證提供者
• The TokenReview API實(shí)現(xiàn)者 實(shí)現(xiàn)者
• The SubjectAccessReview API實(shí)現(xiàn)者

2.1.2 執(zhí)行

在Kubernetes中最重要的控制器是kubelet，它是Pod和Node API的主要實(shí)現(xiàn)者，沒有這些API的話，Kubernetes將僅僅只是由鍵值對存儲(chǔ)(后續(xù)，API機(jī)最終可能會(huì)被作為一個(gè)獨(dú)立的項(xiàng)目)支持的一個(gè)增刪改查的REST應(yīng)用框架。

Kubernetes默認(rèn)執(zhí)行獨(dú)立的應(yīng)用容器和本地模式。

Kubernetes提供管理多個(gè)容器和存儲(chǔ)卷的Pod，Pod在Kubernetes中作為最基本的執(zhí)行單元。

Kubelet API語義包括：

The Pod API，Kubernetes執(zhí)行單元，包括：

1）、Pod可行性準(zhǔn)入控制基于Pod API中的策略(資源請求、Node選擇器、node/pod affinity and anti-affinity, taints and tolerations)。API準(zhǔn)入控制可以拒絕Pod或添加額外的調(diào)度約束，但Kubelet才是決定Pod最終被運(yùn)行在哪個(gè)Node上的決定者，而不是schedulers or DaemonSets。

2）、容器和存儲(chǔ)卷語義和生命周期

3）、Pod IP地址分配(每個(gè)Pod要求一個(gè)可路由的IP地址)

4）、將Pod連接至一個(gè)特定安全范圍的機(jī)制(i.e., ServiceAccount)

5）、存儲(chǔ)卷來源：

• emptyDir
• hostPath
• secret
• configMap
• downwardAPI
• NIY：容器和鏡像存儲(chǔ)卷 (and deprecate gitRepo)
• NIY：本地存儲(chǔ)，對于開發(fā)和生產(chǎn)應(yīng)用清單不需要復(fù)雜的模板或獨(dú)立配置
• flexVolume (應(yīng)該替換內(nèi)置的cloud-provider-specific存儲(chǔ)卷)

6）、子資源：綁定、狀態(tài)、執(zhí)行、日志、attach、端口轉(zhuǎn)發(fā)、代理

• NIY：可用性和引導(dǎo)API 資源檢查點(diǎn)

容器鏡像和日志生命周期

• The Secret API，啟用第三方加密管理
• The ConfigMap API，用于組件配置和Pod引用
• The Node API，Pod的宿主

a、在一些配置中，可以僅僅對集群管理員可見

• Node和pod網(wǎng)絡(luò)，業(yè)績它們的控制(路由控制器)
• Node庫存、健康、和可達(dá)性(node控制器)

b、Cloud-provider-specific node庫存功能應(yīng)該被分成特定提供者的控制器

• pod終止垃圾收集
• 存儲(chǔ)卷控制器

c、Cloud-provider-specific attach/detach邏輯應(yīng)該被分成特定提供者的控制器，需要一種方式從API中提取特定提供者的存儲(chǔ)卷來源。

• The PersistentVolume API

d、NIY：至少被本地存儲(chǔ)所支持

• The PersistentVolumeClaim API

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

當(dāng)前，控制過濾器和kubelet調(diào)用“云提供商”接口來詢問來自于基礎(chǔ)設(shè)施層的信息，并管理基礎(chǔ)設(shè)施資源。然而，kubernetes正在努力將這些觸摸點(diǎn)(問題)提取到外部組件中，不可滿足的應(yīng)用程序/容器/OS級請求(例如，PODS，PersistentVolumeClaims)作為外部“動(dòng)態(tài)供應(yīng)”系統(tǒng)的信號，這將使基礎(chǔ)設(shè)施能夠滿足這些請求，并使用基礎(chǔ)設(shè)施資源(例如，Node、和PersistentVolumes)在Kubernetes進(jìn)行表示，這樣Kubernetes可以將請求和基礎(chǔ)設(shè)施資源綁定在一起。

對于kubelet，它依賴下面的可擴(kuò)展組件：

• 鏡像注冊
• 容器運(yùn)行時(shí)接口實(shí)現(xiàn)
• 容器網(wǎng)絡(luò)接口實(shí)現(xiàn)
• FlexVolume 實(shí)現(xiàn)(”CVI” in the diagram)

以及可能依賴：

• NIY：第三方加密管理系統(tǒng)(例如：Vault)
• NIY：憑證創(chuàng)建和轉(zhuǎn)換控制器

2.2 應(yīng)用層：部署和路由

應(yīng)用管理和組合層，提供自愈、擴(kuò)容、應(yīng)用生命周期管理、服務(wù)發(fā)現(xiàn)、負(fù)載均衡和路由— 也即服務(wù)編排和service fabric。這些API和功能是所有Kubernetes分發(fā)所需要的，Kubernetes應(yīng)該提供這些API的默認(rèn)實(shí)現(xiàn)，當(dāng)然可以使用替代的實(shí)現(xiàn)方案。沒有應(yīng)用層的API，大部分的容器化應(yīng)用將不能運(yùn)行。

Kubernetes’s API提供類似IaaS的以容器為中心的基礎(chǔ)單元，以及生命周期控制器，以支持所有工作負(fù)載的編排(自愈、擴(kuò)容、更新和終止)。這些應(yīng)用管理、組合、發(fā)現(xiàn)、和路由API和功能包括：

• 默認(rèn)調(diào)度，在Pod API中實(shí)現(xiàn)調(diào)度策略：資源請求、nodeSelector、node和pod affinity/anti-affinity、taints and tolerations. 調(diào)度能夠作為一個(gè)獨(dú)立的進(jìn)度在集群內(nèi)或外運(yùn)行。

NIY：重新調(diào)度器 ，反應(yīng)和主動(dòng)刪除已調(diào)度的POD，以便它們可以被替換并重新安排到其他Node

持續(xù)運(yùn)行應(yīng)用：這些應(yīng)用類型應(yīng)該能夠通過聲明式更新、級聯(lián)刪除、和孤兒/領(lǐng)養(yǎng)支持發(fā)布(回滾)。除了DaemonSet，應(yīng)該能支持水平擴(kuò)容。

1. The Deployment API，編排更新無狀態(tài)的應(yīng)用，包括子資源(狀態(tài)、擴(kuò)容和回滾)
2. The DaemonSet API，集群服務(wù)，包括子資源(狀態(tài))
3. The StatefulSet API，有狀態(tài)應(yīng)用，包括子資源(狀態(tài)、擴(kuò)容)
4. The PodTemplate API，由DaemonSet和StatefulSet用來記錄變更歷史

終止批量應(yīng)用：這些應(yīng)該包括終止jobs的自動(dòng)剔除(NIY)

• The Job API (GC discussion)
• The CronJob API

發(fā)現(xiàn)、負(fù)載均衡和路由

1. The Service API，包括集群IP地址分配，修復(fù)服務(wù)分配映射，通過kube-proxy或者對等的功能實(shí)現(xiàn)服務(wù)的負(fù)載均衡，自動(dòng)化創(chuàng)建端點(diǎn)，維護(hù)和刪除。NIY：負(fù)載均衡服務(wù)是可選的，如果被支持的化，則需要通過一致性的測試。
2. The Ingress API，包括internal L7 (NIY)
3. 服務(wù)DNS。DNS使用official Kubernetes schema。

應(yīng)用層可以依賴：

• 身份提供者 (集群的身份和/或應(yīng)用身份)
• NIY：云提供者控制器實(shí)現(xiàn)
• Ingress controller(s)
• 調(diào)度器和重新調(diào)度器的替代解決方案
• DNS服務(wù)替代解決方案
• kube-proxy替代解決方案
• 工作負(fù)載控制器替代解決方案和/或輔助，特別是用于擴(kuò)展發(fā)布策略

2.3 治理層：自動(dòng)化和策略執(zhí)行

策略執(zhí)行和高層自動(dòng)化。這些API和功能是運(yùn)行應(yīng)用的可選功能，應(yīng)該挺其它的解決方案實(shí)現(xiàn)。

每個(gè)支持的API/功能應(yīng)用作為企業(yè)操作、安全和治理場景的一部分。

需要為集群提供可能的配置和發(fā)現(xiàn)默認(rèn)策略，至少支持如下的用例：

• 單一租戶/單一用戶集群
• 多租戶集群
• 生產(chǎn)和開發(fā)集群
• Highly tenanted playground cluster
• 用于將計(jì)算/應(yīng)用服務(wù)轉(zhuǎn)售給他人的分段集群

需要關(guān)注的內(nèi)容：

1. 資源使用
2. Node內(nèi)部分割
3. 最終用戶
4. 管理員
5. 服務(wù)質(zhì)量(DoS)

自動(dòng)化APIs和功能：

• 度量APIs (水平/垂直自動(dòng)擴(kuò)容的調(diào)度任務(wù)表)
• 水平Pod自動(dòng)擴(kuò)容API
• NIY：垂直Pod自動(dòng)擴(kuò)容API(s)
• 集群自動(dòng)化擴(kuò)容和Node供應(yīng)
• The PodDisruptionBudget API
• 動(dòng)態(tài)存儲(chǔ)卷供應(yīng)，至少有一個(gè)出廠價(jià)來源類型

1、The StorageClass API，至少有一個(gè)默認(rèn)存儲(chǔ)卷類型的實(shí)現(xiàn)

• 動(dòng)態(tài)負(fù)載均衡供應(yīng)
• NIY：PodPreset API
• NIY：service broker/catalog APIs
• NIY：Template和TemplateInstance APIs

策略APIs和功能：

授權(quán)：ABAC和RBAC授權(quán)策略方案

1、RBAC，實(shí)現(xiàn)下面的API：Role, RoleBinding, ClusterRole, ClusterRoleBinding

• The LimitRange API
• The ResourceQuota API
• The PodSecurityPolicy API
• The ImageReview API
• The NetworkPolicy API

管理層依賴：

• 網(wǎng)絡(luò)策略執(zhí)行機(jī)制
• 替換、水平和垂直Pod擴(kuò)容
• 集群自動(dòng)擴(kuò)容和Node提供者
• 動(dòng)態(tài)存儲(chǔ)卷提供者
• 動(dòng)態(tài)負(fù)載均衡提供者
• 度量監(jiān)控pipeline，或者它的替換
• 服務(wù)代理

2.4 接口層：類庫和工具

這些機(jī)制被建議用于應(yīng)用程序版本的分發(fā)，用戶也可以用其進(jìn)行下載和安裝。它們包括Kubernetes官方項(xiàng)目開發(fā)的通用的類庫、工具、系統(tǒng)、界面，它們可以用來發(fā)布。

1. Kubectl — kubectl作為很多客戶端工具中的一種，Kubernetes的目標(biāo)是使Kubectl更薄，通過將常用的非平凡功能移動(dòng)到API中。這是必要的，以便于跨Kubernetes版本的正確操作，并促進(jìn)API的擴(kuò)展性，以保持以API為中心的Kubernetes生態(tài)系統(tǒng)模型，并簡化其它客戶端，尤其是非GO客戶端。

• 客戶端類庫(例如：client-go, client-python)
• 集群聯(lián)邦(API server, controllers, kubefed)
• Dashboard
• Helm

這些組件依賴：

• Kubectl擴(kuò)展
• Helm擴(kuò)展

2.5 生態(tài)

在有許多領(lǐng)域，已經(jīng)為Kubernetes定義了明確的界限。雖然，Kubernetes必須提供部署和管理容器化應(yīng)用需要的通用功能。但作為一般規(guī)則，在對Kubernete通用編排功能進(jìn)行補(bǔ)足的功能領(lǐng)域，Kubernetes保持了用戶的選擇。特別是那些有自己的競爭優(yōu)勢的區(qū)域，特別是能夠滿足不同需求和偏好的眾多解決方案。Kubernetes可以為這些解決方案提供插件API，或者可以公開由多個(gè)后端實(shí)現(xiàn)的通用API，或者公開此類解決方案可以針對的API。有時(shí)，功能可以與Kubernetes干凈地組合在而不需要顯式接口。

此外，如果考慮成為Kubernetes的一部分，組件就需要遵循Kubernetes設(shè)計(jì)約定。例如，主要接口使用特定域語言的系統(tǒng)(例如，Puppet、Open Policy Agent)與Kubenetes API的方法不兼容，可以與Kubernetes一起使用，但不會(huì)被認(rèn)為是Kubernetes的一部分。類似地，被設(shè)計(jì)用來支持多平臺的解決方案可能不會(huì)遵循Kubernetes API協(xié)議，因此也不會(huì)被認(rèn)為是Kubernetes的一部分。

內(nèi)部的容器鏡像：Kubernetes不提供容器鏡像的內(nèi)容。 如果某些內(nèi)容被設(shè)計(jì)部署在容器鏡像中，則其不應(yīng)該直接被考慮作為Kubernetes的一部分。例如，基于特定語言的框架。

在Kubernetes的頂部

1、持久化集成和部署(CI/CD)：Kubernetes不提供從源代碼到鏡像的能力。Kubernetes 不部署源代碼和不構(gòu)建應(yīng)用。用戶和項(xiàng)目可以根據(jù)自身的需要選擇持久化集成和持久化部署工作流，Kubernetes的目標(biāo)是方便CI/CD的使用，而不是命令它們?nèi)绾喂ぷ鳌?/p>

2、應(yīng)用中間件：Kubernetes不提供應(yīng)用中間件作為內(nèi)置的基礎(chǔ)設(shè)施，例如：消息隊(duì)列和SQL數(shù)據(jù)庫。然而，可以提供通用目的的機(jī)制使其能夠被容易的提供、發(fā)現(xiàn)和訪問。理想的情況是這些組件僅僅運(yùn)行在Kubernetes上。

3、日志和監(jiān)控：Kubernetes本身不提供日志聚合和綜合應(yīng)用監(jiān)控的能力，也沒有遙測分析和警報(bào)系統(tǒng)，雖然日志和監(jiān)控的機(jī)制是Kubernetes集群必不可少的部分。

4、數(shù)據(jù)處理平臺：在數(shù)據(jù)處理平臺方面，Spark和Hadoop是還有名的兩個(gè)例子，但市場中還存在很多其它的系統(tǒng)。

5、特定應(yīng)用運(yùn)算符：Kubernetes支持通用類別應(yīng)用的工作負(fù)載管理。

6、平臺即服務(wù) Paas：Kubernetes為Paas提供基礎(chǔ)。

7、功能即服務(wù) FaaS：與PaaS類似，但Faa侵入容器和特定語言的應(yīng)用框架。

8、工作量編排： “工作流”是一個(gè)非常廣泛的和多樣化的領(lǐng)域，通常針對特定的用例場景(例如：數(shù)據(jù)流圖、數(shù)據(jù)驅(qū)動(dòng)處理、部署流水線、事件驅(qū)動(dòng)自動(dòng)化、業(yè)務(wù)流程執(zhí)行、iPAAS)和特定輸入和事件來源的解決方案，并且通常需要通過編寫代碼來實(shí)現(xiàn)。

9、配置特定領(lǐng)域語言：特定領(lǐng)域的語言不利于分層高級的API和工具，它們通常具有有限的可表達(dá)性、可測試性、熟悉性和文檔性。它們復(fù)雜的配置生成，它們傾向于在互操作性和可組合性間進(jìn)行折衷。它們使依賴管理復(fù)雜化，并經(jīng)常顛覆性的抽象和封裝。

10、Kompose：Kompose是一個(gè)適配器工具，它有助于從Docker Compose遷移到Kubernetes ，并提供簡單的用例。Kompose不遵循Kubernetes約定，而是基于手動(dòng)維護(hù)的DSL。

11、ChatOps：也是一個(gè)適配器工具，用于聊天服務(wù)。

支撐Kubernetes

1、容器運(yùn)行時(shí)：Kubernetes本身不提供容器運(yùn)行時(shí)環(huán)境，但是其提供了接口，可以來插入所選擇的容器運(yùn)行時(shí)。

2、鏡像倉庫：Kubernetes本身不提供容器的鏡像，可通過Harbor、Nexus和docker registry等搭建鏡像倉庫，以為集群拉取需要的容器鏡像。

3、集群狀態(tài)存儲(chǔ)：用于存儲(chǔ)集群運(yùn)行狀態(tài)，例如默認(rèn)使用Etcd，但也可以使用其它存儲(chǔ)系統(tǒng)。

4、網(wǎng)絡(luò)：與容器運(yùn)行時(shí)一樣，Kubernetes提供了接入各種網(wǎng)絡(luò)插件的容器網(wǎng)絡(luò)接口(CNI)。

5、文件存儲(chǔ)：本地文件系統(tǒng)和網(wǎng)絡(luò)存儲(chǔ)

6、Node管理：Kubernetes既不提供也不采用任何綜合的機(jī)器配置、維護(hù)、管理或自愈系統(tǒng)。通常針對不同的公有/私有云，針對不同的操作系統(tǒng)，針對可變的和不可變的基礎(chǔ)設(shè)施。

7、云提供者：IaaS供應(yīng)和管理。

8、集群創(chuàng)建和管理：社區(qū)已經(jīng)開發(fā)了很多的工具，利潤minikube、kubeadm、bootkube、kube-aws、kops、kargo, kubernetes-anywhere等待。 從工具的多樣性可以看出，集群部署和管理(例如，升級)沒有一成不變的解決方案。也就是說，常見的構(gòu)建塊(例如，安全的Kubelet注冊)和方法(特別是自托管)將減少此類工具中所需的自定義編排的數(shù)量。

后續(xù)，希望通過建立Kubernetes的生態(tài)系統(tǒng)，并通過整合相關(guān)的解決方案來滿足上述需求。

矩陣管理

選項(xiàng)、可配置的默認(rèn)、擴(kuò)展、插件、附加組件、特定于提供者的功能、版本管理、特征發(fā)現(xiàn)和依賴性管理。

Kubernetes不僅僅是一個(gè)開源的工具箱，而且是一個(gè)典型集群或者服務(wù)的運(yùn)行環(huán)境。 Kubernetes希望大多數(shù)用戶和用例能夠使用上游版本，這意味著Kubernetes需要足夠的可擴(kuò)展性，而不需要通過重建來處理各種場景。

雖然在可擴(kuò)展性方面的差距是代碼分支的主要驅(qū)動(dòng)力，而上游集群生命周期管理解決方案中的差距是當(dāng)前Kubernetes分發(fā)的主要驅(qū)動(dòng)因素，可選特征的存在(例如，alpha API、提供者特定的API)、可配置性、插件化和可擴(kuò)展性使概念不可避免。

然而，為了使用戶有可能在Kubernetes上部署和管理他們的應(yīng)用程序，為了使開發(fā)人員能夠在Kubernetes集群上構(gòu)建構(gòu)建Kubernetes擴(kuò)展，他們必須能夠?qū)ubernetes集群或分發(fā)提供一個(gè)假設(shè)。在基本假設(shè)失效的情況下，需要找到一種方法來發(fā)現(xiàn)可用的功能，并表達(dá)功能需求(依賴性)以供使用。

集群組件，包括add-ons，應(yīng)該通過組件注冊 API進(jìn)行注冊和通過/componentstatuses進(jìn)行發(fā)現(xiàn)。

啟用內(nèi)置API、聚合API和注冊的第三方資源，應(yīng)該可以通過發(fā)現(xiàn)和OpenAPI(Savigj.JSON)端點(diǎn)來發(fā)現(xiàn)。如上所述，LoadBalancer類型服務(wù)的云服務(wù)提供商應(yīng)該確定負(fù)載均衡器API是否存在。

類似于StorageClass，擴(kuò)展和它們的選項(xiàng)應(yīng)該通過FoeClass資源進(jìn)行注冊。但是，使用參數(shù)描述、類型(例如，整數(shù)與字符串)、用于驗(yàn)證的約束(例如，ranger或regexp)和默認(rèn)值，從擴(kuò)展API中引用fooClassName。這些API應(yīng)該配置/暴露相關(guān)的特征的存在，例如動(dòng)態(tài)存儲(chǔ)卷供應(yīng)(由非空的storageclass.provisioner字段指示)，以及標(biāo)識負(fù)責(zé)的控制器。需要至少為調(diào)度器類、ingress控制器類、Flex存儲(chǔ)卷類和計(jì)算資源類(例如GPU、其他加速器)添加這樣的API。

假設(shè)我們將現(xiàn)有的網(wǎng)絡(luò)存儲(chǔ)卷轉(zhuǎn)換為flex存儲(chǔ)卷，這種方法將會(huì)覆蓋存儲(chǔ)卷來源。在將來，API應(yīng)該只提供通用目的的抽象，即使與LoadBalancer服務(wù)一樣，抽象并不需要在所有的環(huán)境中都實(shí)現(xiàn)(即，API不需要迎合***公共特性)。

NIY：需要為注冊和發(fā)現(xiàn)開發(fā)下面的機(jī)制：

• 準(zhǔn)入控制插件和hooks(包括內(nèi)置的APIs)
• 身份認(rèn)證插件
• 授權(quán)插件和hooks
• 初始化和終結(jié)器
• 調(diào)度器擴(kuò)展
• Node標(biāo)簽和集群拓?fù)?/li>

NIY：單個(gè)API和細(xì)粒度特征的激活/失活可以通過以下機(jī)制解決：

• 所有組件的配置正在從命令行標(biāo)志轉(zhuǎn)換為版本化配置。
• 打算將大部分配置數(shù)據(jù)存儲(chǔ)在配置映射(ConfigMaps)中，以便于動(dòng)態(tài)重新配置、漸進(jìn)發(fā)布和內(nèi)省性。
• 所有/多個(gè)組件共同的配置應(yīng)該被分解到它自己的配置對象中。這應(yīng)該包括特征網(wǎng)關(guān)機(jī)制。
• 應(yīng)該為語義意義上的設(shè)置添加API，例如，在無響應(yīng)節(jié)點(diǎn)上刪除Pod之前需要等待的默認(rèn)時(shí)間長度。

NIY：版本管理操作的問題，取決于多個(gè)組件的升級(包括在HA集群中的相同組件的副本)，應(yīng)該通過以下方式來解決：

• 為所有新的特性創(chuàng)建flag網(wǎng)關(guān)
• 總是在它們出現(xiàn)的***個(gè)小版本中，默認(rèn)禁用這些特性，
• 提供啟用特性的配置補(bǔ)丁;

在接下來的小版本中默認(rèn)啟用這些特性

• NIY：我們還需要一個(gè)機(jī)制來警告過時(shí)的節(jié)點(diǎn)，和/或潛在防止Master升級(除了補(bǔ)丁發(fā)布)，直到/除非Node已經(jīng)升級。
• NIY：字段級版本管理將有助于大量激活新的和/或alpha API字段的解決方案，防止不良寫入過時(shí)的客戶端對新字段的阻塞，以及非alpha API的演進(jìn)，而不需要成熟的API定義的擴(kuò)散。

Kubernetes API server忽略不支持的資源字段和查詢參數(shù)，但不忽略未知的/未注冊的API(注意禁用未實(shí)現(xiàn)的/不活動(dòng)的API)。這有助于跨多個(gè)版本的集群重用配置，但往往會(huì)帶來意外。Kubctl支持使用服務(wù)器的Wagger/OpenAPI規(guī)范進(jìn)行可選驗(yàn)證。這樣的可選驗(yàn)證，應(yīng)該由服務(wù)器(NYY)提供。此外，為方便用戶，共享資源清單應(yīng)該指定Kubernetes版本最小的要求，這可能會(huì)被kubectl和其他客戶端驗(yàn)證。

服務(wù)目錄機(jī)制(NIY)應(yīng)該能夠斷言應(yīng)用級服務(wù)的存在，例如S3兼容的群集存儲(chǔ)。

與安全相關(guān)的系統(tǒng)分層

為了正確地保護(hù)Kubernetes集群并使其能夠安全擴(kuò)展，一些基本概念需要由系統(tǒng)的組件進(jìn)行定義和約定。***從安全的角度把Kubernetes看作是一系列的環(huán)，每個(gè)層都賦予連續(xù)的層功能去行動(dòng)。

• 用于存儲(chǔ)核心API的一個(gè)或者多個(gè)數(shù)據(jù)存儲(chǔ)系統(tǒng)(etcd)
• 核心APIs
• 高度可信賴資源的APIs(system policies)
• 委托的信任API和控制器(用戶授予訪問API /控制器，以代表用戶執(zhí)行操作)，無論是在集群范圍內(nèi)還是在更小的范圍內(nèi)
• 在不同范圍，運(yùn)行不受信任/作用域API和控制器和用戶工作負(fù)載

當(dāng)較低層依賴于更高的層時(shí)，它會(huì)使安全模型崩潰，并使系統(tǒng)變得更加復(fù)雜。管理員可以選擇這樣做以獲得操作簡單性，但這必須是有意識的選擇。一個(gè)簡單的例子是etcd：可以將數(shù)據(jù)寫入etcd的任何組件現(xiàn)在都在整個(gè)集群上，任何參與者(可以破壞高度信任的資源)都幾乎可以進(jìn)行逐步升級。為每一層的進(jìn)程，將上面的層劃分成不同的機(jī)器集(etcd-> apiservers +控制器->核心安全擴(kuò)展->委托擴(kuò)展- >用戶工作負(fù)載)，即使有些可能在實(shí)踐中崩潰。

如果上面描述的層定義了同心圓，那么它也應(yīng)該可能存在重疊或獨(dú)立的圓-例如，管理員可以選擇一個(gè)替代的秘密存儲(chǔ)解決方案，集群工作負(fù)載可以訪問，但是平臺并不隱含地具有訪問權(quán)限。這些圓圈的交點(diǎn)往往是運(yùn)行工作負(fù)載的機(jī)器，并且節(jié)點(diǎn)必須沒有比正常功能所需的特權(quán)更多的特權(quán)。

***，在任何層通過擴(kuò)展添加新的能力，應(yīng)該遵循***實(shí)踐來傳達(dá)該行為的影響。

當(dāng)一個(gè)能力通過擴(kuò)展被添加到系統(tǒng)時(shí)，它有什么目的?

• 使系統(tǒng)更加安全
• 為集群中的每一個(gè)人，啟用新的“生產(chǎn)質(zhì)量”API
• 在集群的子集上自動(dòng)完成一個(gè)公共任務(wù)
• 運(yùn)行一個(gè)向用戶提供API的托管工作負(fù)載(spark、數(shù)據(jù)庫、etcd)

它們被分為三大類：

1. 集群所需的(因此必須在內(nèi)核附近運(yùn)行，并在存在故障時(shí)導(dǎo)致操作權(quán)衡)
2. 暴露于所有集群用戶(必須正確地租用)
3. 暴露于集群用戶的子集(像傳統(tǒng)的“應(yīng)用程序”工作負(fù)載運(yùn)行)

如果管理員可以很容易地被誘騙，在擴(kuò)展期間安裝新的群集級安全規(guī)則，那么分層被破壞，并且系統(tǒng)是脆弱的。

本文譯者：季向遠(yuǎn)，北京神舟航天軟件技術(shù)有限公司產(chǎn)品經(jīng)理。