- 說明
- Kubernetes叢集的組成
- What are containerized applications?
- What are Kubernetes containers?
- What are Kubernetes pods?
- What is the difference between containers vs. pods?
- What are Kubernetes nodes?
- What is a Kubernetes Control Plane?
- What is a Kubernetes Cluster?
- What are Kubernetes volumes?
- How do the components of Kubernetes work together?
說明
本本內容從 https://www.vmware.com/topics/glossary 獲取、翻譯,網站內容政策請參考 https://www.vmware.com/community_terms.html,內容複製、翻譯請參考版權協議 http://creativecommons.org/licenses/by-nc/3.0/。
本文內容從 vmware 網站的術語詞彙知識庫收集、翻譯、整理,文章主要介紹 Kubernetes 各組成部件中的一些術語,以及概念。
Kubernetes叢集的組成
我們談起 Kubernetes 和應用部署時,往往會涉及到容器、節點、Pods 等概念,還有各種術語,令人眼花繚亂。為了更好地摸清 Kubernetes,下面我們將介紹 Kubernetes 中與應用程式部署(deployment)和執行(execution)相關的知識。
Kubernetes 叢集由多個元件(components)、硬體(hardware)、軟體(software)組成,它們共同工作來管理容器化(containerized)應用的部署和執行,這些相關的組成的概念有:
成分 | 名稱 |
---|---|
Cluster | 叢集 |
Node | 節點 |
Pod | 不翻譯 |
Container | 容器 |
Containerzed Application | 容器化應用 |
接下來的內容,按將從小到大的粒度介紹這些組成成分。
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
管理流程: 將管理/管理任務作為一次性流程執行
上述內容可能有筆者翻譯不到位的地方,讀者可閱讀原文了解:
https://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 都按照指定的方式執行。