Kubernetes（K8s）作為當(dāng)今最流行的容器編排引擎之一，其集群架構(gòu)和組件扮演著關(guān)鍵角色，為現(xiàn)代化云原生應(yīng)用的部署、擴(kuò)展和管理提供了強(qiáng)大的支持。本文將深入探討K8s集群的架構(gòu)以及核心組件，幫助讀者更好地理解Kubernetes的工作原理和設(shè)計(jì)思想。

Kubernetes 架構(gòu)

Kubernetes集群由多個(gè)節(jié)點(diǎn)組成，其中包括Master節(jié)點(diǎn)和Worker節(jié)點(diǎn)。Master節(jié)點(diǎn)負(fù)責(zé)集群的控制平面，而Worker節(jié)點(diǎn)負(fù)責(zé)運(yùn)行實(shí)際的應(yīng)用程序容器。

一個(gè)Kubernetes集群由控制平面節(jié)點(diǎn)和工作節(jié)點(diǎn)組成。

1.控制平面

控制平面負(fù)責(zé)容器編排和維護(hù)集群的期望狀態(tài)。它包括以下組件：

• kube-apiserver
• etcd
• kube-scheduler
• kube-controller-manager
• cloud-controller-manager

一個(gè)集群可以有一個(gè)或多個(gè)控制平面節(jié)點(diǎn)。

2.工作節(jié)點(diǎn)

工作節(jié)點(diǎn)負(fù)責(zé)運(yùn)行容器化的應(yīng)用程序。工作節(jié)點(diǎn)包括以下組件：

• kubelet
• kube-proxy
• 容器運(yùn)行時(shí)（Container runtime）

分層架構(gòu)

Kubernetes 設(shè)計(jì)理念和功能其實(shí)就是一個(gè)類似 Linux 的分層架構(gòu)，如下圖所示：

分層架構(gòu)

• 核心層：Kubernetes 最核心的功能，對外提供 API 構(gòu)建高層的應(yīng)用，對內(nèi)提供插件式應(yīng)用執(zhí)行環(huán)境
• 應(yīng)用層：部署（無狀態(tài)應(yīng)用、有狀態(tài)應(yīng)用、批處理任務(wù)、集群應(yīng)用等）和路由（服務(wù)發(fā)現(xiàn)、DNS 解析等）
• 管理層：系統(tǒng)度量（如基礎(chǔ)設(shè)施、容器和網(wǎng)絡(luò)的度量），自動(dòng)化（如自動(dòng)擴(kuò)展、動(dòng)態(tài) Provision 等）以及策略管理RBAC、Quota、PSP、NetworkPolicy 等
• 接口層：kubectl 命令行工具、客戶端 SDK 以及集群聯(lián)邦
• 生態(tài)系統(tǒng)：在接口層之上的龐大容器集群管理調(diào)度的生態(tài)系統(tǒng)，可以劃分為兩個(gè)范疇。

控制面板組件

首先，讓我們看看每個(gè)控制平面組件以及每個(gè)組件背后的重要概念。

1.kube-apiserver

kube-api服務(wù)器是公開Kubernetes API的Kubernetes集群的中心樞紐。它具有高度的可擴(kuò)展性，可以處理大量并發(fā)請求。最終用戶和其他集群組件通過API服務(wù)器與集群通信。監(jiān)控系統(tǒng)和第三方服務(wù)很少會(huì)與API服務(wù)器通信，與集群進(jìn)行交互。因此，當(dāng)您使用kubectl來管理集群時(shí)，在后端您實(shí)際上是通過HTTP REST API與API服務(wù)器通信。然而，集群內(nèi)部的組件如調(diào)度器、控制器等使用gRPC與API服務(wù)器通信。API服務(wù)器和集群中的其他組件之間通過TLS進(jìn)行通信，以防止對集群的未授權(quán)訪問。

Kubernetes api-server負(fù)責(zé)以下工作：

• API管理：公開集群API端點(diǎn)并處理所有API請求。API是version，它同時(shí)支持多個(gè)API版本。
• 身份驗(yàn)證：(使用客戶端證書、不記名令牌和HTTP基本身份驗(yàn)證)和授權(quán)(ABAC和RBAC評(píng)估)
• 處理API請求并為API對象(如pods, services等)驗(yàn)證數(shù)據(jù)(驗(yàn)證和變異接納控制器)
• 它是唯一與etcd通信的組件。
• API-Server協(xié)調(diào)控制平面和工作節(jié)點(diǎn)組件之間的所有進(jìn)程。
• API-Server有一個(gè)內(nèi)置的apiserver代理。它是API服務(wù)器進(jìn)程的一部分。它主要用于從集群外部訪問ClusterIP服務(wù)，即使這些服務(wù)通常只能在集群內(nèi)部訪問。
• API服務(wù)器還包含一個(gè)聚合層，它允許您擴(kuò)展Kubernetes API以創(chuàng)建自定義API資源和控制器。
• API服務(wù)器還支持監(jiān)視資源的變化。例如，客戶端可以對特定資源建立監(jiān)視，并在創(chuàng)建、修改或刪除這些資源時(shí)接收實(shí)時(shí)通知

2.etcd

Kubernetes是一個(gè)分布式系統(tǒng)，它需要一個(gè)高效的分布式數(shù)據(jù)庫，如etcd，以支持其分布式特性。它既是一個(gè)后端服務(wù)發(fā)現(xiàn)，也是一個(gè)數(shù)據(jù)庫。你可以稱它為Kubernetes集群的大腦。

Etcd是一個(gè)開源的強(qiáng)一致性分布式鍵值存儲(chǔ)。它具體意味著什么？

• 強(qiáng)一致性：如果對一個(gè)節(jié)點(diǎn)進(jìn)行了更新，強(qiáng)一致性將確保該節(jié)點(diǎn)立即更新到集群中的所有其他節(jié)點(diǎn)。此外，如果你看看CAP定理，在強(qiáng)一致性和分區(qū)容忍下實(shí)現(xiàn)100%的可用性是不可能的。
• 分布式：etcd被設(shè)計(jì)成在多個(gè)節(jié)點(diǎn)上作為一個(gè)集群運(yùn)行，而不會(huì)犧牲一致性。
• 鍵值存儲(chǔ)(Key Value Store) ：一種非關(guān)系型數(shù)據(jù)庫，以鍵和值的形式存儲(chǔ)數(shù)據(jù)。它還公開了一個(gè)key-value API。該數(shù)據(jù)存儲(chǔ)構(gòu)建在BoltDB的一個(gè)分支BboltDB之上。

Etcd采用raft共識(shí)算法實(shí)現(xiàn)強(qiáng)一致性和可用性。它以領(lǐng)導(dǎo)者-成員的方式工作，以獲得高可用性和抵御節(jié)點(diǎn)故障。

那么etcd如何與Kubernetes一起工作呢?

簡單地說，當(dāng)你使用kubectl來獲取kubernetes對象的細(xì)節(jié)時(shí)，你是從etcd中獲取它。此外，當(dāng)部署pod等對象時(shí)，會(huì)在etcd中創(chuàng)建一個(gè)條目。

簡而言之，以下是您需要了解的關(guān)于etcd的內(nèi)容：

• etcd存儲(chǔ)Kubernetes對象的所有配置、狀態(tài)和元數(shù)據(jù)(pods、secrets、daemonsets、deployment、configmaps、statefulsets等)。
• etcd允許客戶端使用Watch() API訂閱事件。Kubernetes api-server使用etcd的watch功能來跟蹤對象狀態(tài)的變化。
• etcd使用gRPC提供了key-value API。此外，gRPC網(wǎng)關(guān)是一個(gè)RESTful代理，它將所有HTTP API調(diào)用轉(zhuǎn)換為gRPC消息。這使得它成為Kubernetes的理想數(shù)據(jù)庫。
• Etcd以鍵值格式將所有對象存儲(chǔ)在/registry目錄下。例如，默認(rèn)命名空間中名為Nginx的pod的信息可以在/registry/pods/default/Nginx下找到

此外，etcd 是控制平面中唯一的 Statefulset 組件。

3.kube-scheduler

kube-scheduler負(fù)責(zé)在工作節(jié)點(diǎn)上調(diào)度Kubernetes pods。

當(dāng)您部署pod時(shí)，您需要指定pod需求，例如CPU、內(nèi)存、親和性、污點(diǎn)或容忍、優(yōu)先級(jí)、持久卷(PV)等。調(diào)度器的主要任務(wù)是識(shí)別創(chuàng)建請求，并為滿足要求的pod選擇最佳節(jié)點(diǎn)。

下圖概述了調(diào)度器的工作原理：

在Kubernetes集群中，將有多個(gè)工作節(jié)點(diǎn)。那么，調(diào)度器如何從所有工作節(jié)點(diǎn)中選擇節(jié)點(diǎn)呢?

下面是調(diào)度器的工作原理：

• 為了選擇最佳節(jié)點(diǎn)，Kube-scheduler使用過濾和評(píng)分操作。
• 在篩選過程中，調(diào)度器找到可以調(diào)度pod的最適合的節(jié)點(diǎn)。例如，如果有5個(gè)可用資源運(yùn)行pod的工作節(jié)點(diǎn)，它會(huì)選擇所有5個(gè)節(jié)點(diǎn)。如果沒有節(jié)點(diǎn)，那么pod是不可調(diào)度的，并移動(dòng)到調(diào)度隊(duì)列。如果是一個(gè)大型集群，假設(shè)有100個(gè)工作節(jié)點(diǎn)，調(diào)度器不會(huì)遍歷所有節(jié)點(diǎn)。有一個(gè)調(diào)度器配置參數(shù)，名為percentageOfNodesToScore。默認(rèn)值通常為50%。因此，它嘗試以輪詢方式迭代超過50%的節(jié)點(diǎn)。如果工作節(jié)點(diǎn)分布在多個(gè)內(nèi)存域，那么調(diào)度器會(huì)遍歷不同內(nèi)存域中的節(jié)點(diǎn)。對于非常大的集群，默認(rèn)percentageOfNodesToScore是5%。
• 在評(píng)分階段，調(diào)度器通過為過濾后的工作節(jié)點(diǎn)分配分?jǐn)?shù)來對節(jié)點(diǎn)進(jìn)行排名。調(diào)度器通過調(diào)用多個(gè)調(diào)度插件進(jìn)行評(píng)分。最后，選擇級(jí)別最高的工作節(jié)點(diǎn)進(jìn)行pod調(diào)度。如果所有節(jié)點(diǎn)的相同，則隨機(jī)選擇一個(gè)節(jié)點(diǎn)。
• 一旦節(jié)點(diǎn)被選中，調(diào)度器就會(huì)在API服務(wù)器中創(chuàng)建一個(gè)綁定事件。意味著綁定pod和node的事件。

下面是你需要知道的關(guān)于調(diào)度器的事情：

• 它是一個(gè)在API服務(wù)器中監(jiān)聽pod創(chuàng)建事件的控制器。
• 調(diào)度器有兩個(gè)階段。調(diào)度周期和綁定周期。它們合起來稱為調(diào)度上下文(scheduling context)。調(diào)度周期選擇一個(gè)工作節(jié)點(diǎn)，然后綁定周期將其應(yīng)用到集群上。
• 調(diào)度器總是將高優(yōu)先級(jí)的pods放在低優(yōu)先級(jí)的pods之前進(jìn)行調(diào)度。此外，在某些情況下，在pod開始在選定節(jié)點(diǎn)中運(yùn)行后，pod可能會(huì)被刪除或移動(dòng)到其他節(jié)點(diǎn)。如果你想了解更多，請閱讀Kubernetes pod優(yōu)先級(jí)指南[1]
• 用戶可以創(chuàng)建自定義調(diào)度器，并在集群上運(yùn)行多個(gè)調(diào)度器。當(dāng)你部署pod時(shí)，你可以在pod清單中指定自定義調(diào)度器。因此，調(diào)度決策將基于自定義調(diào)度器邏輯進(jìn)行。
• 調(diào)度器有一個(gè)可插拔的調(diào)度框架。這意味著你可以將自定義插件添加到調(diào)度工作流中。

4.kube-controller-manager

什么是控制器？控制器是運(yùn)行無限控制循環(huán)的程序。這意味著它持續(xù)運(yùn)行并監(jiān)視對象的實(shí)際和期望狀態(tài)。如果實(shí)際狀態(tài)和期望狀態(tài)存在差異，它確保kubernetes資源/對象處于期望狀態(tài)。

根據(jù)官方文件：在Kubernetes中，控制器是監(jiān)視集群狀態(tài)的控制循環(huán)，然后在需要時(shí)進(jìn)行更改或請求更改。每個(gè)控制器都試圖將當(dāng)前集群狀態(tài)移動(dòng)到期望狀態(tài)。

假設(shè)你想要?jiǎng)?chuàng)建一個(gè)部署，你在manifest YAML文件中指定所需的狀態(tài)(聲明方式)。例如，2個(gè)副本，1個(gè)卷掛載，configmap等。內(nèi)置的部署控制器確保部署始終處于所需的狀態(tài)。如果用戶用5個(gè)副本更新部署，部署控制器將識(shí)別它并確保所需狀態(tài)為5個(gè)副本。

kube-controller-manager是一個(gè)管理所有Kubernetes控制器的組件。Kubernetes資源/對象，如pods，命名空間，作業(yè)，replicaset由各自的控制器管理。此外，Kube調(diào)度器也是由Kube控制器管理器管理的控制器。

以下是重要的內(nèi)置Kubernetes控制器列表：

• Deployment Controller
• ReplicaSet Controller
• DaemonSet Controller
• Job Controller
• CronJob Controller
• Endpoints Controller
• Namespace Controller
• Service Accounts Controller
• Node Controller

以下是關(guān)于Kube控制器管理器您應(yīng)該了解的內(nèi)容：

• 它管理所有控制器，而這些控制器則試圖保持集群處于期望的狀態(tài)。
• 你可以通過自定義資源定義（Custom Resource Definition）來擴(kuò)展 Kubernetes，關(guān)聯(lián)自定義控制器。

5.cloud-controller-manager(CCM)

• 當(dāng)kubernetes部署在云環(huán)境中時(shí)，云控制器管理器充當(dāng)云平臺(tái)api和kubernetes集群之間的橋梁。
• 這樣，核心kubernetes的核心組件可以獨(dú)立工作，并允許云提供商使用插件與kubernetes集成。(例如，kubernetes集群和AWS cloud API之間的接口)
• 集成云控制器允許Kubernetes集群提供云資源，如實(shí)例(用于節(jié)點(diǎn))、負(fù)載均衡器(用于服務(wù))和存儲(chǔ)卷(用于持久卷)。

云控制器管理器包含一組特定于云平臺(tái)的控制器，確保特定于云的組件(節(jié)點(diǎn)、負(fù)載均衡器、存儲(chǔ)等)的所需狀態(tài)。以下是云控制器管理器的三個(gè)主要控制器：

• 節(jié)點(diǎn)控制器：該控制器通過與云提供商API通信更新節(jié)點(diǎn)相關(guān)信息。例如，節(jié)點(diǎn)標(biāo)記和注釋、獲取主機(jī)名、CPU和內(nèi)存可用性、節(jié)點(diǎn)健康狀況等。
• 路由控制器：負(fù)責(zé)在云平臺(tái)上配置網(wǎng)絡(luò)路由。這樣不同節(jié)點(diǎn)中的pods就可以相互通信。
• 服務(wù)控制器：它負(fù)責(zé)為kubernetes服務(wù)部署負(fù)載均衡器，分配IP地址等。

下面是云控制器管理器的一些經(jīng)典示例：

• 部署負(fù)載均衡器類型的Kubernetes服務(wù)。在這里，Kubernetes提供了一個(gè)特定于云的負(fù)載均衡器，并與Kubernetes服務(wù)集成。
• 為云存儲(chǔ)解決方案支持的pods配置存儲(chǔ)卷(PV)。

整體云控制器管理器管理kubernetes使用的特定云資源的生命周期。

節(jié)點(diǎn)組件

現(xiàn)在讓我們看看每個(gè)工作節(jié)點(diǎn)組件。

1.kubelet

Kubelet是一個(gè)運(yùn)行在集群中的每個(gè)節(jié)點(diǎn)上的代理組件。它不作為容器運(yùn)行，而是作為守護(hù)進(jìn)程運(yùn)行，由systemd管理。

它負(fù)責(zé)向API服務(wù)器注冊工作節(jié)點(diǎn)，并主要從API服務(wù)器使用podSpec (Pod規(guī)范- YAML或JSON)。podSpec定義了應(yīng)該在pod中運(yùn)行的容器、它們的資源(例如CPU和內(nèi)存限制)以及其他設(shè)置，如環(huán)境變量、卷和標(biāo)簽。

然后，它通過創(chuàng)建容器將podSpec帶到所需狀態(tài)。

簡而言之，kubelet負(fù)責(zé)以下工作：

• 為pod創(chuàng)建、修改和刪除容器。
• 負(fù)責(zé)處理活性，準(zhǔn)備和啟動(dòng)探針。
• 通過讀取pod配置和在主機(jī)上為卷掛載創(chuàng)建相應(yīng)的目錄來負(fù)責(zé)掛載卷。
• 通過調(diào)用API服務(wù)器(如cAdvisor和CRI)來收集和報(bào)告節(jié)點(diǎn)和pod狀態(tài)。
• Kubelet也是一個(gè)控制器，它監(jiān)視pod的變化，并利用節(jié)點(diǎn)的容器運(yùn)行時(shí)來拉取圖像，運(yùn)行容器等。

除了來自API服務(wù)器的podSpec, kubelet還可以接受來自文件、HTTP端點(diǎn)和HTTP服務(wù)器的podSpec?！皃odSpec from a file”的一個(gè)很好的例子是Kubernetes static pods。

靜態(tài)pods由kubelet控制，而不是API服務(wù)器。

這意味著你可以通過向Kubelet組件提供pod的YAML位置來創(chuàng)建pods。然而，Kubelet創(chuàng)建的靜態(tài)pods并不由API服務(wù)器管理。

這是一個(gè)靜態(tài)pod的真實(shí)示例。

在引導(dǎo)控制平面時(shí)，kubelet從位于/etc/kubernetes/manifest的podSpecs中將 api-server、scheduler 和 controller manager作為靜態(tài) pod。

以下是kubelet的一些關(guān)鍵內(nèi)容：

• Kubelet使用CRI(容器運(yùn)行時(shí)接口)gRPC接口與容器運(yùn)行時(shí)進(jìn)行通信。
• 它還向流日志公開HTTP端點(diǎn)，并為客戶端提供exec會(huì)話。
• 使用CSI (container storage interface) gRPC配置塊卷。
• 它使用集群中配置的CNI插件來分配pod的IP地址，并為pod設(shè)置必要的網(wǎng)絡(luò)路由和防火墻規(guī)則。

2.kube-proxy

要理解Kube-proxy，你需要對Kubernetes服務(wù)和端點(diǎn)對象有基本的了解。

Kubernetes中的服務(wù)是一種向內(nèi)部或外部流量暴露一組pods的方法。當(dāng)您創(chuàng)建服務(wù)對象時(shí)，它將獲得分配給它的虛擬IP。它被稱為clusterIP。它只能在Kubernetes集群內(nèi)訪問。

Endpoint對象包含一個(gè)服務(wù)對象下pod組的所有IP地址和端口。端點(diǎn)控制器負(fù)責(zé)維護(hù)pod IP地址(端點(diǎn))列表。服務(wù)控制器負(fù)責(zé)配置服務(wù)的端點(diǎn)。

你不能ping ClusterIP，因?yàn)镃lusterIP只用于服務(wù)發(fā)現(xiàn)，不像pod ip可以ping。

現(xiàn)在讓我們了解一下Kube-proxy。

Kube-proxy是一個(gè)守護(hù)進(jìn)程，在每個(gè)節(jié)點(diǎn)上作為守護(hù)進(jìn)程運(yùn)行。它是一個(gè)為pods實(shí)現(xiàn)Kubernetes服務(wù)概念的代理組件。(一組具有負(fù)載均衡的pods的單一DNS)。它主要代理UDP、TCP和SCTP，但不支持HTTP。

當(dāng)你使用Service(ClusterIP)公開pods時(shí)，Kube-proxy創(chuàng)建網(wǎng)絡(luò)規(guī)則，將流量發(fā)送到服務(wù)對象下分組的后端pods(endpoints)。這意味著，所有的負(fù)載平衡和服務(wù)發(fā)現(xiàn)都由Kube代理處理。

那么Kube-proxy是如何工作的呢?

Kube代理與API服務(wù)器通信以獲取服務(wù)(ClusterIP)以及相應(yīng)的pod ip和端口(endpoints)的詳細(xì)信息。它還監(jiān)視服務(wù)和端點(diǎn)的變化。

然后，Kube-proxy使用以下任意一種模式來創(chuàng)建/更新規(guī)則，將流量路由到服務(wù)背后的pods：

(1) IPTables：默認(rèn)模式。IPTables模式下，流量通過IPtable規(guī)則進(jìn)行處理。這意味著對于每個(gè)服務(wù)，都創(chuàng)建了IPtable規(guī)則。這些規(guī)則捕獲到達(dá)ClusterIP的流量，然后將其轉(zhuǎn)發(fā)到后端pods。在這種模式下，kube-proxy隨機(jī)選擇后端pod進(jìn)行負(fù)載均衡。連接建立后，請求會(huì)發(fā)送到同一個(gè)pod，直到連接終止。

(2) IPVS：對于超過1000個(gè)業(yè)務(wù)的集群，IPVS提供了性能提升。它支持以下后端負(fù)載平衡算法。

• rr：round-robin:默認(rèn)模式。
• Lc：最小連接數(shù)(最小打開連接數(shù))
• Dh：目標(biāo)哈希
• Sh：源散列
• Sed：預(yù)期的最短延遲
• Nq：永不排隊(duì)

(3) 用戶空間：(遺留&不推薦)

(4) 內(nèi)核空間：該模式僅適用于Windows系統(tǒng)。

如果您想了解kube-proxy IPtables和IPVS模式之間的性能差異，請閱讀這篇文章。此外，您可以通過將其替換為ciilium來運(yùn)行Kubernetes集群，而無需kube-proxy。

1.29 Alpha特性:Kubeproxy有一個(gè)新的基于????????????????的后端。nftables是IPtables的繼承者，旨在更簡單、更高效。

3.container runtime

你可能知道Java運(yùn)行時(shí)(JRE)。它是在主機(jī)上運(yùn)行Java程序所需的軟件。以同樣的方式，容器運(yùn)行時(shí)是運(yùn)行容器所需的軟件組件。

容器運(yùn)行時(shí)運(yùn)行在Kubernetes集群中的所有節(jié)點(diǎn)上。它負(fù)責(zé)從容器注冊表中拉取映像，運(yùn)行容器，為容器分配和隔離資源，以及管理主機(jī)上容器的整個(gè)生命周期。

為了更好地理解這一點(diǎn)，讓我們看看兩個(gè)關(guān)鍵概念:

• 容器運(yùn)行時(shí)接口(CRI) ：它是一組api，允許Kubernetes與不同的容器運(yùn)行時(shí)交互。它允許不同的容器運(yùn)行時(shí)與Kubernetes互換使用。CRI定義了用于創(chuàng)建、啟動(dòng)、停止和刪除容器以及管理映像和容器網(wǎng)絡(luò)的API。
• 開放容器計(jì)劃(Open Container Initiative, OCI):它是一組容器格式和運(yùn)行時(shí)的標(biāo)準(zhǔn)

Kubernetes支持與容器運(yùn)行時(shí)接口(CRI)兼容的多個(gè)容器運(yùn)行時(shí)(CRI-O, Docker Engine, containerd等)。這意味著，所有這些容器運(yùn)行時(shí)都實(shí)現(xiàn)了CRI接口并公開了gRPC CRI api(運(yùn)行時(shí)和映像服務(wù)端點(diǎn))。

那么Kubernetes如何利用容器運(yùn)行時(shí)呢?

正如我們在Kubelet部分中了解到的，Kubelet代理負(fù)責(zé)使用CRI API與容器運(yùn)行時(shí)交互，以管理容器的生命周期。它還從容器運(yùn)行時(shí)獲取所有容器信息，并將其提供給控制平面。

讓我們以CRI-O容器運(yùn)行時(shí)接口為例。以下是容器運(yùn)行時(shí)如何與kubernetes一起工作的高級(jí)概述。

• 當(dāng)從API服務(wù)器有對pod的新請求時(shí)，kubelet通過Kubernetes容器運(yùn)行時(shí)接口與CRI-O守護(hù)進(jìn)程通信，以啟動(dòng)所需的容器。
• CRI-O使用容器/映像庫從配置的容器注冊表中檢查并提取所需的容器映像。
• 然后CRI-O為容器生成OCI運(yùn)行時(shí)規(guī)范(JSON)。
• 然后，CRI-O啟動(dòng)一個(gè)oci兼容運(yùn)行時(shí)(runc)，根據(jù)運(yùn)行時(shí)規(guī)范啟動(dòng)容器進(jìn)程。

附加組件

• kube-dns： 負(fù)責(zé)為整個(gè)集群提供 DNS 服務(wù)
• Ingress Controller： 為服務(wù)提供外網(wǎng)入口
• Prometheus： 提供資源監(jiān)控
• Dashboard： 提供 GUI
• Federation： 提供跨可用區(qū)的集群
• Fluentd-elasticsearch： 提供集群日志采集、存儲(chǔ)與查詢

參考文檔：

[1]Kubernetes pod優(yōu)先級(jí)指南: https://devopscube.com/pod-priorityclass-preemption/