淺入kubernetes(2)：Kubernetes 的組成

• 2021 年 1 月 4 日
• 筆記
• Kubernetes與Docker, 雲計算

說明

本本內容從 //www.vmware.com/topics/glossary 獲取、翻譯，網站內容政策請參考 //www.vmware.com/community_terms.html，內容複製、翻譯請參考版權協議 //creativecommons.org/licenses/by-nc/3.0/。

本文內容從 vmware 網站的術語詞彙知識庫收集、翻譯、整理，文章主要介紹 Kubernetes 各組成部件中的一些術語，以及概念。

Kubernetes集群的組成

我們談起 Kubernetes 和應用部署時，往往會涉及到容器、節點、Pods 等概念，還有各種術語，令人眼花繚亂。為了更好地摸清 Kubernetes，下面我們將介紹 Kubernetes 中與應用程序部署(deployment)和執行(execution)相關的知識。

Kubernetes 集群由多個組件(components)、硬件(hardware)、軟件(software)組成，它們共同工作來管理容器化(containerized)應用的部署和執行，這些相關的組成的概念有：

接下來的內容，按將從小到大的粒度介紹這些組成成分。

What are containerized applications?

containerized applications 指容器化的應用，我們常常說使用鏡像打包應用程序，使用 Docker 發佈、部署應用程序，那麼當你的應用成功在 Docker 上運行時，稱這個應用是 containerized applications。

定義：

Containerized applications are bundled with their required libraries, binaries, and configuration files into a container.

容器化的應用程序與它們所需的庫、二進制文件和配置文件綁定到一個容器中。

當然，並不是說能夠將一個應用程序打包到容器中運行，就可以鼓吹產品；並不是每個應用程序都是容器化的優秀對象，例如在 DDD 設計中被稱為大泥球的應用程序，由於其設計複雜、依賴程度高、程序不穩定等原因，難以遷移、難以配置的應用程序明顯是失敗的產品。

在多年經驗中，許多開發者總結了經驗，形成十二個雲計算應用程序因素指導原則：

1. Codebase: One codebase tracked in revision control, many deploys

​ 代碼庫: 一個代碼庫可以在版本控制和多份部署中被跟蹤

2. Dependencies: Explicitly declare and isolate dependencies

依賴項: 顯式聲明和隔離依賴項

3. Config: Store config in the environment

配置: 在環境中存儲配置

4. Backing services: Treat backing services as attached resources

支持服務: 將支持服務視為附加資源(可拓展，而不是做成大泥球)

5. Build, release, run: Strictly separate build and run stages

構建、發佈、運行: 嚴格區分構建和運行階段(連 Debug、Release 都沒有區分的產品是真的垃圾)

6. Processes: Execute the app as one or more stateless processes

過程: 作為一個或多個無狀態過程執行應用程序

7. Port binding: Export services via port binding

端口綁定: 可通過端口綁定服務對外提供服務

8. Concurrency: Scale out via the process model

並發性: 通過進程模型進行擴展

9. Disposability: Maximize robustness with fast startup and graceful shutdown

可處理性: 快速啟動和完美關機，最大限度地增強健壯性

10. Dev/prod parity: Keep development, staging, and production as similar as possible

Dev/prod parity: 儘可能保持開發中、演示時和生產時的相似性

11. Logs: Treat logs as event streams

Logs: 將日誌視為事件流

12. Admin processes: Run admin/management tasks as one-off processes

管理流程: 將管理/管理任務作為一次性流程運行

上述內容可能有筆者翻譯不到位的地方，讀者可閱讀原文了解：

//www.vmware.com/topics/glossary/content/components-kubernetes

許多流行的編程語言和應用被容器化並存儲在開源倉庫中，然而，只使用運行應用程序所需的庫和二進制文件來構建應用程序容器，不需要導入所有可用的東西，這樣可能會更有效率。創建容器可以採用編程方式，從而可以創建持續集成和部署(CI/CD)管道以提高效率。容器化應用位於開發人員領域之中，開發人員需要掌握如何容器化應用。

What are Kubernetes containers?

Containers are standardized, self-contained execution enclosures for applications.

容器是應用的標準化、獨立的執行外殼。

通常，容器都包含一個應用程序，以及正確執行二進制程序所需的依賴庫、文件等，例如 Linux 文件系統+應用程序組成一個簡單的容器。通過將容器限制為單個進程，問題診斷和更新應用程序都變得更加容易。與 VM(虛擬機)不同，容器不包含底層操作系統，因此容器被認為是輕量級的。Kubernentes 容器屬於開發領域。

What are Kubernetes pods?

Pod 是 Kubernetes 集群中最小的執行單位。在 Kubernetes 中，容器不直接在集群節點上運行，而是將一個或多個容器封裝在一個 Pod 中。Pod 中的所有應用程序共享相同的資源和本地網絡，從而簡化了 Pod 中應用程序之間的通訊。Pod 在每個節點(Node)上利用一個名為 Kubelet 的代理和 Kubernetes API 以及集群中其餘部分進行通訊。儘管現在開發人員需要 API 訪問完成集群管理，但 Pod 的管理是正在向 Devops 領域過渡。

隨着 Pod 負載的增加，Kubernetes 可以自動複製 Pod 以達到預期的可拓展性(部署更多的 Pod 提供相同的服務，負載均衡)。因此，設計一個儘可能精簡的 Pod 是很重要的，降低因複製擴容、減少收縮過程中帶來的資源損失。

Pod 似乎被認為是 DevOps 的專業領域。

What is the difference between containers vs. pods?

容器包含執行特定流程或函數所需的代碼(編譯後的二進制可執行程序)。在 Kubernetes 之前，組織可以直接在物理或虛擬服務器上運行容器，但是缺乏 Kubernetes 集群所提供的可伸縮性和靈活性。

Pod 為容器提供了一種抽象，可以將一個或多個應用程序包裝到一個 Pod 中，而 Pod 是 Kubernetes 集群中最小的執行單元。例如 Pod 可以包含初始化容器，這些容器為其它應用提供了準備環境，然後在應用程序開始執行前終結。Pod 是集群中複製的最小單位，Pod 中的容器作為整體被擴展或縮小。

如果應用程序需要訪問持久性的存儲，那麼 Pod 也包括持久性存儲和容器。

What are Kubernetes nodes?

Pod 是 Kubernetes 中最小的執行單元，而 Node 是 Kubernetes 中最小的計算硬件單元。節點可以是物理的本地服務器，也可以是虛擬機。

與容器一樣，Node 提供了一個抽象層。如果操作團隊認為一個 Node 只是一個具有處理能力和內存的資源，那麼每個 Node 就可以與下一個 Node 互換。多個 Node 一起工作形成了 Kubernetes 集群，它可以根據需求的變化自動分配工作負載。如果一個節點失敗，它將自動從集群中移除，由其他節點接管。每個節點都運行着一個名為 kubelet 的代理，該代理與集群控制平面通信。

Node 是 DevOps 和 IT 的專業領域。

What is the difference between Kubernetes pods vs. nodes?

Pod 是可執行代碼的抽象，Node 是計算機硬件的抽象，所以這種比較有點像蘋果和橘子。

Pods 是 Kubernetes 最小的執行單元，由一個或多個容器組成；

Node 是組成 Kubernetes 集群的物理服務器或虛擬機。Node 是可互換的，通常不會由用戶或 IT 單獨處理，除非需要進行維護。

What is a Kubernetes Control Plane?

Kubernetes 控制平面是用於 Kubernetes 集群的控制器，主要包含 apiserver、etcd、scheduler、controller-manager 。

在第一篇時已經提到過，這裡不需要深入介紹，故不再贅述。

What is a Kubernetes Cluster?

Kubernetes 集群由 Node 組成，Node 可以是虛擬機或物理服務器。當你使用 Kubernetes 時，大多時間是在管理集群。在一個 Node 上必須至少有一個運行的 Kubernetes 控制平面的實例，以及至少一個要在其上運行的 Pod。通常，當工作負載發生變化時，集群將有多個節點來處理應用程序的變更。

What is the difference between Kubernetes Nodes vs. Clusters?

Node 是集群中最小的元素。集群由 Node 組成。集群是一個集體，共享 Pod 的總體執行，反映在 Google Kubernetes 集群項目的原始名稱: Borg。

What are Kubernetes volumes?

由於容器最初設計為臨時性和無狀態的，因此幾乎不需要解決存儲持久性問題。然而，隨着越來越多需要從持久性存儲讀寫的應用程序被容器化，對持久性存儲卷的訪問需求也隨之出現。

為了實現這一點，Kubernetes 有持久的卷。獨特之處在於它們是集群外部的，可以將持久卷掛載到集群，而不需要將它們與特定節點、容器或 pod 關聯。

持久卷可以是本地的，也可以是基於雲的，並且是 DevOps 和 IT 的專業領域。

在 Docker 中，我們可以使用以下命令管理卷

# 創建自定義容器卷
docker volume create {卷名稱}

# 查看所有容器卷
docker volume ls

# 查看指定容器卷的詳細信息
docker volume inspect {卷名稱}

我們可以在運行容器時，使用 -v 映射主機目錄，或者映射容器卷到容器中。

docker -itd ... -v /var/tmp:/opt/app ...
docker -itd ... -v {卷名}:/opt/app    ...

How do the components of Kubernetes work together?

簡單地說，剛開始時，應用程序被創建或遷移到容器中，然後運行在 Kubernetes 集群創建的 Pod上。

一旦 Pod 被創建，Kubernetes 會將它們分配給集群中的一個或多個 Node ，並確保運行的副本 Node 的正確數量。Kubernetes 掃描集群以確保每組 Container 都按照指定的方式運行。