在Kubernetes中，pod是基本部署單位。它可以包含一個或多個作為邏輯實體打包和部署的容器。在Kubernetes中運行的雲原生應用程序可能包含多個一一映射到每個微服務的pod。pod也是Kubernetes的擴展單位。
下面是在Kubernetes中部署pod之前要遵循的五個最基本的最佳實踐。
1） 選擇最合適的Kubernetes控制器
雖然部署和運行一個容器鏡像（作為一個通用pod）是很有誘惑力的，但是你應該根據工作負載特性選擇正確的控制器類型。Kubernetes有一個稱為controller的原語，它與工作負載的關鍵特性相一致。Deployment、StatefulSet和DaemonSet是Kubernetes中最常用的控制器。
部署無狀態pod時，請總是使用部署控制器。這通過擴展、部署歷史和回滾特性將類似PaaS的功能引入pod。當一個部署配置了最少兩個副本計數時，Kubernetes確保至少兩個pod始終在運行，這帶來了容錯性。即使在部署只有一個副本的pod時，也強烈建議你使用部署控制器，而不是普通的pod規範。
對於數據庫集群等工作負載，StatefulSet控制器將創建一組具有可預測命名約定的高可用pod。需要高度可用的有狀態工作負載（如Cassandra、Kafka、ZooKeeper和SQL Server）在Kubernetes中部署為StatefulSet。
當需要在集群的每個節點上運行pod時，應該使用DaemonSet控制器。由於Kubernetes在新配置的工作節點中自動調度DaemonSet，因此它成為為工作負載配置和準備節點的理想候選。例如，如果你想在部署工作負載之前在節點上安裝現有的NFS或GLUSTER文件共享，那麼將pod打包並部署為DaemonSet。
在部署pod之前，請確保選擇了最合適的控制器類型。
2） 為pod配置健康檢查
默認情況下，所有正在運行的pod都將restart策略設置為always，這意味著當容器遇到錯誤時，在節點內運行的kubelet將自動重啟pod。
健康檢查通過容器探針的概念擴展了kubelet的這種能力。有三個探針可以為每一個pod配置：readiness、liveness、startup。
你可能會遇到pod處於運行狀態但ready列顯示0/1的情況。這表示pod尚未準備好接受請求。readiness探針確保在啟動pod之前滿足先決條件。例如，為機器學習模型提供服務的pod需要在提供推理之前下載模型的最新版本。readiness探針會在將pod移動到就緒狀態之前不斷檢查文件是否存在。類似地，CMS pod中的readiness探針將確保數據存儲已安裝並可訪問。
liveness探針將定期檢查容器的健康狀況，並向kubelet報告。當此健康檢查失敗時，pod不會接收流量。服務將忽略此pod，直到liveness探針報告正常狀態。例如，MySQL pod可能包含一個liveness探針，它持續檢查數據庫引擎的狀態。
從1.16版開始，startup探針仍然處於alpha中，它允許容器在將健康檢查移交給liveness探針之前等待更長的時間。這在將遺留應用程序移植到需要異常啟動時間的Kubernetes時非常有用。
以上所有健康檢查都可以配置為通過命令、HTTP探針和TCP探針配置。
3） 用Init Container準備pod
在某些情況下，容器在準備就緒之前需要初始化。初始化可以移動到另一個容器，以便在pod移動到就緒狀態之前完成基礎工作。init container可用於下載文件、創建目錄、更改文件權限等。
init container甚至可以用來確保pod是按特定順序啟動的。例如，在啟動WordPress pod之前，Init Container將一直等到MySQL pod可用。
一個pod可以包含多個init container，每個容器執行特定的初始化任務。
4） 應用Node/Pod Affinity和Anti-Affinity規則
Kubernetes調度器根據pod的資源需求和集群內的資源消耗，很好地將pod放置在相關節點上。但是，可能需要控制pod在節點上的調度方式。Kubernetes提供了兩種機制——node affinity/anti-affinity和pod affinity/anti-affinity.
node affinity擴展了已經很強大的nodeSelector規則來覆蓋其他場景。就像Kubernetes註釋使label/selector更具表現力和可擴展性一樣，node affinity通過附加規則使nodeSelector更具表現力。node affinity將確保在滿足特定條件的節點上調度pod。例如，可以強制在連接了SSD的節點上調度有狀態數據庫pod。類似地，node anti-affinity將有助於避免在可能導致問題的節點上調度pod。
雖然node affinity在pod和節點之間進行匹配，但可能存在需要co-locate pod以獲得性能或合規性的場景。pod affinity將幫助我們放置需要共享同一節點的pod。例如，Nginx web服務器pod必須調度在同時有Redis pod的節點上。這將確保web應用程序和緩存之間的低延遲。在其他情況下，你可能希望避免在同一節點上運行兩個pod。部署HA工作負載時，你可能希望強制同一pod的兩個實例不能在同一節點上運行。pod anti-affinity將強制執行防止這種可能性的規則。
分析工作負載，以評估是否需要使用node和pod affinity策略。
5） 利用Auto Scaler
像AWS、Microsoft Azure和Google Cloud Platform這樣的超大規模雲平臺都有內置的自動伸縮引擎，可以根據平均資源消耗或外部指標來伸縮VM群。
Kubernetes在水平pod自動縮放器（HPA）、垂直pod自動縮放器（VPA）和集群自動縮放的部署中具有類似的自動縮放功能。
水平pod自動縮放器根據觀察到的CPU利用率自動縮放複製控制器、部署、副本集或狀態集中的pod數。HPA在Kubernetes中表示為一個對象，這意味著可以通過由kubectl CLI控制的YAML文件來聲明它。與IaaS自動縮放引擎類似，HPA支持定義CPU閾值、pod的最小和最大實例、冷卻週期甚至自定義指標。
垂直pod自動縮放消除了定義pod的CPU和內存配置所涉及的猜測。這個自動縮放器能夠為CPU和內存請求和限制推薦適當的值，或者自動更新這些值。自動更新標誌將決定是否將刪除現有pod還是繼續使用舊配置運行。查詢VPA對象將通過上下限顯示最佳CPU和內存請求。
當HPA和VPA伸縮擴展部署和pod時，Cluster Autoscaler將擴展和縮小工作節點池的大小。它是一個獨立的工具，可以根據當前的利用率調整Kubernetes集群的大小。當存在由於資源不足而無法在任何當前節點上調度的pod時，或當添加新節點會增加集群資源的總體可用性時，自動縮放器將增加集群的大小。在幕後，Cluster Autoscaler與底層IaaS provider協商添加或刪除節點。HPA與Cluster Autoscaler相結合，提供了工作負載的最大性能和最高可用性。
