這個(gè)問題既然是向非技術(shù)人員介紹kubernetes。這里第一個(gè)想到的就是比喻法。畢竟kubernetes涉及到很多操作系統(tǒng)，網(wǎng)絡(luò)的知識，想一點(diǎn)相關(guān)知識不捎帶又介紹清楚kubernetes，著實(shí)有些難。

先拋一張kubernetes架構(gòu)圖，參照這個(gè)咱們分解來說。見下圖。

我理解中的Kubernetes，可以看作一個(gè)公交樞紐站(不是普通的公交站喲)。其作用是統(tǒng)一的調(diào)度管理各路公交車的運(yùn)營。

集群：一個(gè)公交樞紐站可以看做是一個(gè)kubernetes集群

Master：作為kubernetes的大腦，負(fù)責(zé)整個(gè)kubernetes集群的管理。其中有三個(gè)核心組件，既三個(gè)核心部門。

apiserver：作為總控，相當(dāng)于樞紐站的總控制臺。可以理解為管理樞紐站的方方面面。比如門衛(wèi)室，廣播站，購票大廳等等。

controller-manager：在kubernetes中提供多種控制器，管理集群各個(gè)資源。既公交樞紐站的具體職權(quán)部門。比如一路里應(yīng)該有幾個(gè)公交車等

Scheduler:kubernetes負(fù)責(zé)資源調(diào)度。既具體的調(diào)度部門，比如這個(gè)樞紐站中，某個(gè)分站臺需要維修，需要把這個(gè)站臺上停靠的車輛調(diào)到其他站臺。這就是它做的事。當(dāng)然不止這些。

Node：kubernetes中各個(gè)子節(jié)點(diǎn)，各資源項(xiàng)會具體的部署在各節(jié)點(diǎn)上。這里包括幾個(gè)關(guān)鍵概念：

Kubelet：各節(jié)點(diǎn)在集群中與apiserver通信的出入口，處理master下發(fā)到本節(jié)點(diǎn)的任務(wù)，并定期向master匯報(bào)節(jié)點(diǎn)的情況。在這個(gè)樞紐站中。類似于每個(gè)分站臺的控制臺。只關(guān)注自己分站臺的情況，并與總控保持聯(lián)系。

Kubeproxy：這是一個(gè)提供負(fù)載均衡和服務(wù)發(fā)現(xiàn)的組件。其功能多與service綁定。可以理解為，對每路公車發(fā)送的信息。由它制定分發(fā)規(guī)則進(jìn)行發(fā)送。新加入的公車。由它負(fù)責(zé)注冊到service中。

Pod：每一輛公交車可以看做一個(gè)pod，這是kubernetes中的基本資源單位。每一個(gè)乘客可以看做是一個(gè)容器。一輛車上可以有多個(gè)乘客。但不管有幾個(gè)乘客，都必須有一個(gè)司機(jī)，既pause容器。

Deployment:每一路公車都會之前有一輛公車，如789路。一定不值一輛車，這些車都運(yùn)行同樣的路線，完成同樣的功能。就如同deployment，可以部署一類實(shí)例多個(gè)副本。

Service：這是kubernetes中一個(gè)抽象概念。可以這樣比喻。本來某一路下所有的公車副本，應(yīng)該都停靠在一個(gè)分站臺下。但由于站臺位置有限，有一部分車停在了其他分站臺。這時(shí)候，總控臺需要對這一路下的所有車進(jìn)行管理。該怎么辦呢？總控臺將這一路車定義為一個(gè)service，并建立一個(gè)通信的頻道。通過這個(gè)頻道，實(shí)現(xiàn)對這一路車的負(fù)載均衡，調(diào)度管理。車該往哪停，車與車之間通信，都可以通過這個(gè)service。