Kubernetes 使用共享網(wǎng)絡(luò)將多個(gè)物理機(jī)或虛擬機(jī)匯集到一個(gè)集群中，在各服務(wù)器之間進(jìn)行通信，該集群是配置 Kubernetes 的所有組件、功能和工作負(fù)載的物理平臺。 集群中一臺服務(wù)器（或高可用部署中的一組服務(wù)器）用作 Master ，負(fù)責(zé)管理整個(gè)集群，余下的其他機(jī)器用作 Worker Node ，它們是使用本地和外部資源接收和運(yùn)行工作負(fù)載的服務(wù)器。

Master

Master 是集群的網(wǎng)關(guān)和中樞，負(fù)責(zé)為用戶和客戶端暴露 API ，跟蹤其他服務(wù)器的健 康狀態(tài)、以最優(yōu)方式調(diào)度工作負(fù)載，以及編排其他組件之間的通信等任務(wù)，它是用戶或客戶端與集群之間的核心聯(lián)絡(luò)點(diǎn)，并負(fù)責(zé) Kubernetes 系統(tǒng)的大多數(shù)集中式管控邏輯。 單個(gè) Master 節(jié)點(diǎn)即可完成其所有的功能，但出于冗余及負(fù)載均衡等目的，生產(chǎn)環(huán)境中通常需要協(xié)同部署多個(gè)此類主機(jī)。

Node

Node 是 Kubernetes 集群的工作節(jié)點(diǎn)，負(fù)責(zé)接收來自 Master 的工作指令并根據(jù)指令相應(yīng)地創(chuàng)建或銷毀 Pod 對象，以及調(diào)整網(wǎng)絡(luò)規(guī)則以合理地路由和轉(zhuǎn)發(fā)流量等。 理論上講，Node 可以是任何形式的計(jì)算設(shè)備，不過 Master 會統(tǒng)一將其抽象為 Node 對象進(jìn)行管理。

Kubernetes 將所有 Node 的資源集結(jié)于一處形成一臺更加強(qiáng)大的“服務(wù)器”，在用戶將應(yīng)用部署于其上時(shí)，Master 會使用調(diào)度算法將其自動指派至某個(gè)特定的 Node 運(yùn)行。在 Node 加入集群或從集群中移除時(shí) Master 也會按需重新編排影響到的 Pod（容器）。于是，用戶無須關(guān)心其應(yīng)用究竟運(yùn)行于何處。

從抽象的視角來講， Kubernetes 還有著眾多的組件來支撐其內(nèi)部的業(yè)務(wù)邏輯，包括運(yùn)行應(yīng)用、應(yīng)用編排、服務(wù)暴露、應(yīng)用恢復(fù)等，它們在 Kubernetes 中被抽象為Pod、Label、Annotation、Ingress、Service、Controller等資源對象。

資源對象

Pod

Kubernetes 并不直接運(yùn)行容器，而是使用一個(gè)抽象的資源對象來封裝一個(gè)或者多個(gè)容器，這個(gè)抽象為 Pod ，它也是 Kubernetes 的最小調(diào)度單元。同一 Pod 中的容器共享網(wǎng)絡(luò)名稱空間和存儲資源，這些容器可經(jīng)由本地回環(huán)接口 lineout 直接通信，但彼此之間又在 Mount、User 及 PID 等名稱空間上保持了隔離。盡管 Pod 中可以包含多個(gè)容器，但是作為最小調(diào)度單元，它應(yīng)該盡可能地保持“小”，即通常只應(yīng)該包含一個(gè)主容器。

Label 資源標(biāo)簽

標(biāo)簽（ Label ）是將資源進(jìn)行分類的標(biāo)識符，資源標(biāo)簽其實(shí)就是一個(gè)鍵值型（ key/values) 數(shù)據(jù)。標(biāo)簽旨在指定對象（如 Pod 等）辨識性的屬性，這些屬性僅對用戶存在特定的意義，對 Kubernetes 集群來說并不直接表達(dá)核心系統(tǒng)語義。標(biāo)簽可以在對象創(chuàng)建時(shí)附加其上，并能夠在創(chuàng)建后的任意時(shí)間進(jìn)行添加和修改。一個(gè)對象可以擁有多個(gè)標(biāo)簽，一個(gè)標(biāo)簽也可以附加于多個(gè)對象（通常是同一類對象）之上

標(biāo)簽選擇器（ Selector ）

標(biāo)簽選擇器（ Selector ）全稱為 " Label Selector" 它是一種根據(jù) Label 來過濾符合條件的資源對象的機(jī)制。 例如，將附有標(biāo)簽“ role:backend ”的所有 Pod 對象挑選出來歸為一組就是標(biāo)簽選擇器的一種應(yīng)用，用戶通常使用標(biāo)簽對資源對象進(jìn)行分類，而后使用標(biāo)簽選擇器挑選出它們，直接批量給挑選出來的資源對象做相應(yīng)的操作。

Pod 控制器

盡管 Pod 是 Kubernetes 的最小調(diào)度單元，但用戶通常并不會直接部署及管理 Pod 對象，而是要借助于另一類抽象——控制器（Controller）對其進(jìn)行管理。 用于工作負(fù)載的控制器是一種管理 Pod 生命周期的資源抽象，它們是 Kubernetes 上的一類對象，而非單個(gè)資源對象，包 括 ReplicationController、ReplicaSet、 Deployment、StatefulSet、Job 等 。 以 Deployment 控制器為例，它負(fù)責(zé)確保指定的 Pod 對象的副本數(shù)量精確符合定義，否則“多退少補(bǔ)”。使用控制器之后就不再需要手動管理 Pod 對象了，用戶只需要聲明應(yīng)用的期望狀態(tài)，控制器就會自動對其進(jìn)行進(jìn)程管理。

服務(wù)資源（ Service )

Service 是建立在一組 Pod 對象之上的資源抽象，它通過標(biāo)簽選擇器選定一組 Pod 對象， 并為這組 Pod 對象定義一個(gè)統(tǒng)一的固定訪問入口（通常是一個(gè) IP 地址），若 Kubernetes 集群存在 DNS 附件，它就會在 Service 創(chuàng)建時(shí)為其自動配置一個(gè) DNS 名稱以便客戶端進(jìn)行服務(wù)發(fā)現(xiàn)。 到達(dá) Service IP 的請求將被負(fù)載均衡至其后的端點(diǎn)——各個(gè) Pod 對象之上，因此 Service 從本質(zhì)上來講是一個(gè)四層代理服務(wù)。 另外， Service 還可以將集群外部流量引入到集群中來 。

存儲卷

存儲卷（ Volume ）是獨(dú)立于容器文件系統(tǒng)之外的存儲空間，常用于擴(kuò)展容器的存儲空間并為它提供持久存儲能力。Kubernetes 集群上的存儲卷大體可分為臨時(shí)卷 、本地卷和網(wǎng)絡(luò)卷。臨時(shí)卷和本地卷都位于 Node 本地，一旦 Pod 被調(diào)度至其他 Node，此種類型的存儲卷將無法訪問到，因此臨時(shí)卷和本地卷通常用于數(shù)據(jù)緩存，持久化的數(shù)據(jù)則需要放置于持久卷 (persistent volume ）之上。

Name 和 Namespace

名稱（ Name ）是 Kubernetes 集群中資源對象的標(biāo)識符，它們的作用域通常是名稱空間( Namespace ）因此名稱空間是名稱的額外的限定機(jī)制。在同一個(gè)名稱空間中，同一類型資源對象的名稱必須具有唯一性。名稱空間通常用于實(shí)現(xiàn)租戶或項(xiàng)目的資源隔離，從而形成邏輯分組。創(chuàng)建資源對象未指定名稱空間時(shí) ，它們都屬于默認(rèn)的名稱空間“ default ” 。

Annotation

Annotation（注解）是另一種附加在對象之上的鍵值類型的數(shù)據(jù)，但它擁有更大的數(shù)據(jù)容量。Annotation常用于將各種非標(biāo)識型元數(shù)據(jù)（ metadata ） 附加到對象上，但它不能用于標(biāo)識和選擇對象，通常也不會被 Kubernetes 直接使用，其主要目的是方便工具或用戶的閱讀及查找等

Ingress

Kubernetes 將 Pod 對象和外部網(wǎng)絡(luò)環(huán)境進(jìn)行了隔離，Pod 和 Service 等對象間的通信都使用其內(nèi)部專用地址進(jìn)行，如若需要開放某些 Pod 對象提供給外部用戶訪問，則需要為其請求流量打開一個(gè)通往 Kubernetes 集群內(nèi)部的通道，除了Service之外，Ingress 也是這類通道的實(shí)現(xiàn)方式之一。

Kubernetes集群組件

一個(gè)典型的 Kubernetes 集群由多個(gè)工作節(jié)點(diǎn)和一個(gè)或多個(gè)Master節(jié)點(diǎn)，以及一個(gè)集群狀態(tài)存儲系統(tǒng)（ etcd ）組成。其中 Master 節(jié)點(diǎn)負(fù)責(zé)整個(gè)集群的管理工作， 為集群提供管理接口，并監(jiān)控和編排集群中的各個(gè)工作節(jié)點(diǎn)。各個(gè)工作節(jié)點(diǎn)負(fù)責(zé)以 Pod 的形式運(yùn)行容器，因此，各節(jié)點(diǎn)需要事先配置好容器運(yùn)行依賴的所有服務(wù)和資源，如容器運(yùn)行時(shí)環(huán)境（比如Docker）。

Master 節(jié)點(diǎn)主要是由 apiserver、 controller-manager 和 scheduler 三個(gè)組件，以及一個(gè)用于集群狀態(tài)存儲的 etcd 存儲服務(wù)組成，而每個(gè) Node 節(jié)點(diǎn)則主要包含 kubelet、kube-proxy 及容器引擎（ Docker是最為常用的實(shí)現(xiàn)）等組件。此外，完整的集群服務(wù)還依賴于一些附加組件，如 KubeDNS、Dashboard、Heapster、Ingress Controller 等。

API Server

API Server 負(fù)責(zé)輸出 RESTful 風(fēng)格的 Kubernetes API ，它是發(fā)往集群的所有 REST 操作命令的接入點(diǎn)，并負(fù)責(zé)接收、校驗(yàn)并響應(yīng)所有的 REST 請求，結(jié)果狀態(tài)被持久存儲于 etcd 中。因此，API Server 是整個(gè)集群的網(wǎng)關(guān)。

集群狀態(tài)存儲（etcd）

Kubernetes 集群的所有狀態(tài)信息都需要持久存儲于存儲系統(tǒng) etcd 中，不過， etcd 是由 CoreOS 基于 Raft 協(xié)議開發(fā)的分布式鍵值存儲，可用于服務(wù)發(fā)現(xiàn)、共享配置以及一致性保障（如數(shù)據(jù)庫主節(jié)點(diǎn)選擇、分布式鎖等）。因此，etcd 是獨(dú)立的服務(wù)組件，并不隸屬于 Kubernetes 集群自身。生產(chǎn)環(huán)境中應(yīng)該以 etcd 集群的方式運(yùn)行以確保其服務(wù)可用性。

etcd 不僅能夠提供鍵值數(shù)據(jù)存儲， 而且還為其提供了監(jiān)昕（ watch ）機(jī)制，用于監(jiān)聽和推送變更。 Kubernetes 集群系統(tǒng)中，etcd 中的鍵值發(fā)生變化時(shí)會通知到 API Server ，并由其通過 watchAPI 向客戶端輸出?；?watch 機(jī)制， Kubernetes 集群的各組件實(shí)現(xiàn)了高效協(xié)同 。

控制器管理器（ Controller Manager )

Kubernetes 中，集群級別的大多數(shù)功能都是由幾個(gè)被稱為控制器的進(jìn)程執(zhí)行實(shí)現(xiàn)的，這幾個(gè)進(jìn)程被集成于 kube-controller-manager 守護(hù)進(jìn)程中。由控制器完成的功能主要包括生命周期功能和 API 業(yè)務(wù)邏輯，具體如下。

• 生命周期功能：包括 Namespace 創(chuàng)建和生命周期、 Event 垃圾回收、 Pod 終止相關(guān)的垃圾回收、級聯(lián)垃圾回收及 Node 垃圾回收等 。
• API業(yè)務(wù)邏輯：例如，由 ReplicaSet 執(zhí)行的 Pod 擴(kuò)展等 。

調(diào)度器（ Scheduler )

Kubernetes 是用于部署和管理大規(guī)模容器應(yīng)用的平臺，根據(jù)集群規(guī)模的不同，其托管運(yùn)行的容器很可能會數(shù)以千計(jì)甚至更多。 API Server 確認(rèn) Pod 對象的創(chuàng)建請求之后， 便需要由 Scheduler 根據(jù)集群內(nèi)各節(jié)點(diǎn)的可用資源狀態(tài)，以及要運(yùn)行的容器的資源需求做出調(diào)度決策。另外，Kubernetes 還支持用戶自定義調(diào)度器

kubelet

kubelet 是運(yùn)行于工作節(jié)點(diǎn)之上的守護(hù)進(jìn)程，它從 API Server 接收關(guān)于 Pod 對象的配置信息并確保它們處于期望的狀態(tài)。 kubelet 會在 API Server 上注冊當(dāng)前工作節(jié)點(diǎn)， 定期向 Master 匯報(bào)節(jié)點(diǎn)資源使用情況，并通過 cAdvisor 監(jiān)控容器和節(jié)點(diǎn)的資源占用狀況 。

容器運(yùn)行時(shí)環(huán)境

每個(gè) Node 都要提供一個(gè)容器運(yùn)行時(shí)（ Container Runtime ）環(huán)境， 它負(fù)責(zé)下載鏡像并運(yùn)行容器。 kubelet 并未固定鏈接至某容器運(yùn)行時(shí)環(huán)境，而是以插件的方式載入配置的容器環(huán)境。這種方式清晰地定義了各組件的邊界。目前，Kubernetes 支持的容器運(yùn)行環(huán)境至少包括Docker、RKT、cri-o 和 Fraki等。

kube-proxy

每個(gè)工作節(jié)點(diǎn)都需要運(yùn)行一個(gè) kube-proxy 守護(hù)進(jìn)程，它能夠按需為 Service 資源對象生成 iptables 或 ipvs 規(guī)則，從而捕獲訪問當(dāng)前 Service 的ClusterIP 的流量并將其轉(zhuǎn)發(fā)至正確的后端 Pod 對象。

KubeDNS

KubeDNS 是在 Kubernetes 集群中調(diào)度運(yùn)行提供 DNS 服務(wù)的 Pod，同一集群中的其他 Pod 可使用此 DNS 服務(wù)解決主機(jī)名。 Kubernetes 自 1.11 版本開始默認(rèn)使用 CoreDNS 項(xiàng)目為集群提供服務(wù)注冊和服務(wù)發(fā)現(xiàn)的動態(tài)名稱解析服務(wù)，之前的版本中用到的是 kube-dns 項(xiàng)目，而 SkyDNS 則是更早一代的項(xiàng)目。

Kubernetes Dashboard

Kubernetes 集群的全部功能都要基于 Web 的 UI，來管理集群中的應(yīng)用甚至是集群自身。

Heapster

容器和節(jié)點(diǎn)的性能監(jiān)控與分析系統(tǒng)，它收集并解析多種指標(biāo)數(shù)據(jù)，如資源利用率、生命周期事件等。新版本的 Kubernetes 中，其功能會逐漸由 Prometheus 結(jié)合其他組件所取代。

Ingress Controller

Service 是一種工作于傳統(tǒng)層的負(fù)載均衡器，而 Ingress 是在應(yīng)用層實(shí)現(xiàn)的 HTTP (s）負(fù)載均衡機(jī)制。不過，Ingress 資源自身并不能進(jìn)行“流量穿透”，它僅是一組路由規(guī)則的集合，這些規(guī)則需要通過 Ingress 控制器（ Ingress Controller) 發(fā)揮作用 。 目前，此類的可用項(xiàng)目有 Nginx、Traefik、Envoy 及 HAProxy 等。