k8s系列文章：
Pod是k8s中最小的調度單元，包含了一個“根容器”和其它用戶業務容器。
如果你使用過k8s的話，當然會瞭解pod的基本使用，但是爲了更好的應用，你需要深入瞭解pod的配置、調度、升級和擴縮容等。本文將會更進一步的介紹pod。
基礎
爲什麼需要pod？
pod包含一個或多個相對緊密耦合的容器，處於同一個pod中的容器共享同樣的存儲空間、IP地址和Port端口。
爲什麼k8s要設計出Pod這個概念並作爲最小調度單元呢？
直接部署一個容器可能會更加容易，每個容器都有不同的配置和功能，k8s需要對這些容器進行管理（重啓、檢測等），那麼爲了避免在容器這個實體上增加更多的屬性，就產生了pod這個概念。
並且，Pod中的多個業務容器共享Pause容器的IP，共享Pause容器掛接的Volume，這樣既簡化了密切關聯的業務容器的通信問題，也很好的解決了它們之間的文件共享問題。
容器配置
pod可以由一個或多個容器組合而成，也就是說， 在創建pod時可以給一個pod配置多個container，一般情況下，建議將應用緊耦合的容器打包爲一個pod，原則上一個容器一個進程。
共享Volume
同一個pod中的多個容器能夠共享pod級別的存儲卷Volume，多個容器各自掛載，將一個volume掛載爲容器內部需要的目錄。
Pod通信
k8s爲每個pod都分配了唯一的IP地址，稱之爲pod IP，一個pod中的多個容器共享Pod IP地址，屬於同一個pod的多個應用之間相互訪問時僅通過localhost就可以通信。
k8s底層支持集羣內任意兩個pod之間的TCP/IP直接通信，因此，在k8s中，一個pod中的容器可以與另外主機上的pod裏的容器直接通信。
容器限制
需要注意的是：pod中長時間運行的容器需保證其主程序一直在前臺運行。比如創建docker鏡像時啓動命令是通過nohup在後臺運行的：
nohup ./start.sh &
那麼kubelet創建了包含這個容器的pod之後運行完這個命令，則會根據配置發生兩種情況：
- 如果pod未配置RC，則認爲該pod執行結束，將立刻銷燬該pod。
- 如果pod配置了RC，該pod終止以後，k8s會根據RC的數量生成新的pod，會陷入一個 銷燬-> 創建的無限循環中。
如果無法前臺執行，只能後端運行的話，該怎麼辦呢？
可以藉助supervisor。
配置管理
應用部署的一個最佳實踐就是將配置信息和程序進行分離，在k8s中可以使用configmap實現。
詳細使用可參考：K8S configmap使用
生命週期和重啓策略
在創建pod出錯了，通常會看到pending狀態，而你使用 kubectl get pods 時，也偶爾會看到重啓這個字段，那麼pod的生命週期和重啓策略具體是怎麼實現的呢？
一個pod的狀態信息是保存在PodStatus對象中的，phase字段用來描述pod在其生命週期中的不同狀態，包括：
| 狀態 | 說明 |
|---|---|
| Pending | 掛起。有一個或多個容器未被創建，可以通過kubectl get po ** 查看原因。 |
| running | 運行中。所有容器已被創建，至少有一個是運行狀態，可通過kubectl logs -f ** 查看日誌 |
| succeeded | 成功。所有容器執行成功並終止，不會再次重啓。 |
| failed | 失敗。所有容器都已終止，至少有一個容器以失敗的方式終止。 |
| unknown | 未知。一般是因爲通信問題無法獲取pod的狀態 |
Pod通常使用探針來檢測容器內的應用是否正常，有兩類探針：
- LivenessProbe探針：判斷容器是否存活（Running狀態）
- ReadinessProbe探針：判斷容器是否可用（Ready狀態）
在Pod發生故障時對Pod進行重啓（僅在Pod所處的Node上操作），具體的方式包括：
| 操作方式 | 說明 |
|---|---|
| Always | 容器失效時，自動重啓 |
| OnFailure | 容器以不爲0的狀態碼終止，自動重啓 |
| Never | 無論何種狀態，都不會重啓 |
其中，Pod的重啓策略與控制方式息息相關，不同的控制器對pod的重啓策略要求不一樣：
- RC和DaemonSet：必須設置爲Always，需要保證容器持續運行
- Job：onfailure或者Never，保證容器執行完成後不再重啓。
Pod調度
在使用K8S時，我們很少直接創建Pod，大多數情況都是會通過RC、Deployment、DaemonSet、Job等控制器來實現對一組Pod副本的創建、調度和全生命週期的自動控制。
官方建議：不應該使用底層的ReplicaSet來控制Pod副本，推薦直接使用管理ReplicaSet的Deployment對象來控制Pod副本。
全自動調度
Deployment或RC的主要功能之一就是自動部署一個容器應用的多份副本，持續監控副本的數量，保證集羣內始終維持指定的副本數量。創建的pod完全由系統自動完成調度，pod各自運行在哪個節點上，完全由master scheduler計算出一個最佳的目標節點進行分配，用戶無法干預。
舉個例子：
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx
spec:
replicas: 3
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.0
ports:
- containerPort: 80
使用kubectl create -f **.yaml創建該Deployment。
使用kubectl get deployments，就會發現剛纔創建的deployment有三個副本。
使用kubectl get rs和kubectl get pods可查看已創建的RS和pod，使用kubectl get pod -o wide可以查看pod的分配情況。
定向調度
在實際應用中，經常會需要將Pod調度到指定的一些Node節點上，這時候可配置NodeSelector或者NodeAffinity來進行定向調度。
NodeSelector
具體的使用：
- 通過kubectl label命令給目標Node打上標籤，可通過kubectl label nodes命令查看所有節點的標籤；
- 在Pod的定義中加上NodeSelector的設置
- 運行kubectl create -f 命令創建Pod時，scheduler就會將pod自動調度指定標籤的Node上。
NodeAffinity（節點親和力調度）
NodeSelector通過標籤機制，簡單的限制了Pod所在節點的方法，親和力調度機制則更好擴展了Pod的調度能力，可以使用軟限制，支持In、NotIn、Exists、DoesNotExist、Gt、LT等操作符。
- 可依據節點上正在運行的其它Pod的標籤來進行限制，而非節點本身的標籤。
需要注意以下幾點：
- 如果同時定義了nodeSelector和nodeAffinity，則必須兩個條件都滿足
- 如果nodeAffinity指定了多個nodeSelectorTerms，則其中一個匹配成功即可。
- 如果nodeSelectorTerms中有多個matchExpressions。則一個節點必須滿足所有matchExpressions才能運行該Pod
PodAffinity（Pod親和與互斥調度）
根據節點上正在運行的Pod標籤而非節點的標籤進行判斷和調度，對節點和Pod兩個條件進行匹配。
具體的使用：
- 創建一個名爲pod-flag的pod，設置標籤
- 親和性調度：創建pod-flag在同一個Node節點的pod
- 互斥性調度：可創建與pod-flag不在同一個Node節點的pod
DaemonSet
用於管理在集羣的每個Node上僅運行一份pod的副本實例。適用場景：日誌採集、性能監控等。
優先調度
爲了提高資源利用率，我們通常會採用優先級方案，即不同類型的負載對應不同的優先級，並且當發生資源不足時，系統可以選擇釋放一些不重要的負載，保障最重要的負載以獲取足夠的資源穩定運行。
優先級搶佔調度策略的有兩個核心點：
- 驅逐（Eviction）：kubelet的行爲，當一個Node發生資源不足時，該結點上的kubelet進程會綜合考慮優先級、資源申請量和實際資源使用等進行驅逐
- 搶佔（Preemption）：scheduler的行爲，當一個新的pod因資源無法滿足而不能調度時，scheduler可能會選擇（跨節點或本節點）驅逐部分低優先級的pod實例來滿足調度
批處理調度 Job
可以通過Job來定義並啓動一個批處理任務（並行啓動多個進程去處理一些工作項），處理完成後，整個批處理任務結束。
定時任務 Cronjob
類似Linux Cron的定時任務Cron Job。
除此以外，你還可以自定義調度器。
升級和回滾
爲了保證服務的高可用，k8s提供了滾動升級功能。主要介紹下deployment。
Deployment
升級
更新鏡像名的話，有以下方法進行更新：
- 通過
kubectl set image命令設置新的鏡像名 - 使用
kubectl edit命令修改Deployment的配置，根據yaml的結構更新（比如：將spec.template.spec.containers[0].image從nginx:1.0改爲nginx:1.1）。
對於RC的滾動升級，可以使用kubectl rolling-update命令，該命令會創建一個新的RC，自動控制舊的RC中pod副本數量逐漸減少到0，新的RC中的Pod副本數量從0逐步增加到目標值。
一旦pod的定義發生了修改，則將觸發系統完成Deployment中所有pod的滾動操作，可使用kubectl rollout status查看滾動更新過程。
在升級過程中，deployment能夠保證服務不中斷，並且副本數量始終維持在用戶指定數量。可在Deployment定義中，通過spec.strategy指定pod的更新策略，包括：
- Recreate 重建
- RollingUpdate 滾動更新
回滾
服務穩定性或者配置錯誤等原因會使得我們需要進行回滾，Deployment的所有發佈歷史記錄都被保留在系統中，所以回滾是很方便的。具體操作：
- 用kubectl rollout history查看deployment的部署歷史記錄，確定要回退的版本，可以加上--revision=
參數查看特定版本詳情 - 回退到上一個版本或者指定版本
- kubectl describe deployment查看操作過程
對於相對複雜的配置修改，爲了避免頻繁大量觸發更新操作，可使用kubectl rollout pause命令暫停更新操作，然後進行配置修改，最後恢復deployment，一次性觸發完整的更新操作。
擴縮容
伴隨着資源的使用情況，常需要對pod進行擴縮容，可以利用Deployment/RC的Scale機制來實現，分爲手動和自動兩種模式。
手動
通過kubectl scale deployment *** --replicas 3命令更新Pod副本數量，將--replicas設置比當前pod副本數量更小的數字的話，系統會kill一些正在運行的pod。
自動
用戶指定pod副本的數量範圍，設定依據的性能指標或者自定義業務指標，系統將自動的在這個範圍內根據性能指標變化調整pod副本數量。
k8s 1.1版本開始新增了HPA控制器，基於Master的kube-controller-manager服務啓動參數--horizontal-pod-autoscal-sync-period定義的探測週期，週期性檢測目標pod的資源性能指標。並與設定的擴容條件進行對比，進行pod副本數量的自動調整。
以上。