kubernetes核心概念

Cluster

Cluster 是計算、存儲和網絡資源的集合，Kubernetes 利用這些資源運作各種基于容器的應用。

Master

Master 是 Cluster 的大腦，它的主要職責是排程，即決定将應用放在哪裡運作。Master 運作 Linux 作業系統，可以是實體機或者虛拟機。為了實作高可用，可以運作多個 Master。

Node

Node 的職責是運作容器應用。Node 由 Master 管理，Node 負責監控并彙報容器的狀态，并根據 Master 的要求管理容器的生命周期。Node 運作在 Linux 作業系統，可以是實體機或者是虛拟機。

在前面互動式教程中我們建立的 Cluster 隻有一個主機 host01，

它既是 Master 也是 Node。

Pod

Pod 是 Kubernetes 的最小工作單元。每個 Pod 包含一個或多個容器。Pod 中的容器會作為一個整體被 Master 排程到一個 Node 上運作。

Kubernetes 引入 Pod 主要基于下面兩個目的：

可管理性。

有些容器天生就是需要緊密聯系，一起工作。Pod 提供了比容器更高層次的抽象，将它們封裝到一個部署單元中。Kubernetes 以 Pod 為最小機關進行排程、擴充、共享資源、管理生命周期。

通信和資源共享。

Pod 中的所有容器使用同一個網絡 namespace，即相同的 IP 位址和 Port 空間。它們可以直接用 localhost 通信。同樣的，這些容器可以共享存儲，當 Kubernetes 挂載 volume 到 Pod，本質上是将 volume 挂載到 Pod 中的每一個容器。

Pods 有兩種使用方式：

運作單一容器。

one-container-per-Pod 是 Kubernetes 最常見的模型，這種情況下，隻是将單個容器簡單封裝成 Pod。即便是隻有一個容器，Kubernetes 管理的也是 Pod 而不是直接管理容器。

運作多個容器。

但問題在于：哪些容器應該放到一個 Pod 中？

答案是：這些容器聯系必須 非常緊密，而且需要 直接共享資源。

Controller

Kubernetes 通常不會直接建立 Pod，而是通過 Controller 來管理 Pod 的。Controller 中定義了 Pod 的部署特性，比如有幾個副本，在什麼樣的 Node 上運作等。為了滿足不同的業務場景，Kubernetes 提供了多種 Controller，包括 Deployment、ReplicaSet、DaemonSet、StatefuleSet、Job 等，我們逐一讨論。

Deployment 是最常用的 Controller，比如前面線上教程中就是通過建立 Deployment 來部署應用的。Deployment 可以管理 Pod 的多個副本，并確定 Pod 按照期望的狀态運作。

ReplicaSet 實作了 Pod 的多副本管理。使用 Deployment 時會自動建立 ReplicaSet，也就是說 Deployment 是通過 ReplicaSet 來管理 Pod 的多個副本，我們通常不需要直接使用 ReplicaSet。

DaemonSet 用于每個 Node 最多隻運作一個 Pod 副本的場景。正如其名稱所揭示的，DaemonSet 通常用于運作 daemon。

StatefuleSet 能夠保證 Pod 的每個副本在整個生命周期中名稱是不變的。而其他 Controller 不提供這個功能，當某個 Pod 發生故障需要删除并重新啟動時，Pod 的名稱會發生變化。同時 StatefuleSet 會保證副本按照固定的順序啟動、更新或者删除。

Job 用于運作結束就删除的應用。而其他 Controller 中的 Pod 通常是長期持續運作。

Service

Deployment 可以部署多個副本，每個 Pod 都有自己的 IP，外界如何通路這些副本呢？

通過 Pod 的 IP 嗎？

要知道 Pod 很可能會被頻繁地銷毀和重新開機，它們的 IP 會發生變化，用 IP 來通路不太現實。

答案是 Service。

Kubernetes Service 定義了外界通路一組特定 Pod 的方式。Service 有自己的 IP 和端口，Service 為 Pod 提供了負載均衡。

Kubernetes 運作容器（Pod）與通路容器（Pod）這兩項任務分别由 Controller 和 Service 執行。

Namespace

如果有多個使用者或項目組使用同一個 Kubernetes Cluster，如何将他們建立的 Controller、Pod 等資源分開呢？

答案就是 Namespace。

Namespace 可以将一個實體的 Cluster 邏輯上劃分成多個虛拟 Cluster，每個 Cluster 就是一個 Namespace。不同 Namespace 裡的資源是完全隔離的。

Kubernetes 預設建立了兩個 Namespace。

default – 建立資源時如果不指定，将被放到這個 Namespace 中。

kube-system – Kubernetes 自己建立的系統資源将放到這個 Namespace 中。

API Server（kube-apiserver）

API Server 提供 HTTP/HTTPS RESTful API，即 Kubernetes API。API Server 是 Kubernetes Cluster 的前端接口，各種用戶端工具（CLI 或 UI）以及 Kubernetes 其他元件可以通過它管理 Cluster 的各種資源。

Scheduler（kube-scheduler）

Scheduler 負責決定将 Pod 放在哪個 Node 上運作。Scheduler 在排程時會充分考慮 Cluster 的拓撲結構，目前各個節點的負載，以及應用對高可用、性能、資料親和性的需求。

Controller Manager（kube-controller-manager）

Controller Manager 負責管理 Cluster 各種資源，保證資源處于預期的狀态。Controller Manager 由多種 controller 組成，包括 replication controller、endpoints controller、namespace controller、serviceaccounts controller 等。

不同的 controller 管理不同的資源。例如 replication controller 管理 Deployment、StatefulSet、DaemonSet 的生命周期，namespace controller 管理 Namespace 資源。

etcd

etcd 負責儲存 Kubernetes Cluster 的配置資訊和各種資源的狀态資訊。當資料發生變化時，etcd 會快速地通知 Kubernetes 相關元件。

Pod 網絡

Pod 要能夠互相通信，Kubernetes Cluster 必須部署 Pod 網絡，flannel 是其中一個可選方案。

kubelet

kubelet 是 Node 的 agent，當 Scheduler 确定在某個 Node 上運作 Pod 後，會将 Pod 的具體配置資訊（image、volume 等）發送給該節點的 kubelet，kubelet 根據這些資訊建立和運作容器，并向 Master 報告運作狀态。

kube-proxy

service 在邏輯上代表了後端的多個 Pod，外界通過 service 通路 Pod。service 接收到的請求是如何轉發到 Pod 的呢？這就是 kube-proxy 要完成的工作。

每個 Node 都會運作 kube-proxy 服務，它負責将通路 service 的 TCP/UPD 資料流轉發到後端的容器。如果有多個副本，kube-proxy 會實作負載均衡

想了解更多看這個哦:https://github.com/luoyan321?tab=repositories