Kubernetes系統(tǒng)架構(gòu)演進(jìn)過(guò)程是什么

本篇內(nèi)容主要講解“Kubernetes系統(tǒng)架構(gòu)演進(jìn)過(guò)程是什么”，感興趣的朋友不妨來(lái)看看。本文介紹的方法操作簡(jiǎn)單快捷，實(shí)用性強(qiáng)。下面就讓小編來(lái)帶大家學(xué)習(xí)“Kubernetes系統(tǒng)架構(gòu)演進(jìn)過(guò)程是什么”吧!

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)的開發(fā)藍(lán)圖。

本文中，我們將描述Kubernetes系統(tǒng)的架構(gòu)開發(fā)演進(jìn)過(guò)程，以及背后的驅(qū)動(dòng)原因。對(duì)于希望擴(kuò)展或者定制kubernetes系統(tǒng)的開發(fā)者，其應(yīng)該使用此文檔作為向?qū)?，以明確可以在哪些地方，以及如何進(jìn)行增強(qiáng)功能的實(shí)現(xiàn)。如果應(yīng)用開發(fā)者需要開發(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ì)于開發(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ì)使用它們。開發(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客戶端證書模式，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)的?？蛻舳苏J(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證書。

理想情況下，核心層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ì)于開發(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ì)集群管理員可見

• 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)和開發(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)目開發(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，或者可以公開由多個(gè)后端實(shí)現(xiàn)的通用API，或者公開此類解決方案可以針對(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ò)編寫代碼來(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)開發(fā)了很多的工具，利潤(rùn)minikube、kubeadm、bootkube、kube-aws、kops、kargo, kubernetes-anywhere等待。 從工具的多樣性可以看出，集群部署和管理（例如，升級(jí)）沒(méi)有一成不變的解決方案。也就是說(shuō)，常見的構(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è)開源的工具箱，而且是一個(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)用程序，為了使開發(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)開發(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字段的解決方案，防止不良寫入過(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)。

1. 用于存儲(chǔ)核心API的一個(gè)或者多個(gè)數(shù)據(jù)存儲(chǔ)系統(tǒng)(etcd)

2. 核心APIs

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

4. 委托的信任API和控制器（用戶授予訪問(wèn)API /控制器，以代表用戶執(zhí)行操作），無(wú)論是在集群范圍內(nèi)還是在更小的范圍內(nèi)

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

當(dāng)較低層依賴于更高的層時(shí)，它會(huì)使安全模型崩潰，并使系統(tǒng)變得更加復(fù)雜。管理員可以選擇這樣做以獲得操作簡(jiǎn)單性，但這必須是有意識(shí)的選擇。一個(gè)簡(jiǎn)單的例子是etcd：可以將數(shù)據(jù)寫入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)是脆弱的。

到此，相信大家對(duì)“Kubernetes系統(tǒng)架構(gòu)演進(jìn)過(guò)程是什么”有了更深的了解，不妨來(lái)實(shí)際操作一番吧！這里是億速云網(wǎng)站，更多相關(guān)內(nèi)容可以進(jìn)入相關(guān)頻道進(jìn)行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！