Kubernetes 集群基本概念

什么是 Kubernetes ？

Kubernetes 基本概念

集群 Cluster

節(jié)點 Node

命名空間 Namespace

容器 Container

調(diào)度單位 Pod

標(biāo)簽 Label/Selector

副本集 ReplicaSet

服務(wù) Service

發(fā)布 Deployment

配置管理 ConfigMap/Secret

守護(hù)進(jìn)程 DaemonSet

數(shù)據(jù)卷 Volume

PersistentVolume/PersistentVolumeClaims

StatefulSet

Job/CronJob

Readiness Probe（就緒探針）

Liveness Probe（存活探針）

什么是 Kubernetes ？

Kubernetes 基本概念

集群 Cluster

節(jié)點 Node

命名空間 Namespace

容器 Container

調(diào)度單位 Pod

標(biāo)簽 Label/Selector

副本集 ReplicaSet

服務(wù) Service

發(fā)布 Deployment

配置管理 ConfigMap/Secret

守護(hù)進(jìn)程 DaemonSet

數(shù)據(jù)卷 Volume

PersistentVolume/PersistentVolumeClaims

StatefulSet

Job/CronJob

Readiness Probe（就緒探針）

Liveness Probe（存活探針）

小結(jié)

什么是 Kubernetes ？

Kubernetes 是一個可以移植、可擴(kuò)展的開源平臺，使用聲明式的配置并依據(jù)配置信息自動地執(zhí)行容器化應(yīng)用程序的管理。在所有的容器編排工具中（類似的還有 docker swarm / mesos等），Kubernetes 的生態(tài)系統(tǒng)更大、增長更快，有更多的支持、服務(wù)和工具可供用戶選擇。

Kubernetes 的名字起源于希臘語，含義是 舵手、領(lǐng)航員、向?qū)Аoogle 于 2014 年將 Brog 系統(tǒng)開源為 Kubernetes。Kubernetes 構(gòu)建在 Google Brog 十五年運行大規(guī)模分布式系統(tǒng)的經(jīng)驗基礎(chǔ)之上，并結(jié)合了開源社區(qū)最好的想法和實踐。

以下是使用近三年中國地區(qū) google trends 對比 kubernetes 、 docker swarm、 mesos 三個關(guān)鍵詞的截圖：

Kubernetes 基本概念

集群 Cluster

超大計算機抽象，由節(jié)點組成，這些節(jié)點可以是物理服務(wù)器或者虛擬機，在上面安裝了 Kubernetes 平臺。

節(jié)點 Node

Node（節(jié)點）是 kubernetes 集群中的計算機，可以是虛擬機或物理機。每個 Node（節(jié)點）都由 master 管理。一個 Node（節(jié)點）可以有多個Pod（容器組），kubernetes master 會根據(jù)每個 Node（節(jié)點）上可用資源的情況，自動調(diào)度 Pod（容器組）到最佳的 Node（節(jié)點）上。

每個 Kubernetes Node（節(jié)點）至少運行：

Kubelet，負(fù)責(zé) master 節(jié)點和 worker 節(jié)點之間通信的進(jìn)程；管理 Pod（容器組）和 Pod（容器組）內(nèi)運行的 Container（容器）。

容器運行環(huán)境（如Docker）負(fù)責(zé)下載鏡像、創(chuàng)建和運行容器等。

命名空間 Namespace

Namespace（命名空間）是對一組資源和對象的抽象集合，Kubernetes 資源邏輯的隔離機制，比如可以用來將系統(tǒng)內(nèi)部的對象劃分為不同的項目組或用戶組。常見的 Pods、Services、Deployments 等都是屬于某一個 Namespace 的（默認(rèn)是default），比如 Nginx Pod 沒有指定 namespace，則默認(rèn)就在 default 命名空間下面，而 Node, PersistentVolumes 等資源則不屬于任何 Namespace，是全局的。

注意它并不是 Linux Namespace，二者沒有任何關(guān)系，它只是 Kubernetes 劃分不同工作空間的一個邏輯單位。

容器 Container

應(yīng)用居住和運行在容器中，容器實際上是一個 Linux Namespace、Linux Cgroups 和 rootfs 三種技術(shù)構(gòu)造出來的進(jìn)程的隔離環(huán)境。

容器的靜態(tài)視圖：一組聯(lián)合掛載在 /var/lib/docker/… 上的 rootfs，即 “容器鏡像” Container Image。

容器的動態(tài)視圖：一個由 Namespace 和 Cgroup 構(gòu)成的隔離環(huán)境，即 “容器運行時” Container Runtime。

作為一個測試者，不關(guān)心容器運行時，容器鏡像才是真正承載容器信息進(jìn)程傳遞的。容器編排由此出現(xiàn)，容器從此走向容器云。

調(diào)度單位 Pod

Kubernetes 的基本調(diào)度單位，Pod 是一組緊密關(guān)聯(lián)的容器集合，它們共享 PID、IPC、Network 和 UTS namespace。Pod 的設(shè)計理念是支持多個容器在一個 Pod 中共享網(wǎng)絡(luò)和文件系統(tǒng)，可以通過進(jìn)程間通信和文件共享這種簡單高效的方式組合完成服務(wù)。我們知道容器本質(zhì)上就是進(jìn)程，那么 Pod 實際上就是進(jìn)程組了，只是這一組進(jìn)程是作為一個整體來進(jìn)行調(diào)度的。

標(biāo)簽 Label/Selector

Kubernetes 資源打標(biāo)簽和定位機制，Label 標(biāo)簽在 Kubernetes 資源對象中使用很多，也是非常重要的一個屬性，Label 是識別 Kubernetes 對象的標(biāo)簽，以 key/value 的方式附加到對象上（key最長不能超過63字節(jié)，value 可以為空，也可以是不超過253字節(jié)的字符串）。Label 不提供唯一性，并且實際上經(jīng)常是很多對象（如Pods）都使用相同的 Label 來標(biāo)志具體的應(yīng)用。Label 定義好后其他對象可以使用 Label Selector 來選擇一組相同 Label 的對象（比如 Service 用 Label 來選擇一組 Pod）。

Label Selector 支持以下幾種方式：

等式，如：app=webapp 和 env!=prod

集合，如：env in (prod, test)

多個 Label（它們之間是 AND 關(guān)系），如：app=webapp,env=prod，,version=v2

副本集 ReplicaSet

手動創(chuàng)建 Pod，如果想要創(chuàng)建同一個容器的多份拷貝，需要一個個分別創(chuàng)建出來么，能否將 Pods 劃到邏輯組里？

主要用于創(chuàng)建和管理 Pod，支持無狀態(tài)應(yīng)用，ReplicaSet 確保任意時間都有指定數(shù)量的 Pod “副本”在運行。如為某個 Pod 創(chuàng)建了 ReplicaSet 并且指定 3 個副本，它會創(chuàng)建 3 個Pod，并且持續(xù)監(jiān)控它們。如果某個 Pod 不響應(yīng)，那么 ReplicaSet 會替換它，保持總數(shù)為 3：

服務(wù) Service

應(yīng)用 Pods 的訪問點，屏蔽 IP 尋址和負(fù)載均衡，具體上說 Service 是應(yīng)用服務(wù)的抽象，通過 Labels 為應(yīng)用提供負(fù)載均衡和服務(wù)發(fā)現(xiàn)。匹配 Labels 的 Pod IP 和端口列表組成 Endpoints，由 kube-proxy 負(fù)責(zé)將服務(wù) IP 負(fù)載均衡到這些 Endpoints 上。

每個 Service 都會自動分配一個 cluster IP（僅在集群內(nèi)部可訪問的虛擬地址）和 DNS 名，其他容器可以通過該地址或 DNS 來訪問服務(wù)，而不需要了解后端容器的運行。

發(fā)布 Deployment

Deployment 管理 ReplicaSet，支持滾動等高級發(fā)布機制，Deployment 確保任意時間都有指定數(shù)量的 Pod“副本”在運行。如果為某個 Pod 創(chuàng)建了 Deployment 并且指定 3 個副本，它會創(chuàng)建3 個 Pod，并且持續(xù)監(jiān)控它們。如果某個 Pod 不響應(yīng)，那么 Deployment 會替換它，始終保持總數(shù)為 3 。

如果之前不響應(yīng)的 Pod 恢復(fù)了，現(xiàn)在就有 4 個 Pod 了，那么 Deployment 會將其中一個終止保持總數(shù)為 3。如果在運行中將副本總數(shù)改為 5，Deployment 會立刻啟動 2 個新 Pod，保證總數(shù)為 5。保持回滾和滾動升級。

當(dāng)創(chuàng)建 Deployment 時，需要指定兩個東西：

Pod 模板：用來創(chuàng)建 Pod 副本的模板；

Label 標(biāo)簽：Deployment 需要監(jiān)控的 Pod 的標(biāo)簽。

配置管理 ConfigMap/Secret

日常一個重要的需求就是應(yīng)用的配置管理、敏感信息的存儲和使用（如：密碼、Token 等）、容器運行資源的配置、安全管控、身份認(rèn)證等等。

對于應(yīng)用的可變配置在 Kubernetes 中是通過一個 ConfigMap 資源對象來實現(xiàn)的，我們知道許多應(yīng)用經(jīng)常會有從配置文件、命令行參數(shù)或者環(huán)境變量中讀取一些配置信息的需求，這些配置信息我們肯定不會直接寫死到應(yīng)用程序中去的，比如你一個應(yīng)用連接一個 redis 服務(wù)，下一次想更換一個了的，還得重新去修改代碼，重新制作一個鏡像，這肯定是不可取的，而 ConfigMap 就給我們提供了向容器中注入配置信息的能力，不僅可以用來保存單個屬性，還可以用來保存整個配置文件，比如我們可以用來配置一個 redis 服務(wù)的訪問地址，也可以用來保存整個 redis 的配置文件。

一般情況下 ConfigMap 是用來存儲一些非安全的配置信息，如果涉及到一些安全相關(guān)的數(shù)據(jù)的話用 ConfigMap 就非常不妥了，因為 ConfigMap 是明文存儲的，這個時候我們就需要用到另外一個資源對象了：Secret，Secret 用來保存敏感信息，例如密碼、OAuth 令牌和 ssh key 等等，將這些信息放在 Secret 中比放在 Pod 的定義中或者 Docker 鏡像中要更加安全和靈活。

守護(hù)進(jìn)程 DaemonSet

DaemonSet 用于在每個 Kubernetes 節(jié)點中將守護(hù)進(jìn)程的副本作為后臺進(jìn)程運行，說簡單點就是在每個節(jié)點部署一個 Pod 副本，當(dāng)節(jié)點加入到 Kubernetes 集群中，Pod 會被調(diào)度到該節(jié)點上運行，當(dāng)節(jié)點從集群只能夠被移除后，該節(jié)點上的這個 Pod 也會被移除，當(dāng)然，如果我們刪除 DaemonSet，所有和這個對象相關(guān)的 Pods 都會被刪除。

那么在哪種情況下我們會需要用到這種業(yè)務(wù)場景呢？其實這種場景還是比較普通的，比如：

集群存儲守護(hù)程序，如 glusterd、ceph 要部署在每個節(jié)點上以提供持久性存儲；

節(jié)點監(jiān)控守護(hù)進(jìn)程，如 Prometheus 監(jiān)控集群，可以在每個節(jié)點上運行一個 node-exporter 進(jìn)程來收集監(jiān)控節(jié)點的信息；

日志收集守護(hù)程序，如 fluentd 或 logstash，在每個節(jié)點上運行以收集容器的日志；

節(jié)點網(wǎng)絡(luò)插件，比如 flannel、calico，在每個節(jié)點上運行為 Pod 提供網(wǎng)絡(luò)服務(wù)。

數(shù)據(jù)卷 Volume

Kubernetes Volume（數(shù)據(jù)卷）主要解決了如下兩方面問題：

數(shù)據(jù)持久性：通常情況下，容器運行起來之后，寫入到其文件系統(tǒng)的文件暫時性的。當(dāng)容器崩潰后，kubelet 將會重啟該容器，此時原容器運行后寫入的文件將丟失，因為容器將重新從鏡像創(chuàng)建；

數(shù)據(jù)共享：同一個 Pod（容器組）中運行的容器之間，經(jīng)常會存在共享文件/文件夾的需求。

Docker 里同樣也存在一個 volume（數(shù)據(jù)卷）的概念，但是 docker 對數(shù)據(jù)卷的管理相對 kubernetes 而言要更少一些。在 Docker 里，一個 Volume（數(shù)據(jù)卷）僅僅是宿主機（或另一個容器）文件系統(tǒng)上的一個文件夾。Docker 并不管理 Volume（數(shù)據(jù)卷）的生命周期。

在 Kubernetes 里，Volume（數(shù)據(jù)卷）存在明確的生命周期（與包含該數(shù)據(jù)卷的容器組相同）。因此，Volume（數(shù)據(jù)卷）的生命周期比同一容器組中任意容器的生命周期要更長，不管容器重啟了多少次，數(shù)據(jù)都能被保留下來。當(dāng)然，如果容器組退出了，數(shù)據(jù)卷也就自然退出了。此時，根據(jù)容器組所使用的 Volume（數(shù)據(jù)卷）類型不同，數(shù)據(jù)可能隨數(shù)據(jù)卷的退出而刪除，也可能被真正持久化，并在下次容器組重啟時仍然可以使用。

從根本上來說，一個 Volume（數(shù)據(jù)卷）僅僅是一個可被容器組中的容器訪問的文件目錄（也許其中包含一些數(shù)據(jù)文件）。這個目錄是怎么來的，取決于該數(shù)據(jù)卷的類型（不同類型的數(shù)據(jù)卷使用不同的存儲介質(zhì)）。

使用 Volume（數(shù)據(jù)卷）時，我們需要先在容器組中定義一個數(shù)據(jù)卷，并將其掛載到容器的掛載點上。容器中的一個進(jìn)程所看到（可訪問）的文件系統(tǒng)是由容器的 docker 鏡像和容器所掛載的數(shù)據(jù)卷共同組成的。Docker 鏡像將被首先加載到該容器的文件系統(tǒng)，任何數(shù)據(jù)卷都被在此之后掛載到指定的路徑上。Volume（數(shù)據(jù)卷）不能被掛載到其他數(shù)據(jù)卷上，或者通過引用其他數(shù)據(jù)卷。同一個容器組中的不同容器各自獨立地掛載數(shù)據(jù)卷，即同一個容器組中的兩個容器可以將同一個數(shù)據(jù)卷掛載到各自不同的路徑上。

我們現(xiàn)在通過下圖來理解 容器組、容器、掛載點、數(shù)據(jù)卷、存儲介質(zhì)（nfs、PVC、ConfigMap）等幾個概念之間的關(guān)系：

一個容器組可以包含多個數(shù)據(jù)卷、多個容器；

一個容器通過掛載點決定某一個數(shù)據(jù)卷被掛載到容器中的什么路徑；

不同類型的數(shù)據(jù)卷對應(yīng)不同的存儲介質(zhì)（圖中列出了 nfs、PVC、ConfigMap 三種存儲介質(zhì)）。

PersistentVolume/PersistentVolumeClaims

Kubernetes 超大磁盤存儲抽象和分配機制。

PersistentVolume（持久化卷）簡稱為 PV ，是對底層共享存儲的一種抽象，PV 由管理員進(jìn)行創(chuàng)建和配置，它和具體的底層的共享存儲技術(shù)的實現(xiàn)方式有關(guān)，比如 Ceph、GlusterFS、NFS、hostPath 等，都是通過插件機制完成與共享存儲的對接。

PersistentVolumeClaim（持久化卷聲明）簡稱為 PVC ，PVC 是用戶存儲的一種聲明，PVC 和 Pod 比較類似，Pod 消耗的是節(jié)點，PVC 消耗的是 PV 資源，Pod 可以請求 CPU 和內(nèi)存，而 PVC 可以請求特定的存儲空間和訪問模式。對于真正使用存儲的用戶不需要關(guān)心底層的存儲實現(xiàn)細(xì)節(jié)，只需要直接使用 PVC 即可。

通過 PVC 請求到一定的存儲空間也很有可能不足以滿足應(yīng)用對于存儲設(shè)備的各種需求，而且不同的應(yīng)用程序?qū)τ诖鎯π阅艿囊罂赡芤膊槐M相同，比如讀寫速度、并發(fā)性能等，為了解決這一問題，Kubernetes 又為我們引入了一個新的資源對象：StorageClass，通過 StorageClass 的定義，管理員可以將存儲資源定義為某種類型的資源，比如快速存儲、慢速存儲等，用戶根據(jù) StorageClass 的描述就可以非常直觀的知道各種存儲資源的具體特性了，這樣就可以根據(jù)應(yīng)用的特性去申請合適的存儲資源了，此外 StorageClass 還可以為我們自動生成 PV，免去了每次手動創(chuàng)建的麻煩。

StatefulSet

類似 ReplicaSet，支持有狀態(tài)應(yīng)用。無狀態(tài)服務(wù)利用我們前面的 Deployment 可以很好的進(jìn)行編排，對應(yīng)有狀態(tài)服務(wù)，需要考慮的細(xì)節(jié)就要多很多了，容器化應(yīng)用程序最困難的任務(wù)之一，就是設(shè)計有狀態(tài)分布式組件的部署體系結(jié)構(gòu)。由于無狀態(tài)組件沒有預(yù)定義的啟動順序、集群要求、點對點 TCP 連接、唯一的網(wǎng)絡(luò)標(biāo)識符、正常的啟動和終止要求等，因此可以很容易地進(jìn)行容器化。諸如數(shù)據(jù)庫，大數(shù)據(jù)分析系統(tǒng)，分布式 key/value 存儲、消息中間件需要有復(fù)雜的分布式體系結(jié)構(gòu)，都可能會用到上述功能。

為此，Kubernetes 引入了 StatefulSet 這種資源對象來支持這種復(fù)雜的需求。StatefulSet 類似于 ReplicaSet，但是它可以處理 Pod 的啟動順序，為保留每個 Pod 的狀態(tài)設(shè)置唯一標(biāo)識，具有以下幾個功能特性：

穩(wěn)定的、唯一的網(wǎng)絡(luò)標(biāo)識符

穩(wěn)定的、持久化的存儲

有序的、優(yōu)雅的部署和縮放

有序的、優(yōu)雅的刪除和終止

有序的、自動滾動更新

Job/CronJob

運行一次就結(jié)束的任務(wù)/周期性運行的任務(wù)。

我們在日常的工作中經(jīng)常都會遇到一些需要進(jìn)行批量數(shù)據(jù)處理和分析的需求，當(dāng)然也會有按時間來進(jìn)行調(diào)度的工作，在我們的 Kubernetes 集群中為我們提供了 Job 和 CronJob 兩種資源對象來應(yīng)對我們的這種需求。

Job 負(fù)責(zé)處理任務(wù)，即僅執(zhí)行一次的任務(wù)，它保證批處理任務(wù)的一個或多個 Pod 成功結(jié)束。而 CronJob 則就是在 Job 上加上了時間調(diào)度。

Readiness Probe（就緒探針）

有了活性探針后能保證程序在運行中如果掛掉能夠自動重啟，但是還有個經(jīng)常遇到的問題，比如說，在 Kubernetes 中啟動 Pod，顯示明明 Pod 已經(jīng)啟動成功，且能訪問里面的端口，但是卻返回錯誤信息。還有就是在執(zhí)行滾動更新時候，總會出現(xiàn)一段時間，Pod 對外提供網(wǎng)絡(luò)訪問，但是訪問卻發(fā)生 404，這兩個原因，都是因為 Pod 已經(jīng)成功啟動，但是 Pod 的的容器中應(yīng)用程序還在啟動中導(dǎo)致，考慮到這點 Kubernetes 推出了就緒探針機制。

就緒探針，流量接入 Pod 判斷依據(jù)， 用于判斷容器中應(yīng)用是否啟動完成，當(dāng)探測成功后才使 Pod 對外提供網(wǎng)絡(luò)訪問，設(shè)置容器 Ready 狀態(tài)為 true，如果探測失敗，則設(shè)置容器的 Ready 狀態(tài)為 false。對于被 Service 管理的 Pod，Service 與 Pod、EndPoint 的關(guān)聯(lián)關(guān)系也將基于 Pod 是否為 Ready 狀態(tài)進(jìn)行設(shè)置，如果 Pod 運行過程中 Ready 狀態(tài)變?yōu)?false，則系統(tǒng)自動從 Service 關(guān)聯(lián)的 EndPoint 列表中移除，如果 Pod 恢復(fù)為 Ready 狀態(tài)。將再會被加回 Endpoint 列表。通過這種機制就能防止將流量轉(zhuǎn)發(fā)到不可用的 Pod 上。

Liveness Probe（存活探針）

在 Kubernetes 中 Pod 是最小的計算單元，而一個 Pod 又由多個容器組成，相當(dāng)于每個容器就是一個應(yīng)用，應(yīng)用在運行期間，可能因為某也意外情況致使程序掛掉。那么如何監(jiān)控這些容器狀態(tài)穩(wěn)定性，保證服務(wù)在運行期間不會發(fā)生問題，發(fā)生問題后進(jìn)行重啟等機制，就成為了重中之重的事情，考慮到這點 kubernetes 推出了存活探針機制。

存活探針，是否 kill Pod 的判斷依據(jù) ，用指定的方式進(jìn)入容器檢測容器中的應(yīng)用是否正常運行，如果檢測失敗，則認(rèn)為容器不健康，那么 Kubelet 將根據(jù) Pod 中設(shè)置的 restartPolicy （重啟策略）來判斷，Pod 是否要進(jìn)行重啟操作，如果容器配置中沒有配置 livenessProbe 存活探針，Kubelet 將認(rèn)為存活探針探測一直為成功狀態(tài)。

小結(jié)

以上，下表做個基本概念總結(jié)：

Docker Kubernetes Node.js

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實后本網(wǎng)站將在24小時內(nèi)刪除侵權(quán)內(nèi)容。