Kubernetes的詳細介紹

本篇內容主要講解“Kubernetes的詳細介紹”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“Kubernetes的詳細介紹”吧!

Kubernetes 的 11 個部分

1. Pod

Pod 是 Kubernetes 中最小的可互動單元。一個 Pod 可以由多個容器組成，這些容器共同部署在單個節點上形成一個單元。一個 Pod 具有一個 IP，該 IP 在其容器之間共享。

在微服務世界中，一個 Pod 可以是執行后臺工作或服務請求的微服務的單個實例。

2. Node（節點）

Node 是機器。它們是 Kubernetes 用于部署 Pod 的“裸機”（或虛擬機）。Node 為 Kubernetes 提供可用的集群資源用于以保持數據、運行作業、維護工作負載、創建網絡路由等。

3. Label（標簽）與 Annotation（注解）

Label 是 Kubernetes 及其最終用戶用于過濾系統中相似資源的方式，也是資源與資源相互“訪問”或關聯的粘合劑。比如說，為 Deployment 打開端口的 Service。不論是監控、日志、調試或是測試，任何 Kubernetes 資源都應打上標簽以供后續查驗。例如，給系統中所有 Worker Pod 打上標簽：app=worker，之后即可在 kubectl 或 Kubernetes API 中使用 --selector 字段對其進行選擇。

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

4. Service Discovery（服務發現）

作為編排系統，Kubernetes 控制著不同工作負載的眾多資源，負責管理 Pod、作業及所有需要通信的物理資源的網絡。為此，Kubernetes 使用了 ETCD。

ETCD 是 Kubernetes 的“內部”數據庫，Master 通過它來獲取所有資源的位置。Kubernetes 還為服務提供了實際的“服務發現”——所有 Pod 使用了一個自定義的 DNS 服務器，通過解析其他服務的名稱以獲取其 IP 地址和端口。它在 Kubernetes 集群中“開箱即用”，無須進行設置。

5. ReplicaSet（副本集）

雖然 Pod 是一個物理性的運行任務，但通常使用單個實例是不夠的。為了冗余并處理負載，出于某種原因（比如“伸縮”）需要對 Pod 進行復制。為了實現負責擴展和復制的層，Kubernetes 使用了 ReplicaSet。這個層以副本的數量表示系統的期望狀態，并在任意給定時刻保持該系統的當前狀態。

這也是配置自動伸縮的所在，在系統高負載時創建額外的副本，并在不再需要這些資源來支撐所運行的工作負載時進行縮容。

6. DaemonSet（守護進程集）

有時候，應用程序每個節點需要的實例不超過一個。比如 FileBeat 這類日志收集器就是個很好的例子。為了從各個節點收集日志，其代理需要運行在所有節點上，但每個節點只需要一個實例。Kubernetes 的 DaemonSet 即可用于創建這樣的工作負載。

7. StatefulSet（有狀態集）

盡管多數微服務涉及的都是不可變的無狀態應用程序，但也有例外。有狀態的工作負載有賴于磁盤卷的可靠支持。雖然應用程序容器本身可以是不可變的，可以使用更新的版本或更健康的實例來替代，但是所有副本還是需要數據的持久化。StatefulSet 即是用于這類需要在整個生命周期內使用同一節點的應用程序的部署。

它還保留了它的“名稱”：容器內的 hostname 以及整個集群中服務發現的名稱。3 個 ZooKeeper 構成的 StatefulSet 可以被命名 zk-1、zk-2 及 zk-3，也可以擴展到更多的成員 zk-4、zk-5 等等…… StatefulSets 還負責管理 PersistentVolumeClaim（Pod 上連接的磁盤）。

8. Job（任務）

Kubernetes 核心團隊考慮了大部分使用編排系統的應用程序。雖然多數應用程序要求持續運行以同時處理服務器請求（比如 Web 服務器），但有時還是需要生成一批作業并在其完成后進行清理。比如，一個迷你的無服務器環境。

為了在 Kubernetes 中實現這一點，可以使用 Job 資源。正如其名，Job 的工作是生成容器來完成特定的工作，并在成功完成時銷毀。舉個例子，一組 Worker 從待處理和存儲的數據隊列中讀取作業。一旦隊列空了，就不再需要這些 Worker 了，直到下個批次準備好。

9. ConfigMap（配置映射）及 Secret（機密配置）

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

我個人認為 Hashicorp 的 Vault 是使用機密配置的最佳方案。請務必閱讀一下我去年寫的有關文章，文章講述了將 Vault 作為生產環境一部分的原因，以及我的一位同事寫的另一篇更技術性的文章。

10. Deployment（部署）

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

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

• 替換——正如其名，使用新需求替換全部負載，自然會強制停機。對于快速替換非生產環境的資源，這很有幫助。

• 滾動升級——通過監聽兩個特定配置慢慢地將容器替換成新的：

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

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

11. Storage（存儲）

Kubernetes 在存儲之上添加了一層抽象。工作負載可以為不同任務請求特定存儲，甚至可以管理超過 Pod 生命周期的持久化。為簡短起見，請閱讀作者之前發布的關于 Kubernetes 存儲的文章，特別重點看看為什么它不能完全解決類似數據庫部署這樣的數據持久性要求。

概念性理解

Kubernetes（現在仍然）是根據一些指導原則進行設計和開發的，構建在系統里的每個功能、概念和想法都考慮了社區因素。此外，最終用戶會被引導以某種方式使用該系統，但這不是強迫的；最佳實踐也是公開的，但作為一個開源免費的系統，你完全可以根據自身需要進行操作。

面向 API——系統每個部分構建時通過優良的文檔和可操作的 API 來實現可交互性。核心開發人員會確保最終用戶可以進行更改、查詢和更新，以免將其阻擋在外或有不想要的過濾器。

歡迎包裝工具——作為前一點的衍生產品，Kubernetes 對在其 API 之上構建的工具和包裝器表示歡迎。作為一個原始平臺，Kubernetes 是以一個非常可定制的方式進行構建的，以便他人使用，并進一步開發用于不同用例的工具。有些工具已經變得非常有名并被廣泛使用，比如 Spinnaker、Istio 等等。

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

到此，相信大家對“Kubernetes的詳細介紹”有了更深的了解，不妨來實際操作一番吧！這里是億速云網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！