K8s核心概念詳解

kubernetes（一般簡稱爲K8S），是一個用於管理在容器中運行的應用的容器編排工具。

Kubernetes不只有你所須要的用來支持複雜容器應用的全部東西，它仍是市面上最方便開發和運維的框架。

Kubernetes的工做原理是經過將容器分組來把一個應用程序拆分紅多個邏輯單元，以方便管理和發現。它對由小且獨立的服務組成的微服務應用特別有用。

儘管Kubernetes運行在Linux上，他實際上是平臺無關的，能夠在裸機、虛擬機、雲實例或OpenStack上運行。

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 會實現負載均衡。