淺入kubernetes(2):Kubernetes 的組成

說明

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

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

Kubernetes集羣的組成

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

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

成分 名稱
Cluster 集羣
Node 節點
Pod 不翻譯
Container 容器
Containerzed Application 容器化應用

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

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.併發

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

固然,並非說可以將一個應用程序打包到容器中運行,就能夠鼓吹產品;並非每一個應用程序都是容器化的優秀對象,例如在 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 集羣的控制器,主要包含 apiserveretcdschedulercontroller-manager

在第一篇時已經提到過,這裏不須要深刻介紹,故再也不贅述。

Kubernetes_Architecture_graphic

rancher-k8s-node-components-architecture

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 都按照指定的方式運行。

相關文章
相關標籤/搜索