摘要：?在實(shí)踐之前，必須先學(xué)習(xí) Kubernetes 的幾個(gè)重要概念，它們是組成 Kubernetes 集群的基石。
在實(shí)踐之前，必須先學(xué)習(xí) Kubernetes 的幾個(gè)重要概念，它們是組成 Kubernetes 集群的基石。
Cluster
Cluster 是計(jì)算、存儲(chǔ)和網(wǎng)絡(luò)資源的集合，Kubernetes 利用這些資源運(yùn)行各種基于容器的應(yīng)用。
Master
Master 是 Cluster 的大腦，它的主要職責(zé)是調(diào)度，即決定將應(yīng)用放在哪里運(yùn)行。Master 運(yùn)行 Linux 操作系統(tǒng)，可以是物理機(jī)或者虛擬機(jī)。為了實(shí)現(xiàn)高可用，可以運(yùn)行多個(gè) Master。
Node
Node 的職責(zé)是運(yùn)行容器應(yīng)用。Node 由 Master 管理，Node 負(fù)責(zé)監(jiān)控并匯報(bào)容器的狀態(tài)，并根據(jù) Master 的要求管理容器的生命周期。Node 運(yùn)行在 Linux 操作系統(tǒng)，可以是物理機(jī)或者是虛擬機(jī)。
在前面交互式教程中我們創(chuàng)建的 Cluster 只有一個(gè)主機(jī)?host01，
它既是 Master 也是 Node。
Pod
Pod 是 Kubernetes 的最小工作單元。每個(gè) Pod 包含一個(gè)或多個(gè)容器。Pod 中的容器會(huì)作為一個(gè)整體被 Master 調(diào)度到一個(gè) Node 上運(yùn)行。
Kubernetes 引入 Pod 主要基于下面兩個(gè)目的：
可管理性。
有些容器天生就是需要緊密聯(lián)系，一起工作。Pod 提供了比容器更高層次的抽象，將它們封裝到一個(gè)部署單元中。Kubernetes 以 Pod 為最小單位進(jìn)行調(diào)度、擴(kuò)展、共享資源、管理生命周期。
通信和資源共享。
Pod 中的所有容器使用同一個(gè)網(wǎng)絡(luò) namespace，即相同的 IP 地址和 Port 空間。它們可以直接用 localhost 通信。同樣的，這些容器可以共享存儲(chǔ)，當(dāng) Kubernetes 掛載 volume 到 Pod，本質(zhì)上是將 volume 掛載到 Pod 中的每一個(gè)容器。
Pods 有兩種使用方式：
運(yùn)行單一容器。
one-container-per-Pod?是 Kubernetes 最常見的模型，這種情況下，只是將單個(gè)容器簡單封裝成 Pod。即便是只有一個(gè)容器，Kubernetes 管理的也是 Pod 而不是直接管理容器。
運(yùn)行多個(gè)容器。
但問題在于：哪些容器應(yīng)該放到一個(gè) Pod 中？
答案是：這些容器聯(lián)系必須非常緊密，而且需要直接共享資源。
舉個(gè)例子。
下面這個(gè) Pod 包含兩個(gè)容器：一個(gè) File Puller，一個(gè)是 Web Server。
File Puller 會(huì)定期從外部的 Content Manager 中拉取最新的文件，將其存放在共享的 volume 中。Web Server 從 volume 讀取文件，響應(yīng) Consumer 的請求。
這兩個(gè)容器是緊密協(xié)作的，它們一起為 Consumer 提供最新的數(shù)據(jù)；同時(shí)它們也通過 volume 共享數(shù)據(jù)。所以放到一個(gè) Pod 是合適的。
再來看一個(gè)反例：是否需要將 Tomcat 和 MySQL 放到一個(gè) Pod 中？
Tomcat 從 MySQL 讀取數(shù)據(jù)，它們之間需要協(xié)作，但還不至于需要放到一個(gè) Pod 中一起部署，一起啟動(dòng)，一起停止。同時(shí)它們是之間通過 JDBC 交換數(shù)據(jù)，并不是直接共享存儲(chǔ)，所以放到各自的 Pod 中更合適。
Controller
Kubernetes 通常不會(huì)直接創(chuàng)建 Pod，而是通過 Controller 來管理 Pod 的。Controller 中定義了 Pod 的部署特性，比如有幾個(gè)副本，在什么樣的 Node 上運(yùn)行等。為了滿足不同的業(yè)務(wù)場景，Kubernetes 提供了多種 Controller，包括 Deployment、ReplicaSet、DaemonSet、StatefuleSet、Job 等，我們逐一討論。
Deployment是最常用的 Controller，比如前面在線教程中就是通過創(chuàng)建 Deployment 來部署應(yīng)用的。Deployment 可以管理 Pod 的多個(gè)副本，并確保 Pod 按照期望的狀態(tài)運(yùn)行。
ReplicaSet實(shí)現(xiàn)了 Pod 的多副本管理。使用 Deployment 時(shí)會(huì)自動(dòng)創(chuàng)建 ReplicaSet，也就是說 Deployment 是通過 ReplicaSet 來管理 Pod 的多個(gè)副本，我們通常不需要直接使用 ReplicaSet。
DaemonSet用于每個(gè) Node 最多只運(yùn)行一個(gè) Pod 副本的場景。正如其名稱所揭示的，DaemonSet 通常用于運(yùn)行 daemon。
StatefuleSet能夠保證 Pod 的每個(gè)副本在整個(gè)生命周期中名稱是不變的。而其他 Controller 不提供這個(gè)功能，當(dāng)某個(gè) Pod 發(fā)生故障需要?jiǎng)h除并重新啟動(dòng)時(shí)，Pod 的名稱會(huì)發(fā)生變化。同時(shí) StatefuleSet 會(huì)保證副本按照固定的順序啟動(dòng)、更新或者刪除。
Job用于運(yùn)行結(jié)束就刪除的應(yīng)用。而其他 Controller 中的 Pod 通常是長期持續(xù)運(yùn)行。
Service
Deployment 可以部署多個(gè)副本，每個(gè) Pod 都有自己的 IP，外界如何訪問這些副本呢？
通過 Pod 的 IP 嗎？
要知道 Pod 很可能會(huì)被頻繁地銷毀和重啟，它們的 IP 會(huì)發(fā)生變化，用 IP 來訪問不太現(xiàn)實(shí)。
答案是 Service。
Kubernetes Service 定義了外界訪問一組特定 Pod 的方式。Service 有自己的 IP 和端口，Service 為 Pod 提供了負(fù)載均衡。
Kubernetes 運(yùn)行容器（Pod）與訪問容器（Pod）這兩項(xiàng)任務(wù)分別由 Controller 和 Service 執(zhí)行。
Namespace
如果有多個(gè)用戶或項(xiàng)目組使用同一個(gè) Kubernetes Cluster，如何將他們創(chuàng)建的 Controller、Pod 等資源分開呢？
答案就是 Namespace。
Namespace 可以將一個(gè)物理的 Cluster 邏輯上劃分成多個(gè)虛擬 Cluster，每個(gè) Cluster 就是一個(gè) Namespace。不同 Namespace 里的資源是完全隔離的。
Kubernetes 默認(rèn)創(chuàng)建了兩個(gè) Namespace。
default?-- 創(chuàng)建資源時(shí)如果不指定，將被放到這個(gè) Namespace 中。
kube-system?-- Kubernetes 自己創(chuàng)建的系統(tǒng)資源將放到這個(gè) Namespace 中。
熟悉了 k8s 的這些重要概念，下節(jié)開始，我們將搭建自己的 Kubernetes 集群。
書籍：
1.《每天5分鐘玩轉(zhuǎn)Docker容器技術(shù)》
https://item.jd.com/16936307278.html
2.《每天5分鐘玩轉(zhuǎn)OpenStack》
https://item.jd.com/12086376.html
版權(quán)聲明：本文內(nèi)容由互聯(lián)網(wǎng)用戶自發(fā)貢獻(xiàn)，版權(quán)歸作者所有，本社區(qū)不擁有所有權(quán)，也不承擔(dān)相關(guān)法律責(zé)任。如果您發(fā)現(xiàn)本社區(qū)中有涉嫌抄襲的內(nèi)容，歡迎發(fā)送郵件至：yqgroup@service.aliyun.com?進(jìn)行舉報(bào)，并提供相關(guān)證據(jù)，一經(jīng)查實(shí)，本社區(qū)將立刻刪除涉嫌侵權(quán)內(nèi)容。
