概述

Kubernetes

• 一個可在任何地方部署、擴縮和管理容器化應用的開源系統。

GKE（Google Kubernetes Engine）

• 雲中的託管式 Kubernetes，以可靠、高效、安全的方式執行 Kubernetes 叢集。

GKE On-Prem

• 無處不在的託管式 Kubernetes，在任意位置以可靠、高效、安全的方式執行 Kubernetes 叢集。

Kubernetes元件

硬體

節點(Node)

• 節點是Kubernetes中最小的計算硬體單元。它是叢集中單個機器的表示。在大多數生產系統中，節點很可能是資料中心中的物理機器，或者是託管在像谷歌雲平臺這樣的雲供應商上的虛擬機器器。不過，不要讓慣例限制了你的想象力，從理論上講，你可以把任何東西做成一個結點。

• 把機器看作一個“節點”，可以讓我們插入一個抽象層。現在，我們不必擔心任何單個機器的獨特特性，而是可以簡單地將每臺機器看作一組可以使用的CPU和RAM資源。這樣，任何機器都可以替代Kubernetes叢集中的任何其他機器。

叢集(Cluster)

• 雖然使用單個節點是有用的，但它與Kubernetes理念不同。一般來說，你應該將叢集看作一個整體，而無需擔心單個節點的狀態。
• 在Kubernetes中，節點匯聚資源，形成更強大的機器。當你將程式部署到叢集中時，它將智慧地處理將工作分配給你的各個節點。如果新增或刪除了任何節點，叢集將根據需要在工作中進行轉換。這對程式或程式設計師來說都不重要，因為機器實際上是在執行程式碼。

持久卷(Persistent Volumes)

• 因為在叢集上執行的程式不能保證在特定的節點上執行，所以無法將資料儲存到檔案系統中的任意位置。如果一個程式試圖將資料儲存到一個檔案中，但隨後又被轉移到一個新的節點上，那麼該檔案將不再是程式期望的位置。由於這個原因，與每個節點相關的傳統本地儲存被當作臨時快取來儲存程式，但本地儲存的任何資料都不能持久。

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

軟體

容器(Container)

• 在Kubernetes上執行的程式被打包成Linux容器。容器是一個被廣泛接受的標準，因此已經有許多預先構建的映像可以部署在Kubernetes上。

• 容器化允許你建立自足式的Linux執行環境。任何程式和它的所有依賴項都可以打包成一個檔案，然後在網路上共享。任何人都可以下載該容器並在其基礎設施上部署它，所需的設定非常少。建立一個容器可以通過程式設計方式完成，從而形成強大的CI和CD管道。

• 可以將多個程式新增到單個容器中，但是如果可能的話，你應該將自己限制為每個容器的一個程式。擁有很多小容器比一個大容器好。如果每個容器都有一個緊密的焦點，那麼更新更容易部署，並且問題更容易診斷。

Pod

• Pod 是 Kubernetes 中可部署的最小、最基本物件。一個 Pod 代表叢集中正在執行的單個程式例項。

• 與你過去使用的其他系統不同，Kubernetes不直接執行容器;相反，它將一個或多個容器封裝到一個稱為Pod的高階結構中。相同Pod中的任何容器都將共享相同的名稱空間和本地網路。容器可以很容易地與其他容器在相同的容器中進行通訊，就像它們在同一臺機器上同時保持一定程度的隔離。

• Pod被用作Kubernetes的複製單元。如果你的應用程式太受歡迎，單個的Pod例項無法承載負載，那麼可以配置Kubernetes以在必要時將你的Pod的新副本部署到叢集。即使在沒有過載的情況下，在生產系統中任何時候都要有多個副本，以保證負載均衡和故障抵抗。

• Pod可以容納多個容器，但在可能的情況下應該限制自己。因為Pod作為一個單位被放大和縮小時，所有在一個Pod裡的容器都必須在一起縮放，不管它們是否需要。這將導致資源的浪費和成本增加。為瞭解決這個問題，Pod應該保持儘可能小的大小，通常只保留一個主程式和緊密耦合的輔助容器(這些輔助容器通常被稱為“側三輪摩托車”)。

pod和容器的區別

• pod是Kubernetes的最小單元，容器包含在pod中，一個pod中有一個pause容器和若干個業務容器，而容器就是單獨的一個容器，簡而言之，pod是一組容器，而容器單指一個容器。

ReplicaSet

• 主要作用是確保Pod以你指定的副本數執行，即如果有容器異常退出，會自動建立新的 Pod 來替代；而異常多出來的容器也會自動回收。可以說，通過ReplicaSet，Kubernetes實現了叢集的高可用性。
• 雖然也 ReplicaSet 可以獨立使用，但建議使用 Deployment 來自動管理 ReplicaSet，這樣就無需擔心跟其他機制的不相容問題（比如 ReplicaSet 不支援 rolling-update 但 Deployment 支援），並且Deployment還支援版本記錄、回滾、暫停升級等高階特性。
• Kubernetes官方強烈建議避免直接使用ReplicaSet，而應該通過Deployment來建立RS和Pod。

部署(Deployment)

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

• 部署的主要目的是宣告一個Pod應該同時執行多少個副本。當將部署新增到叢集中時，它將自動地旋轉加速所需的Pod數量，然後監視它們。如果一個Pod消失，部署將自動重新建立它。

• 使用部署，你不必手動處理Pod。你只需宣告系統的期望狀態，它將自動為你管理。

• Deployments是kubernetes中的一種控制器，是比ReplicaSet更高階的概念，它最重的特性是支援對pod與ReplicaSet的宣告式升級，宣告式升級比其它方式的升級更安全可靠。需要注意的是使用者不應該手動管理被Deployments建立的ReplicaSet。

Service

• 將執行在一組 Pods 上的應用程式公開為網路服務的抽象方法。Service 物件提供對一組 Pod 的單一訪問點。儘管您可以訪問單個 Pod，但 Pod 是臨時性的，只有通過一個 Service 地址才能進行可靠的訪問。它通過一個虛擬的IP的形式(VIPs)，映射出來指定的埠，通過代理客戶端發來的請求轉發到後端一組Pods中的一臺（也就是endpoint）。此 Service 在 service.yaml 檔案中定義。
• 在Kubernetes中用到的管理微服務的常用的到的型別就是deployment， 裡面有個引數replicas 來管理整個deployment裡面Pod的生命週期，因為有容器的銷燬和生成導致Pod IP也就是動態變化的。而Service做為客戶端和Pod（backends）中間的代理層，並抽象一個clusterIP的虛擬IP ，叢集內部都可以通過這個IP訪訪問到具體Pod的服務。

Deployment與Service區別

• Deployment 物件，用來定義應用。
• Service 物件，用來定義如何訪問應用。

入口(Ingress)

• 使用上面描述的概念，你可以建立一個節點叢集，並將Pod部署到叢集上。不過，還有一個問題需要解決：允許外部通訊流進入你的應用程式。

• 預設情況下，Kubernetes提供隔離艙和外部世界。如果你想要與執行在Pod中的服務通訊，你必須開啟一個通訊通道。稱作入口(ingress)。

• 有多種方法可以將入口新增到叢集中。最常見的方法是新增入口控制器或負載均衡器。