Kubernetes 之 Pod 實現原理

Pod 就是最小而且最簡單的 Kubernetes 對象

Pod、Service、Volume 和 Namespace 是 Kubernetes 集羣中四大基本對象，它們可以表示系統中部署的應用、工做負載、網絡和磁盤資源，共同定義了集羣的狀態。Kubernetes 中不少其餘的資源其實只對這些基本的對象進行了組合。

• Pod -> 集羣中的基本單元

• Service -> 解決如何訪問 Pod 裏面服務的問題

• Volume -> 集羣中的存儲卷

• Namespace -> 命名空間爲集羣提供虛擬的隔離做用

Kubernetes 有許許多多的技術概念，同時對應不少 API 對象，其中最重要的也是最基礎的是 Pod 對象。Pod 是在 Kubernetes 集羣中運行部署應用或服務的最小單元，它是能夠支持多容器的。Pod 的設計理念是支持多個容器在一個 Pod 中共享網絡地址和文件系統，能夠經過進程間通訊和文件共享這種簡單高效的方式組合完成服務。

apiVersion: v1
kind: Pod
metadata:
  name: busybox
  labels:
    app: busybox
spec:
  containers:
  restartPolicy: Always
    - name: busybox
      image: busybox
      command:
        - sleep
        - "3600"
      imagePullPolicy: IfNotPresent

Pod 的內部結構

Pod 表明着集羣中運行的進程：共享網絡、共享存儲

在同一個 Pod 中，有幾個概念特別值得關注，首先就是容器，在 Pod 中其實能夠同時運行一個或者多個容器，這些容器可以共享網絡、存儲以及 CPU/內存等資源。

首先，咱們須要知道的是，每一個 Pod 都有一個特殊的被稱爲 「根容器」 的 Pause 容器。Pause 容器對應的鏡像屬於 Kubernetes 平臺的一部分，經過 Pause 容器使工做在對應 Pod 的容器之間能夠共享網絡、共享存儲。

Pod 共享資源

爲何 Kubernetes 會設計出一個全新的 Pod 概念，而且有這樣特殊的結構？主要是由於，使用 Pause 容器做爲 Pod 根容器，以它的狀態表明整個容器組的狀態；其次，Pod 裏的多個業務容器共享 Pause 容器的 IP 地址，共享 Pause 容器掛接的 Volume 資源。

• 共享存儲資源

能夠爲一個 Pod 指定多個共享的 Volume 資源。Pod 中的全部容器均可以訪問共享的 volume 資源。Volume 也能夠用來持久化 Pod 中的存儲資源，以防容器重啓後文件丟失。

• 共享網絡資源

每一個 Pod 都會被分配一個惟一的 IP 地址。Pod 中的全部容器共享網絡空間，包括 IP 地址和端口。Pod 內部的容器可使用 localhost 互相通訊。Pod 中的容器與外界通訊時，必須分配共享網絡資源，例如使用宿主機的端口映射。

veth 設備的特色

一個設備收到協議棧的數據發送請求後，會將數據發送到另外一個設備上去

• veth 和其它的網絡設備都同樣，一端鏈接的是內核協議棧

• veth 設備是成對出現的，另外一端兩個設備彼此相連

# 物理網卡eth0配置的IP爲192.168.1.11
# 而veth0和veth1的IP分別是192.168.2.11和192.168.2.10
+----------------------------------------------------------------+
|                                                                |
|       +------------------------------------------------+       |
|       |             Newwork Protocol Stack             |       |
|       +------------------------------------------------+       |
|              ↑               ↑               ↑                 |
|..............|...............|...............|.................|
|              ↓               ↓               ↓                 |
|        +----------+    +-----------+   +-----------+           |
|        |   eth0   |    |   veth0   |   |   veth1   |           |
|        +----------+    +-----------+   +-----------+           |
|192.168.1.11  ↑               ↑               ↑                 |
|              |               +---------------+                 |
|              |         192.168.2.11     192.168.2.10           |
+--------------|-------------------------------------------------+
               ↓
         Physical Network

Pod 的網絡通訊

集羣網絡解決方案: Kubernetes + Flannel

Kubernetes 的網絡模型假定了全部 Pod 都在一個直接連通的扁平的網絡空間中，這在 GCE(Google Compute Engine)裏面是現成的網絡模型，Kubernetes 假定這個網絡已經存在了。而在私有云搭建 Kubernetes 集羣，就不能假定這個網絡已經存在了。咱們須要本身實現這個網絡假設，將不一樣節點上的 Docker 容器之間的互相訪問先打通，而後才能正常運行 Kubernetes 集羣。

• 同一個 Pod 內多個容器以前經過迴環網絡(lo - 127.0.0.1)進行通訊

• 各 Pod 之間的通信，則是經過 Overlay Network 網絡進行通訊

• 而 Pod 與 Service 之間的通信，則是各節點的 iptables 或 lvs 規則

Flannel 是 CoreOS 團隊針對 Kubernetes 設計的一個網絡規劃服務，簡單來講，它的功能就是讓集羣中的不一樣節點主機建立的 Docker 容器都具備全集羣惟一的虛擬 IP 地址。並且它還能在這些 IP 地址之間創建一個覆蓋的網絡(Overlay Network)，經過這個覆蓋網絡，將數據包原封不動地傳遞給目標容器內。

不一樣狀況下的網絡通訊方式

• 同一個 Pod 內部通信：

• 同一個 Pod 共享同一個網絡命名空間，共享同一個 Linux 協議棧。

• 不一樣 Pod 之間通信：

• Pod1 和 Pod2 在同一臺 Node 主機，由 docker0 網橋直接轉發請求到 Pod2 上面，- 不通過 Flannel 的轉發。

• Pod1 和 Pod2 不在同一臺 Node 主機，Pod 的地址是與 docker0 在同一個網段的，但 docker0 網絡與宿主機網卡是兩個徹底不一樣的 IP 網段，而且不一樣的 Node 之間的通信只能經過宿主機的物理網卡進行。將 Pod 的 IP 地址和所在 Node 的 IP 地址關聯起來，經過這個關聯讓 Pod 能夠互相訪問。

• Pod 至 Service 的網絡

• 目前基於性能考慮，所有爲 iptables 或 lvs 維護和轉發。

• Pod 到外網

• Pod 想外網發送請求，查找路由表，轉發數據包到宿主機的網卡，宿主機網卡完成路由選擇以後，iptables 或 lvs 執行 Masquerade，把源 IP 地址更改成宿主機的網卡的 IP 地址，而後向外網服務器發送請求。

• 外網訪問 Pod

• 經過 Service 服務來向外部提供 Pod 服務。

ETCD 之於 Flannel 提供說明：

• 存儲管理 Flannel 可分配的 IP 地址段資源

• 監控 ETCD 中每個 Pod 的實際 IP 地址，並在內存中創建維護 Pod 節點的路由表

Pod 的多種類型

Pod 存在多種不一樣的建立類型來知足不同的用途

ReplicationController

ReplicationController 用來確保容器應用的副本數量始終保持在用戶定義的副本數，即若是有容器異常退出，會自動建立新的 Pod 來代替，而若是異常多出現的容器會自動回收。

ReplicaSet

在新版本(相對而言的較優方式)的 Kubernetes 中建議使用 ReplicaSet 來取代 ReplicationController 來管理 Pod。雖然 ReplicaSet 和 ReplicationController 並無本質上的不一樣，只是名字不同而已，惟一的區別就是 ReplicaSet 支持集合式的 selector，可供標籤篩選。

雖然 ReplicaSet 能夠獨立使用，但通常仍是建議使用 Deployment 來自動管理 ReplicaSet 建立的 Pod，這樣就無需擔憂跟其餘機制的不兼容問題。好比 ReplicaSet 自身並不支持滾動更新(rolling-update)，可是使用 Deployment 來部署就原生支持。

Deployment

Deployment 爲 Pod 和 ReplicaSet 提供了一個聲明式定義方法，用來替代之前使用 ReplicationController 來方便且便捷的管理應用。主要的應用場景，包括：滾動升級和回滾應用、擴容和縮容、暫停和繼續。

HPA

HPA 僅僅適用於 Deployment 和 ReplicaSet，在 V1 版本中僅支持根據 Pod 的 CPU 利用率擴縮容，在新版本中，支持根據內存和用戶自定義的 metric 動態擴縮容。

StatefulSet

StatefulSet 是爲了解決有狀態服務的問題，相對於 Deployment 和 ReplicaSet 而已。其主要的使用場景，包括：穩定的持久化存儲、穩定的網絡標識、有序部署、有序收縮。

DaemonSet

DaemonSet 確保所有或者一些 Node 上面運行一個 Pod 副本。當有 Node 加入集羣的時候，也會爲它們新加一個 Pod。當有 Node 從集羣中移除的時候，這些 Pod 也會被回收。刪除 DaemonSet 將會刪除它所建立的全部 Pod。

使用 DaemonSet 的典型場景就是，在每一個節點運行日誌收集、運行監控系統、運行集羣存儲等服務，只要新加進來的節點都須要運行該服務。

Job

Job 負責批處理任務，僅執行一次的任務，它保證批處理任務的一個或者多個 Pod 成功結束，纔會返回成功。

Cront Job

Cront Job 管理是基於時間的 Job，即在給定時間點只運行一次，且週期行的在給定時間點運行特定任務。

做者: Escape
連接: https://www.escapelife.site/p...