更多細(xì)節(jié)請(qǐng)參見：Architectural Roadmap（架構(gòu)演進(jìn)路線）

概述

Kubernetes是由谷歌開發(fā)的，為了在主機(jī)集群間的應(yīng)用容器可以進(jìn)行部署、動(dòng)態(tài)伸縮、管理的一個(gè)生產(chǎn)級(jí)別的、開源的基礎(chǔ)設(shè)施。Kubernetes不僅想要做一個(gè)容器編排者，它的目的在于減輕各種資源（包括虛擬/物理計(jì)算資源、網(wǎng)絡(luò)資源、存儲(chǔ)資源等）的編排負(fù)擔(dān)，讓應(yīng)用的維護(hù)和開發(fā)者能夠更專注于容器原生的服務(wù)構(gòu)建。Kubernetes也為構(gòu)建定制工作流和更高等級(jí)的自動(dòng)操作提供了穩(wěn)定的、輕便的基礎(chǔ)設(shè)施（一個(gè)平臺(tái)）。

作用域

Kubernetes是一個(gè)用于部署和管理容器的平臺(tái)。Kubernetes提供了容器運(yùn)行時(shí)間管理、容器編排、容器原生基建編排、自愈的機(jī)制，例如：健康狀態(tài)監(jiān)測、重調(diào)度、服務(wù)發(fā)現(xiàn)、負(fù)載均衡等。

Kubernetes希望成為一個(gè)可擴(kuò)展、插件化的平臺(tái)和工具集。因此，架構(gòu)上，我們希望Kubernetes成為一個(gè)可插拔組件/平面的集合，如此就有能力在調(diào)度器、控制器、存儲(chǔ)系統(tǒng)、分布式組件等方面做靈活的選擇，我們也正在令它的代碼往這個(gè)方向去演進(jìn)。此外，我們也希望開發(fā)者能夠不必修改其源代碼就能實(shí)現(xiàn)功能的擴(kuò)展，例如更高層次的PaaS支持，或者多集群架構(gòu)。因此，它的API不僅面向終端使用者，更面向工具和擴(kuò)展功能的開發(fā)者。它的API是有意地被設(shè)計(jì)作為開源生態(tài)系統(tǒng)、自動(dòng)化系統(tǒng)和更高級(jí)別的API的基礎(chǔ)?？偠灾瑳]有任何所謂的“內(nèi)部”API。所有的API，包括那些被調(diào)度器、節(jié)點(diǎn)控制器、復(fù)制管理器、Kubelet等等使用的API，都是可見的和可用的。這么設(shè)計(jì)是為了能夠兼容更多的復(fù)雜使用場景，比如說，在某些完全透明的組合操作中，一些操作需要訪問到底層的API。

目標(biāo)

這個(gè)項(xiàng)目承諾遵循以下的設(shè)計(jì)原則：

• 輕便的。Kubernetes可以在任何地方運(yùn)行——公有云、私有云、裸機(jī)、手提電腦等——因其具有一致的行為，應(yīng)用程序和工具就可以在整個(gè)生態(tài)系統(tǒng)以及任何開發(fā)環(huán)境或生產(chǎn)環(huán)境中隨意移植。
• 通用性強(qiáng)的。Kubernetes應(yīng)該運(yùn)行所有主要類別的工作，以便用戶可以在一個(gè)單一的基礎(chǔ)平臺(tái)上運(yùn)行自己的所有服務(wù)，無論基礎(chǔ)平臺(tái)是有狀態(tài)還是無狀態(tài)的，微服務(wù)隔離的還是整體控制的，服務(wù)型還是批處理型，新建環(huán)境還是遺留環(huán)境。
• 某種程度上適配用戶。Kubernetes并不僅僅適配全新的云原生應(yīng)用，也不能支持所有的應(yīng)用架構(gòu)。它專注于微服務(wù)和云原生應(yīng)用的部署和管理，也提供一些機(jī)制來幫助傳統(tǒng)應(yīng)用向微服務(wù)的方向遷移。
• 靈活的。Kubernetes的功能能夠被定制，并且在大多數(shù)情況下，也并不組織用戶用自己的解決方案代替內(nèi)置功能。
• 可拓展的。Kubernetes通過暴露內(nèi)部接口，使用戶能夠?qū)ubernetes集成到自己的平臺(tái)上，或者額外增加一些功能。
• 自動(dòng)化的。Kubernetes的目標(biāo)是顯著降低運(yùn)維操作。它既支持聲明式控制，即用戶通過API指定所需意圖，也支持命令式控制以支持更高級(jí)別的編制和自動(dòng)化。聲明式方法是系統(tǒng)自修復(fù)和自管理的關(guān)鍵。
• 驅(qū)動(dòng)當(dāng)前技術(shù)發(fā)展。Kubernetes打算支持非云原生應(yīng)用，也渴望驅(qū)動(dòng)云原生和DevOps的技術(shù)發(fā)展，例如在participation of applications in their own management（參與應(yīng)用自己的管理）。但是，與此同時(shí)，我們也嚴(yán)格要求自己不要把應(yīng)用綁定在Kubernetes的生態(tài)上，這也是為什么我們?cè)谀舷駻PI中，更喜歡配置而非約定。同時(shí)，Kubernetes也不受其運(yùn)行平臺(tái)的最低水平限制，例如容器運(yùn)行時(shí)間和云服務(wù)提供商，舉個(gè)例子，我們?cè)?a href="https:///docs/concepts/cluster-administration/networking/#kubernetes-model">IP per Pod networking model（每Pod一個(gè)IP的網(wǎng)絡(luò)模型中），突破了可實(shí)現(xiàn)的極限。

架構(gòu)

一個(gè)運(yùn)行中的Kubernetes包括節(jié)點(diǎn)代理（kubelet）和一個(gè)集群控制平面（也稱為master），集群狀態(tài)存儲(chǔ)在一個(gè)分布式存儲(chǔ)系統(tǒng)（etcd）中。

集群控制平面（也稱為master）

Kubernetes的集群控制平面（control plane）被切分為一堆的組件，能運(yùn)行于單個(gè)master節(jié)點(diǎn)，也能多副本地運(yùn)行于一個(gè)高可用集群中，甚至能運(yùn)行在Kubernetes自身（self-hosted）。

Kubernetes提供REST規(guī)范的API支持主流的CURD操作用于持久化資源，這也是其控制平面的中心。Kubernetes的API提供了IaaS一般的容器中心基元例如Pods,?Services, Ingress，也提供了生命周期API，來支持編排常見的特性（如自修復(fù)，動(dòng)態(tài)伸縮，更新，終止），例如ReplicaSet?（簡易可替換/無狀態(tài)應(yīng)用程序管理器）,?Deployment?（編排無狀態(tài)的應(yīng)用更新）,?Job?（批處理）,?CronJob?（定時(shí)任務(wù)）,?DaemonSet（集群服務(wù)）, and?StatefulSet?（有狀態(tài)應(yīng)用）。我們故意地將服務(wù)發(fā)現(xiàn)和負(fù)載均衡從應(yīng)用實(shí)現(xiàn)中解耦了出來，因?yàn)閼?yīng)用實(shí)現(xiàn)是開放且差異非常大的。

用戶的客戶端和組件都包含了異步控制器來和相同的API資源交互，API資源作為了調(diào)和點(diǎn)、中間件、狀態(tài)共享而存在。大部分資源包含元數(shù)據(jù)，包括labels（標(biāo)簽）和annotations（注釋），非常詳盡的目標(biāo)狀態(tài)，包括默認(rèn)值和觀測到的當(dāng)前狀態(tài)。

控制器持續(xù)地工作，驅(qū)動(dòng)從當(dāng)前狀態(tài)向目標(biāo)狀態(tài)轉(zhuǎn)變，與此同時(shí)也不斷地向用戶和其他控制器上報(bào)當(dāng)前觀測到的狀態(tài)。

假如控制器是設(shè)置成水平觸發(fā)的，以此來增大容錯(cuò)率，它通常會(huì)監(jiān)控相關(guān)資源的變化，以此來減少反應(yīng)延遲和重復(fù)工作。這使得無需消息總線就可以實(shí)現(xiàn)分散和解耦的類似于編排的協(xié)調(diào)。

API服務(wù)

API server（API服務(wù)）提供了Kubernetes API，它被設(shè)計(jì)成一個(gè)相當(dāng)簡單的服務(wù)，其大部分業(yè)務(wù)邏輯在分散的組件和插件中實(shí)現(xiàn)。它主要處理REST請(qǐng)求，并更新etcd（或其他存儲(chǔ)）中的相應(yīng)對(duì)象。值得注意的是，因?yàn)槟承┰騅ubernetes不支持跨資源的原子性事務(wù)。

Kubernetes必須在以下API機(jī)制幫助下運(yùn)行：

• REST原則、監(jiān)聽、持久性和一致性保證、API的版本控制、默認(rèn)設(shè)置、鑒權(quán)
• 內(nèi)置的接入控制機(jī)制，同步的接入控制鉤子，和異步資源初始化
• API注冊(cè)和發(fā)現(xiàn)

此外，API服務(wù)也作為集群對(duì)外的接口。從定義上講，API服務(wù)必須暴露給集群以外的客戶端，然而集群內(nèi)的節(jié)點(diǎn)和容器可能是不暴露的。客戶端通過API服務(wù)進(jìn)行鑒權(quán)，也以API服務(wù)作為堡壘機(jī)訪問集群中的節(jié)點(diǎn)和服務(wù)。

集群狀態(tài)存儲(chǔ)

所有持久化的集群狀態(tài)存儲(chǔ)在etcd的一個(gè)實(shí)例中，這也提供了一個(gè)可靠的方法來存儲(chǔ)配置數(shù)據(jù)。通過監(jiān)控的支持，協(xié)調(diào)組件能夠很快地感知集群的變化。

控制管理服務(wù)

大部分其他的集群層面上的功能由一個(gè)分布式服務(wù)實(shí)現(xiàn)，稱作Controller Manager（控制管理服務(wù)）。它既執(zhí)行生命周期函數(shù)（命名空間的創(chuàng)建和生命周期管理、事件垃圾回收、終端Pod垃圾回收、級(jí)聯(lián)刪除垃圾回收、節(jié)點(diǎn)垃圾回收），也實(shí)現(xiàn)API業(yè)務(wù)邏輯（Pod的動(dòng)態(tài)伸縮）。

應(yīng)用管理和組合面提供了自修復(fù)、動(dòng)態(tài)伸縮、應(yīng)用生命周期管理、服務(wù)發(fā)現(xiàn)、路由、服務(wù)綁定和發(fā)放功能。

這些功能可能最后被拆分到多個(gè)組件中去以使其更加易于擴(kuò)展和可替代。

調(diào)度器

Kubernetes允許用戶在一個(gè)集群中運(yùn)行多個(gè)容器。調(diào)度器組件能夠自動(dòng)地選擇哪個(gè)物理/虛擬機(jī)來運(yùn)行這些容器。

調(diào)度器監(jiān)控那些未經(jīng)調(diào)度的Pod，并使用“/binding”API來將它們綁定到節(jié)點(diǎn)上。調(diào)度依據(jù)Pods請(qǐng)求的資源的可用性、服務(wù)的質(zhì)量、親和性和反親和性以及其他的一些限制。

Kubernetes支持用戶自行提供調(diào)度器和多并發(fā)的調(diào)度器（使用由Omega首創(chuàng)的共享狀態(tài)方法）。除了Omega的論文中提到的悲觀的并發(fā)狀況之外，two-level scheduling models（二級(jí)調(diào)度模型）中，高層調(diào)度器和低層調(diào)度器均需實(shí)現(xiàn)相同的調(diào)度需求以保證供調(diào)度的資源能滿足它們的需求。

Kubernetes節(jié)點(diǎn)

Kubernetes節(jié)點(diǎn)有運(yùn)行應(yīng)用容器以及接受管理所需的必要服務(wù)。

Kubelet

Kubernetes體系中，最重要也最突出的控制器就是Kubelet，它是Pod和節(jié)點(diǎn)API的主要實(shí)現(xiàn)者，驅(qū)動(dòng)了容器執(zhí)行面。沒有了這些API，Kubernetes可能就只是一個(gè)應(yīng)用的CURD操作的框架，背后有一個(gè)存儲(chǔ)系統(tǒng)而已。

Kubernetes使用獨(dú)立的應(yīng)用容器作為其默認(rèn)的本機(jī)執(zhí)行模式，而非進(jìn)程或傳統(tǒng)的操作系統(tǒng)包。不僅應(yīng)用容器間相互獨(dú)立，并且應(yīng)用容器也和運(yùn)行它們的物理節(jié)點(diǎn)相互獨(dú)立，這也是解耦不同應(yīng)用的管控和基礎(chǔ)設(shè)施的管控的關(guān)鍵點(diǎn)。

Kubernetes提供了Pods這樣的能夠同時(shí)運(yùn)行數(shù)個(gè)容器并共享存儲(chǔ)的管理基元，以便為每個(gè)容器打包單個(gè)應(yīng)用程序，將部署和構(gòu)建解耦，在不同的（物理/虛擬）節(jié)點(diǎn)間進(jìn)行遷移。以Pod作為管理基元是部署在現(xiàn)代云平臺(tái)上，如Kubernetes，的主要好處。

API準(zhǔn)入控制也許會(huì)拒絕Pods或向它們添加額外的調(diào)度約束，但是Kubelet最終決定Pods能否在給定節(jié)點(diǎn)上運(yùn)行，而不是調(diào)度程序或守護(hù)進(jìn)程集。

Kubelet目前也會(huì)受到cAdvisor資源監(jiān)控代理的監(jiān)控。

容器運(yùn)行時(shí)間

每個(gè)節(jié)點(diǎn)都維護(hù)一個(gè)容器運(yùn)行時(shí)間，在下載鏡像和運(yùn)行容器時(shí)起作用。

Kubelet并不鏈接到基礎(chǔ)的容器運(yùn)行時(shí)間。相反，我們定義了一個(gè)Container Runtime Interface（容器運(yùn)行時(shí)間接入面）來管控下層的運(yùn)行時(shí)間，這種機(jī)制也促進(jìn)了這個(gè)層面的可插拔性。為了維護(hù)組件間的邊界，促進(jìn)可調(diào)試性和可插拔性，這種解耦是很有必要的。今天的運(yùn)行時(shí)間支持，不管是上游的還是分叉的，都至少支持docker,?rkt,?cri-o,?frakti。

Kube Proxy

服務(wù)的抽象提供了一種劃分Pods的公開原則（例如，負(fù)載均衡）。這種實(shí)現(xiàn)創(chuàng)建了一個(gè)虛擬IP給客戶端訪問，并且這個(gè)IP被透明代理給一個(gè)服務(wù)中的Pods。每個(gè)節(jié)點(diǎn)都運(yùn)行了一個(gè)kube-proxy，其通過規(guī)劃防火墻規(guī)則來將不同的訪問重定向到正確的后端。這提供了一個(gè)高可用的負(fù)載均衡解決方案，通過平衡同一節(jié)點(diǎn)的流量來實(shí)現(xiàn)低性能消耗。

服務(wù)端點(diǎn)主要通過DNS創(chuàng)建

附加組件和其他依賴

非常多的組件作為附加組件運(yùn)行在Kubernetes上：

• DNS
• Ingress controller
• Heapster?(resource monitoring)
• Dashboard?(GUI)

集群聯(lián)邦

單一的Kubernetes集群可能跨越多個(gè)可用區(qū)域。

然而，為了更高的可用性，我們推薦cluster federation（集群聯(lián)邦）。