pod的深入了解

1. 什麼是Pod？

Pod是kubernetes中你可以建立和部署的最小也是最簡的機關。一個Pod代表着叢集中運作的一個程序。

Pod中封裝着應用的容器（有的情況下是好幾個容器），存儲、獨立的網絡IP，管理容器如何運作的政策選項。Pod代表着部署的一個機關：kubernetes中應用的一個執行個體，可能由一個或者多個容器組合在一起共享資源。

Pod中共享的環境包括Linux的namespace，cgroup和其他可能的隔絕環境，這一點跟Docker容器一緻。在Pod的環境中，每個容器中可能還有更小的子隔離環境。

2.Pod中如何管理多個容器？

Pod中可以同時運作多個程序（作為容器運作）協同工作。同一個Pod中的容器會自動的配置設定到同一個 node 上。同一個Pod中的容器共享資源、網絡環境和依賴，它們總是被同時排程。

Pod中可以共享兩種資源：網絡和存儲

• 每個Pod都會被配置設定一個唯一的IP位址。Pod中的所有容器共享網絡空間，包括IP位址和端口。Pod内部的容器可以使用localhost互相通信。Pod中的容器與外界通信時，必須配置設定共享網絡資源（例如使用主控端的端口映射）。
• 可以Pod指定多個共享的Volume。Pod中的所有容器都可以通路共享的volume。Volume也可以用來持久化Pod中的存儲資源，以防容器重新開機後檔案丢失。

3.Pod的分類

• 自主式Pod

  這種Pod本身是不能自我修複的，當Pod被建立後（不論是由你直接建立還是被其他Controller），都會被Kuberentes排程到叢集的Node上。直到Pod的程序終止、被删掉、因為缺少資源而被驅逐、或者Node故障之前這個Pod都會一直保持在那個Node上。Pod不會自愈。如果Pod運作的Node故障，或者是排程器本身故障，這個Pod就會被删除。同樣的，如果Pod所在Node缺少資源或者Pod處于維護狀态，Pod也會被驅逐。

• 控制器管理的Pod

  Kubernetes使用更進階的稱為Controller的抽象層，來管理Pod執行個體。Controller可以建立和管理多個Pod，提供副本管理、滾動更新和叢集級别的自愈能力。

  

每個Pod都有一個特殊的被稱為“根容器”的Pause 容器。 Pause容器對應的鏡像屬于Kubernetes平台的一部分，除了Pause容器，每個Pod還包含一個或者多個緊密相關的使用者業務容器。

Kubernetes設計這樣的Pod概念和特殊組成結構有什麼用意？

原因一：在一組容器作為一個單元的情況下，難以對整體的容器簡單地進行判斷及有效地進行行動。比如，一個容器死亡了，此時是算整體挂了麼？那麼引入與業務無關的Pause容器作為Pod的根容器，以它的狀态代表着整個容器組的狀态，這樣就可以解決該問題。

原因二：Pod裡的多個業務容器共享Pause容器的IP，共享Pause容器挂載的Volume，這樣簡化了業務容器之間的通信問題，也解決了容器之間的檔案共享問題。

4.Pod的生命周期

Pod 的 status 在資訊儲存在 PodStatus 中定義，其中有一個 phase 字段。

Pod 的相位（phase）是 Pod 在其生命周期中的簡單宏觀概述。該階段并不是對容器或 Pod 的綜合彙總，也不是為了做為綜合狀态機。

• 挂起（Pending）：APIServer建立了Pod資源對象并已經存入了etcd中，但是它并未被排程完成，或者仍然處于從倉庫下載下傳鏡像的過程中。
• 運作中（Running）：Pod已經被排程到某節點之上，并且所有容器都已經被kubelet建立完成。
• 成功（Succeeded）：Pod 中的所有容器都被成功終止，并且不會再重新開機。
• 失敗（Failed）：Pod中的所有容器都已終止了，并且至少有一個容器是因為失敗終止。也就是說，容器以非0狀态退出或者被系統終止。
• 未知（Unknown）：因為某些原因無法取得 Pod 的狀态，通常是因為與 Pod 所在主機通信失敗。

  

Pod是Kubernetes的基礎單元，了解其建立的過程，更有助于了解系統的運作。

①使用者通過kubectl或其他API用戶端送出Pod Spec給API Server。

②API Server嘗試将Pod對象的相關資訊存儲到etcd中，等待寫入操作完成，API Server傳回确認資訊到用戶端。

③API Server開始反映etcd中的狀态變化。

④所有的Kubernetes元件通過"watch"機制跟蹤檢查API Server上的相關資訊變動。

⑤kube-scheduler（排程器）通過其"watcher"檢測到API Server建立了新的Pod對象但是沒有綁定到任何工作節點。

⑥kube-scheduler為Pod對象挑選一個工作節點并将結果資訊更新到API Server。

⑦排程結果新消息由API Server更新到etcd，并且API Server也開始回報該Pod對象的排程結果。

⑧Pod被排程到目标工作節點上的kubelet嘗試在目前節點上調用docker engine進行啟動容器，并将容器的狀态結果傳回到API Server。

⑨API Server将Pod資訊存儲到etcd系統中。

⑩在etcd确認寫入操作完成，API Server将确認資訊發送到相關的kubelet。

5.Pod存活性探測

在pod生命周期中可以做的一些事情。主容器啟動前可以完成初始化容器，初始化容器可以有多個，他們是串行執行的，執行完成後就推出了，在主程式剛剛啟動的時候可以指定一個post start 主程式啟動開始後執行一些操作，在主程式結束前可以指定一個 pre stop 表示主程式結束前執行的一些操作。在程式啟動後可以做兩類檢測 liveness probe（存活性探測） 和 readness probe（就緒性探測）。

探針是由 kubelet 對容器執行的定期診斷。要執行診斷，kubelet 調用由容器實作的Handler。其存活性探測的方法有以下三種：

1. ExecAction：在容器内執行指定指令。如果指令退出時傳回碼為 0 則認為診斷成功。
2. TCPSocketAction：對指定端口上的容器的 IP 位址進行 TCP 檢查。如果端口打開，則診斷被認為是成功的。

3. HTTPGetAction：對指定的端口和路徑上的容器的 IP 位址執行 HTTP Get 請求。如果響應的狀态碼大于等于200 且小于

   400，則診斷被認為是成功的。

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness-exec
  name: liveness-exec
spec:
  containers:
  - name: liveness-exec-demo
    image: busybox
    args: ["/bin/sh","-c","touch /tmp/healthy;sleep 60;rm -rf /tmp/healthy;"sleep 600]
    livenessProbe:
      exec:
        command: ["test","-e","/tmp/healthy"]
           

livenessProbe和readinessProbe使用場景

如果希望容器在探測失敗時被殺死并重新啟動，那麼請指定一個存活探針，并指定restartPolicy 為 Always 或 OnFailure。

如果要僅在探測成功時才開始向 Pod 發送流量，請指定就緒探針。在這種情況下，就緒探針可能與存活探針相同，但是 spec 中的就緒探針的存在意味着 Pod 将在沒有接收到任何流量的情況下啟動，并且隻有在探針探測成功後才開始接收流量。

6.Pod的重新開機政策

PodSpec 中有一個 restartPolicy 字段，可能的值為 **Always、OnFailure 和 Never。**預設為 Always。 restartPolicy 适用于 Pod 中的所有容器。restartPolicy 僅指通過同一節點上的 kubelet 重新啟動容器。失敗的容器由 kubelet 以五分鐘為上限的指數退避延遲（10秒，20秒，40秒…）重新啟動，并在成功執行十分鐘後重置。pod一旦綁定到一個節點，Pod 将永遠不會重新綁定到另一個節點。

7.資源限制

limits是對資源的總限制、requests是最低配置設定的資源。requests一般要比limits要小一些。

250m/單核CPU的白分之25/0.25

資源限制 cpu可以直接設定為數字 “1”為1核“2”為2核。

記憶體超額>OOMKill

apiVersion: v1
kind: Pod
metadata:
  name: frontend
spec:
  containers:
  - name: db
    image: mysql
    env:
    - name: MYSQL_ROOT_PASSWORD
      value: "password"
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"