摘要：本文中，我們將描述系統(tǒng)的架構(gòu)開(kāi)發(fā)演進(jìn)過(guò)程，以及背后的驅(qū)動(dòng)原因。應(yīng)用管理層提供基本的部署和路由，包括自愈能力彈性擴(kuò)容服務(wù)發(fā)現(xiàn)負(fù)載均衡和流量路由。

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

1、背景

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

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

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

核心層（Nucleus）： 提供標(biāo)準(zhǔn)的API和執(zhí)行機(jī)制，包括基本的REST機(jī)制，安全、Pod、容器、網(wǎng)絡(luò)接口和存儲(chǔ)卷管理，通過(guò)接口能夠?qū)@些API和執(zhí)進(jìn)行擴(kuò)展，核心層是必需的，它是系統(tǒng)最核心的一部分。

應(yīng)用管理層（Application Management Layer )：提供基本的部署和路由，包括自愈能力、彈性擴(kuò)容、服務(wù)發(fā)現(xiàn)、負(fù)載均衡和流量路由。此層即為通常所說(shuō)的服務(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í)行。這些都是可選的，也可以通過(guò)其它解決方案實(shí)現(xiàn)。

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

生態(tài)層（The Ecosystem）：包括與Kubernetes相關(guān)的所有內(nèi)容，嚴(yán)格上來(lái)說(shuō)這些并不是Kubernetes的組成部分。包括CI/CD、中間件、日志、監(jiān)控、數(shù)據(jù)處理、PaaS、serverless/FaaS系統(tǒng)、工作流、容器運(yùn)行時(shí)、鏡像倉(cāng)庫(kù)、Node和云提供商管理等。

2、系統(tǒng)分層

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

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

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

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

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

2.1.1 API和集群控制面板

Kubernetes集群提供了類似REST API的集，通過(guò)Kubernetes API server對(duì)外進(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)用場(chǎng)景。核心層也需要提供足夠的彈性，以支持高層能擴(kuò)展新的范圍，而不需要在安全模式方面進(jìn)行妥協(xié)。

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

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

1、The TokenReview API (與hook的機(jī)制一樣) 能夠啟用外部認(rèn)證檢查，例如Kubelet

2、Pod身份標(biāo)識(shí)通過(guò)”service accounts“提供

3、The ServiceAccount API，包括通過(guò)控制器創(chuàng)建的默認(rèn)ServiceAccount保密字段，并通過(guò)接入許可控制器進(jìn)行注入。

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

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

REST 語(yǔ)義、監(jiān)控、持久化和一致性保證、API版本控制、違約、驗(yàn)證

1、NIY：需要被解決的API缺陷：

2、混淆違約行為

3、缺少保障

4、編排支持

5、支持事件驅(qū)動(dòng)的自動(dòng)化

6、干凈卸載

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

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

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

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

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

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

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

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

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

1、Add-ons應(yīng)該是一個(gè)集群服務(wù)，作為集群的一部分進(jìn)行管理

2、它們可以運(yùn)行在kube-system命名空間，這么就不會(huì)與用戶的命名進(jìn)行沖突

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

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

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

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

持久化狀態(tài)存儲(chǔ) (etcd，或相對(duì)應(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)者，沒(méi)有這些API的話，Kubernetes將僅僅只是由鍵值對(duì)存儲(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語(yǔ)義包括：

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

1、Pod可行性準(zhǔn)入控制基于Pod API中的策略(資源請(qǐng)求、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ǔ)卷語(yǔ)義和生命周期

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

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

5、存儲(chǔ)卷來(lái)源：

5.1、emptyDir

5.2、hostPath

5.3、secret

5.4、configMap

5.5、downwardAPI

5.6、NIY：容器和鏡像存儲(chǔ)卷 (and deprecate gitRepo)

5.7、NIY：本地存儲(chǔ)，對(duì)于開(kāi)發(fā)和生產(chǎn)應(yīng)用清單不需要復(fù)雜的模板或獨(dú)立配置

5.8、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的宿主

1、在一些配置中，可以僅僅對(duì)集群管理員可見(jiàn)

Node和pod網(wǎng)絡(luò)，業(yè)績(jī)它們的控制(路由控制器)

Node庫(kù)存、健康、和可達(dá)性(node控制器)

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

pod終止垃圾收集

存儲(chǔ)卷控制器

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

The PersistentVolume API

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

The PersistentVolumeClaim API

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

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

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

鏡像注冊(cè)

容器運(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)方案。沒(méi)有應(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)度策略：資源請(qǐng)求、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)該能夠通過(guò)聲明式更新、級(jí)聯(lián)刪除、和孤兒/領(lǐng)養(yǎng)支持發(fā)布(回滾)。除了DaemonSet，應(yīng)該能支持水平擴(kuò)容。

1、The Deployment API，編排更新無(wú)狀態(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用來(lái)記錄變更歷史

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

1、The Job API (GC discussion)

2、The CronJob API

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

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

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è)操作、安全和治理場(chǎng)景的一部分。

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

單一租戶/單一用戶集群

多租戶集群

生產(chǎn)和開(kāi)發(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à)來(lái)源類型

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 接口層：類庫(kù)和工具

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

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

客戶端類庫(kù)(例如：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ī)則，在對(duì)Kubernete通用編排功能進(jìn)行補(bǔ)足的功能領(lǐng)域，Kubernetes保持了用戶的選擇。特別是那些有自己的競(jìng)爭(zhēng)優(yōu)勢(shì)的區(qū)域，特別是能夠滿足不同需求和偏好的眾多解決方案。Kubernetes可以為這些解決方案提供插件API，或者可以公開(kāi)由多個(gè)后端實(shí)現(xiàn)的通用API，或者公開(kāi)此類解決方案可以針對(duì)的API。有時(shí)，功能可以與Kubernetes干凈地組合在而不需要顯式接口。

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

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

在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ù)庫(kù)。然而，可以提供通用目的的機(jī)制使其能夠被容易的提供、發(fā)現(xiàn)和訪問(wèn)。理想的情況是這些組件僅僅運(yùn)行在Kubernetes上。

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

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

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

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

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

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

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

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

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

支撐Kubernetes

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

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

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)。通常針對(duì)不同的公有/私有云，針對(duì)不同的操作系統(tǒng)，針對(duì)可變的和不可變的基礎(chǔ)設(shè)施。

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

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

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

矩陣管理

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

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

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

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

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

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

類似于StorageClass，擴(kuò)展和它們的選項(xiàng)應(yīng)該通過(guò)FoeClass資源進(jìn)行注冊(cè)。但是，使用參數(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)識(shí)負(fù)責(zé)的控制器。需要至少為調(diào)度器類、ingress控制器類、Flex存儲(chǔ)卷類和計(jì)算資源類（例如GPU、其他加速器）添加這樣的API。

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

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

準(zhǔn)入控制插件和hooks(包括內(nèi)置的APIs)

身份認(rèn)證插件

授權(quán)插件和hooks

初始化和終結(jié)器

調(diào)度器擴(kuò)展

Node標(biāo)簽和集群拓?fù)?/p>

NIY：?jiǎn)蝹€(gè)API和細(xì)粒度特征的激活/失活可以通過(guò)以下機(jī)制解決：

所有組件的配置正在從命令行標(biāo)志轉(zhuǎn)換為版本化配置。

打算將大部分配置數(shù)據(jù)存儲(chǔ)在配置映射(ConfigMaps)中，以便于動(dòng)態(tài)重新配置、漸進(jìn)發(fā)布和內(nèi)省性。

所有/多個(gè)組件共同的配置應(yīng)該被分解到它自己的配置對(duì)象中。這應(yīng)該包括特征網(wǎng)關(guān)機(jī)制。

應(yīng)該為語(yǔ)義意義上的設(shè)置添加API，例如，在無(wú)響應(yīng)節(jié)點(diǎn)上刪除Pod之前需要等待的默認(rèn)時(shí)間長(zhǎng)度。

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

為所有新的特性創(chuàng)建flag網(wǎng)關(guān)

總是在它們出現(xiàn)的第一個(gè)小版本中，默認(rèn)禁用這些特性，

提供啟用特性的配置補(bǔ)??；

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

NIY：我們還需要一個(gè)機(jī)制來(lái)警告過(guò)時(shí)的節(jié)點(diǎn)，和/或潛在防止Master升級(jí)（除了補(bǔ)丁發(fā)布），直到/除非Node已經(jīng)升級(jí)。

NIY：字段級(jí)版本管理將有助于大量激活新的和/或alpha API字段的解決方案，防止不良寫(xiě)入過(guò)時(shí)的客戶端對(duì)新字段的阻塞，以及非alpha API的演進(jìn)，而不需要成熟的API定義的擴(kuò)散。

Kubernetes API server忽略不支持的資源字段和查詢參數(shù)，但不忽略未知的/未注冊(cè)的API（注意禁用未實(shí)現(xiàn)的/不活動(dòng)的API）。這有助于跨多個(gè)版本的集群重用配置，但往往會(huì)帶來(lái)意外。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)用級(jí)服務(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和控制器（用戶授予訪問(wèn)API /控制器，以代表用戶執(zhí)行操作），無(wú)論是在集群范圍內(nèi)還是在更小的范圍內(nèi)

在不同范圍，運(yùn)行不受信任/作用域API和控制器和用戶工作負(fù)載

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

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

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

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

使系統(tǒng)更加安全

為集群中的每一個(gè)人，啟用新的“生產(chǎn)質(zhì)量”API

在集群的子集上自動(dòng)完成一個(gè)公共任務(wù)

運(yùn)行一個(gè)向用戶提供API的托管工作負(fù)載（spark、數(shù)據(jù)庫(kù)、etcd）

它們被分為三大類：

1、集群所需的（因此必須在內(nèi)核附近運(yùn)行，并在存在故障時(shí)導(dǎo)致操作權(quán)衡）

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

3、暴露于集群用戶的子集（像傳統(tǒng)的“應(yīng)用程序”工作負(fù)載運(yùn)行）

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

英文原文：
https://github.com/kubernetes...
本文譯者：
季向遠(yuǎn)，北京神舟航天軟件技術(shù)有限公司產(chǎn)品經(jīng)理。
本文版權(quán)歸原作者所有。本文版權(quán)歸原作者所有。