Kubernetes的詳細(xì)介紹

本篇內(nèi)容主要講解“Kubernetes的詳細(xì)介紹”，感興趣的朋友不妨來(lái)看看。本文介紹的方法操作簡(jiǎn)單快捷，實(shí)用性強(qiáng)。下面就讓小編來(lái)帶大家學(xué)習(xí)“Kubernetes的詳細(xì)介紹”吧!

Kubernetes 的 11 個(gè)部分

1. Pod

Pod 是 Kubernetes 中最小的可互動(dòng)單元。一個(gè) Pod 可以由多個(gè)容器組成，這些容器共同部署在單個(gè)節(jié)點(diǎn)上形成一個(gè)單元。一個(gè) Pod 具有一個(gè) IP，該 IP 在其容器之間共享。

在微服務(wù)世界中，一個(gè) Pod 可以是執(zhí)行后臺(tái)工作或服務(wù)請(qǐng)求的微服務(wù)的單個(gè)實(shí)例。

2. Node（節(jié)點(diǎn)）

Node 是機(jī)器。它們是 Kubernetes 用于部署 Pod 的“裸機(jī)”（或虛擬機(jī)）。Node 為 Kubernetes 提供可用的集群資源用于以保持?jǐn)?shù)據(jù)、運(yùn)行作業(yè)、維護(hù)工作負(fù)載、創(chuàng)建網(wǎng)絡(luò)路由等。

3. Label（標(biāo)簽）與 Annotation（注解）

Label 是 Kubernetes 及其最終用戶用于過(guò)濾系統(tǒng)中相似資源的方式，也是資源與資源相互“訪問(wèn)”或關(guān)聯(lián)的粘合劑。比如說(shuō)，為 Deployment 打開端口的 Service。不論是監(jiān)控、日志、調(diào)試或是測(cè)試，任何 Kubernetes 資源都應(yīng)打上標(biāo)簽以供后續(xù)查驗(yàn)。例如，給系統(tǒng)中所有 Worker Pod 打上標(biāo)簽：app=worker，之后即可在 kubectl 或 Kubernetes API 中使用 --selector 字段對(duì)其進(jìn)行選擇。

Annotation 與 Label 非常相似，但通常用于以自由的字符串形式保存不同對(duì)象的元數(shù)據(jù)，例如“更改原因: 安全補(bǔ)丁升級(jí)”。

4. Service Discovery（服務(wù)發(fā)現(xiàn)）

作為編排系統(tǒng)，Kubernetes 控制著不同工作負(fù)載的眾多資源，負(fù)責(zé)管理 Pod、作業(yè)及所有需要通信的物理資源的網(wǎng)絡(luò)。為此，Kubernetes 使用了 ETCD。

ETCD 是 Kubernetes 的“內(nèi)部”數(shù)據(jù)庫(kù)，Master 通過(guò)它來(lái)獲取所有資源的位置。Kubernetes 還為服務(wù)提供了實(shí)際的“服務(wù)發(fā)現(xiàn)”——所有 Pod 使用了一個(gè)自定義的 DNS 服務(wù)器，通過(guò)解析其他服務(wù)的名稱以獲取其 IP 地址和端口。它在 Kubernetes 集群中“開箱即用”，無(wú)須進(jìn)行設(shè)置。

5. ReplicaSet（副本集）

雖然 Pod 是一個(gè)物理性的運(yùn)行任務(wù)，但通常使用單個(gè)實(shí)例是不夠的。為了冗余并處理負(fù)載，出于某種原因（比如“伸縮”）需要對(duì) Pod 進(jìn)行復(fù)制。為了實(shí)現(xiàn)負(fù)責(zé)擴(kuò)展和復(fù)制的層，Kubernetes 使用了 ReplicaSet。這個(gè)層以副本的數(shù)量表示系統(tǒng)的期望狀態(tài)，并在任意給定時(shí)刻保持該系統(tǒng)的當(dāng)前狀態(tài)。

這也是配置自動(dòng)伸縮的所在，在系統(tǒng)高負(fù)載時(shí)創(chuàng)建額外的副本，并在不再需要這些資源來(lái)支撐所運(yùn)行的工作負(fù)載時(shí)進(jìn)行縮容。

6. DaemonSet（守護(hù)進(jìn)程集）

有時(shí)候，應(yīng)用程序每個(gè)節(jié)點(diǎn)需要的實(shí)例不超過(guò)一個(gè)。比如 FileBeat 這類日志收集器就是個(gè)很好的例子。為了從各個(gè)節(jié)點(diǎn)收集日志，其代理需要運(yùn)行在所有節(jié)點(diǎn)上，但每個(gè)節(jié)點(diǎn)只需要一個(gè)實(shí)例。Kubernetes 的 DaemonSet 即可用于創(chuàng)建這樣的工作負(fù)載。

7. StatefulSet（有狀態(tài)集）

盡管多數(shù)微服務(wù)涉及的都是不可變的無(wú)狀態(tài)應(yīng)用程序，但也有例外。有狀態(tài)的工作負(fù)載有賴于磁盤卷的可靠支持。雖然應(yīng)用程序容器本身可以是不可變的，可以使用更新的版本或更健康的實(shí)例來(lái)替代，但是所有副本還是需要數(shù)據(jù)的持久化。StatefulSet 即是用于這類需要在整個(gè)生命周期內(nèi)使用同一節(jié)點(diǎn)的應(yīng)用程序的部署。

它還保留了它的“名稱”：容器內(nèi)的 hostname 以及整個(gè)集群中服務(wù)發(fā)現(xiàn)的名稱。3 個(gè) ZooKeeper 構(gòu)成的 StatefulSet 可以被命名 zk-1、zk-2 及 zk-3，也可以擴(kuò)展到更多的成員 zk-4、zk-5 等等…… StatefulSets 還負(fù)責(zé)管理 PersistentVolumeClaim（Pod 上連接的磁盤）。

8. Job（任務(wù)）

Kubernetes 核心團(tuán)隊(duì)考慮了大部分使用編排系統(tǒng)的應(yīng)用程序。雖然多數(shù)應(yīng)用程序要求持續(xù)運(yùn)行以同時(shí)處理服務(wù)器請(qǐng)求（比如 Web 服務(wù)器），但有時(shí)還是需要生成一批作業(yè)并在其完成后進(jìn)行清理。比如，一個(gè)迷你的無(wú)服務(wù)器環(huán)境。

為了在 Kubernetes 中實(shí)現(xiàn)這一點(diǎn)，可以使用 Job 資源。正如其名，Job 的工作是生成容器來(lái)完成特定的工作，并在成功完成時(shí)銷毀。舉個(gè)例子，一組 Worker 從待處理和存儲(chǔ)的數(shù)據(jù)隊(duì)列中讀取作業(yè)。一旦隊(duì)列空了，就不再需要這些 Worker 了，直到下個(gè)批次準(zhǔn)備好。

9. ConfigMap（配置映射）及 Secret（機(jī)密配置）

如果你還不熟悉十二要素應(yīng)用清單，請(qǐng)先行了解?，F(xiàn)代應(yīng)用程序的一個(gè)關(guān)鍵概念是無(wú)環(huán)境，并可通過(guò)注入的環(huán)境變量進(jìn)行配置。應(yīng)用程序應(yīng)與其位置完全無(wú)關(guān)。為了在 Kubernetes 中實(shí)現(xiàn)這個(gè)重要的概念，就有了 ConfigMap。實(shí)際上這是一個(gè)環(huán)境變量鍵值列表，它們會(huì)被傳遞給正在運(yùn)行的工作負(fù)載以確定不同的運(yùn)行時(shí)行為。在同樣的范疇下，Secret 與正常的配置條目類似，只是會(huì)進(jìn)行加密以防類似密鑰、密碼、證書等敏感信息的泄漏。

我個(gè)人認(rèn)為 Hashicorp 的 Vault 是使用機(jī)密配置的最佳方案。請(qǐng)務(wù)必閱讀一下我去年寫的有關(guān)文章，文章講述了將 Vault 作為生產(chǎn)環(huán)境一部分的原因，以及我的一位同事寫的另一篇更技術(shù)性的文章。

10. Deployment（部署）

一切看起來(lái)都很美好，Pod 可以正常運(yùn)行，如果上層有 ReplicaSet，還可以根據(jù)負(fù)載進(jìn)行伸縮。不過(guò)，大家蜂擁而來(lái)，為的是能用新版本快速替換應(yīng)用程序。我們想小規(guī)模地進(jìn)行構(gòu)建、測(cè)試和發(fā)布，以縮短反饋周期。使用 Deployments 即可持續(xù)地部署新軟件，這是一組描述特定運(yùn)行工作負(fù)載新需求的元數(shù)據(jù)。舉個(gè)例子，發(fā)布新版本、錯(cuò)誤修復(fù)，甚至是回滾（這是 Kubernetes 的另一個(gè)內(nèi)部選項(xiàng)）。

在 Kubernetes 中部署軟件可使用 2 個(gè)主要策略：

• 替換——正如其名，使用新需求替換全部負(fù)載，自然會(huì)強(qiáng)制停機(jī)。對(duì)于快速替換非生產(chǎn)環(huán)境的資源，這很有幫助。

• 滾動(dòng)升級(jí)——通過(guò)監(jiān)聽兩個(gè)特定配置慢慢地將容器替換成新的：

a. MaxAvailable——設(shè)置在部署新版本時(shí)可用的工作負(fù)載比例（或具體數(shù)量），100% 表示“我有 2 個(gè)容器，在部署時(shí)要保持 2 個(gè)存活以服務(wù)請(qǐng)求”；

b. MaxSurge——設(shè)置在當(dāng)前存活容器的基礎(chǔ)上部署的工作負(fù)載比例（或數(shù)量），100% 表示“我有 X 個(gè)容器，部署另外 X 個(gè)容器，然后開始滾動(dòng)移除舊容器”。

11. Storage（存儲(chǔ)）

Kubernetes 在存儲(chǔ)之上添加了一層抽象。工作負(fù)載可以為不同任務(wù)請(qǐng)求特定存儲(chǔ)，甚至可以管理超過(guò) Pod 生命周期的持久化。為簡(jiǎn)短起見(jiàn)，請(qǐng)閱讀作者之前發(fā)布的關(guān)于 Kubernetes 存儲(chǔ)的文章，特別重點(diǎn)看看為什么它不能完全解決類似數(shù)據(jù)庫(kù)部署這樣的數(shù)據(jù)持久性要求。

概念性理解

Kubernetes（現(xiàn)在仍然）是根據(jù)一些指導(dǎo)原則進(jìn)行設(shè)計(jì)和開發(fā)的，構(gòu)建在系統(tǒng)里的每個(gè)功能、概念和想法都考慮了社區(qū)因素。此外，最終用戶會(huì)被引導(dǎo)以某種方式使用該系統(tǒng)，但這不是強(qiáng)迫的；最佳實(shí)踐也是公開的，但作為一個(gè)開源免費(fèi)的系統(tǒng)，你完全可以根據(jù)自身需要進(jìn)行操作。

面向 API——系統(tǒng)每個(gè)部分構(gòu)建時(shí)通過(guò)優(yōu)良的文檔和可操作的 API 來(lái)實(shí)現(xiàn)可交互性。核心開發(fā)人員會(huì)確保最終用戶可以進(jìn)行更改、查詢和更新，以免將其阻擋在外或有不想要的過(guò)濾器。

歡迎包裝工具——作為前一點(diǎn)的衍生產(chǎn)品，Kubernetes 對(duì)在其 API 之上構(gòu)建的工具和包裝器表示歡迎。作為一個(gè)原始平臺(tái)，Kubernetes 是以一個(gè)非?？啥ㄖ频姆绞竭M(jìn)行構(gòu)建的，以便他人使用，并進(jìn)一步開發(fā)用于不同用例的工具。有些工具已經(jīng)變得非常有名并被廣泛使用，比如 Spinnaker、Istio 等等。

聲明性狀態(tài)——鼓勵(lì)用戶在系統(tǒng)中使用聲明性描述而非命令式描述。這意味著，系統(tǒng)的狀態(tài)和組件最好被描述為在某種版本控制（如 Git）中管理的代碼，以此避免手工修改造成的困擾。因此，Kubernetes 減少了災(zāi)難恢復(fù)的難度、更易于在團(tuán)隊(duì)之間分享并傳遞責(zé)任。

到此，相信大家對(duì)“Kubernetes的詳細(xì)介紹”有了更深的了解，不妨來(lái)實(shí)際操作一番吧！這里是億速云網(wǎng)站，更多相關(guān)內(nèi)容可以進(jìn)入相關(guān)頻道進(jìn)行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！