Pods,Nodes,Containers和Clusters

來自專欄進擊的雲計算5 人贊了文章

翻譯：https://medium.com/google-cloud/kubernetes-101-pods-nodes-containers-and-clusters-c1509e409e16

Kubernetes正在迅速成為在雲平台部署和管理軟體的新標準。然而，Kubernetes提供的功能也都帶來了陡峭的學習曲線。作為一個新手，試圖解析官方文檔可能是困難的。系統由許多不同的部分組成，很難說哪些部分與你的問題相關。這篇文章將提供Kubernetes的簡化視圖，但它將嘗試對最重要的組件以及它們如何組合在一起進行抽象的概述。

首先，讓我們看一下硬體的表示方式

硬體

節點(Nodes)

一個節點在Kubernetes里是最小的硬體計算單位。它表示群集中的單台計算機。在大多數生產系統中，節點可能是數據中心中的物理機，也可能是託管在雲提供商（如Google Cloud Platform）上的虛擬機。但是，不要讓約定限制你; 從理論上講，你可以幾乎 把 任何東西 當作一個Node。

將機器視為"node"允許我們插入一層抽象。現在，我們可以簡單地將每台機器視為一組可以使用的CPU和RAM資源，而不必擔心任何單個機器的獨特特性。這樣，任何機器都可以替換Kubernetes集群中的任何其他機器。

集群(The Cluster)

雖然使用單個節點可能很有用，但它不是Kubernetes的工作方式。通常，你應該將集群視為一個整體，而不是考慮單個節點的狀態。

在Kubernetes中，節點將它們的資源集中在一起以形成一個更強大的機器。將程序部署到群集時，它會智能地為你分配工作到各個節點。如果添加或刪除任何節點，群集將根據需要轉移工作。對於程序或程序員來說，單個機器實際運行代碼並不重要。

如果這種類似hivemind的系統讓你想起星際迷航中的Borg，那麼你並不孤單; 「Borg」是Kubernetes基於的內部Google項目的名稱。

持續卷(Persistent Volumes)

由於無法保證在群集上運行的程序在特定節點上運行，因此無法將數據保存到文件系統中的任何位置。如果程序試圖將數據保存到文件中以供日後使用，但隨後重新定位到新節點上，則該文件將不再是程序所期望的位置。因此，與每個節點關聯的傳統本地存儲被視為用於保存程序的臨時高速緩存，但是不能期望本地保存的任何數據都保持不變。

為了永久存儲數據，Kubernetes使用Persistent Volumes。雖然所有節點的CPU和RAM資源都由集群有效地彙集和管理，但持久性文件存儲卻不是。相反，本地或雲驅動器可以作為持久卷附加到集群。這可以被認為是將外部硬碟插入集群。Persistent Volumes提供可以掛載到群集的文件系統，而不與任何特定節點關聯。

軟體

容器(Containter)

在Kubernetes上運行的程序打包為Linux容器。容器是一種被廣泛接受的標準，因此已經有許多預構建的鏡像可以部署在Kubernetes上。

容器化允許你創建自包含的Linux執行環境。任何程序及其所有依賴項都可以捆綁到一個文件中，然後在Internet上共享。任何人都可以下載容器並將其部署在他們的基礎架構上，只需很少的設置。可以通過編程方式創建容器，從而形成強大的CI和CD管道。

可以將多個程序添加到單個容器中，但是如果可能的話，你應該將它限制為每個容器一個進程。擁有許多小容器比一個大容器更好。如果每個容器都更加內聚，則更新更容易部署，並且問題更容易診斷。

莢(Pods)

與你過去使用的其他系統不同，Kubernetes不直接運行容器; 相反，它將一個或多個容器包裝到稱為pod的更高級別的結構中。同一pod中的任何容器將共享相同的資源和本地網路。容器可以輕鬆地與同一個容器中的其他容器進行通信，就像它們在同一台機器上一樣，同時保持與其他容器的隔離程度。

Pod用作Kubernetes中的可複製單元。如果你的應用程序變得過於流行且單個pod實例無法承載負載，則可以將Kubernetes配置為根據需要將pod的新副本部署到群集。即使在不負載的情況下，在生產系統中隨時運行多個pod的副本也是標準的，以允許負載平衡和故障冗餘。

Pod可以容納多個容器，但是你應該儘可能限制自己。由於pod是作為一個單元放大和縮小的，因此pod中的所有容器必須一起擴展，無論其個人需求如何。這導致浪費的資源和昂貴的賬單。為了解決這個問題，pod應該保持儘可能小，通常只保持一個主進程及其緊密耦合的輔助容器（這些輔助容器通常被稱為「邊車」）。

部署(Deployment)

雖然pod是Kubernetes中的基本計算單元，但它們通常不直接在群集上啟動。相反，pod通常由另一層抽象管理：部署。

部署的主要目的是聲明一次應該運行多少個pod副本。將部署添加到群集後，它將自動啟動請求的pod數量，然後監視它們。如果pod死亡，部署將自動重新創建它。

使用部署，你不必手動處理pod。你只需聲明所需的系統狀態，即可自動為您管理。

入口(Ingress)

使用上述概念，你可以創建節點集群，並將pod的部署啟動到集群上。但是，還有一個問題需要解決：允許外部流量訪問到你的應用程序。

默認情況下，Kubernetes提供pod和外部世界之間的隔離。如果要與在pod中運行的服務進行通信，則必須打開通信通道。這被稱為入口。

有多種方法可以向群集添加入口。最常見的方法是添加Ingress控制器或LoadBalancer。這兩個選項之間的確切權衡超出了本文的範圍，但你必須意識到在你嘗試使用Kubernetes之前需要處理入口。