# . Pod調度 在kubernetes系統中，Pod在大部分場景下都只是容器的載體而已，通常需要通過RC、Deployment、 DaemonSet、Job等對象完成Pod的調度和自動控制功能。 1）RC、Deployment：全自動調度 RC的主要功能之一就是自動部署一個容器應用的多份副本，以及繼續監控副本的數量，在集群內始終維持用戶指定的副本數量。 a）NodeSelector：定向調度 b）NodeAffinity：親和性調度 2）DaemonSet：特定場景調度 DaemonSet是kubernetes1.2版本新增的一種資源對象，用于管理在集群中每個Node上僅運行一份Pod的副本實例。 DaemonSet的Pod調度策略與RC類似，除了使用系統內置的算法在每臺Node上進行調度，也可以在Pod的定義中使用NodeSelector或NodeAffinity來指定滿足條件的Node范圍進行調度。 3）Job：批處理調度 kubernetes從1.2版本開始支持批處理類型的應用，我們可以通過kubernetes Job資源對象來定義并啟動一個批處理任務。批處理任務通常并行啟動多個計算進程去處理一批工作項，處理完成后，整個批處理任務結束。 按照批處理任務實現方式的不同，分為： Job Template Expansion模式 Queue with Pod Per Work Item模式 Queue with Variable Pod Count模式 kubernetes將Job分以下三種類型。 1）Non-parallel Jobs 2）Parallel Jobs with a fixed completion count 3）Parallel Jobs with a work queue # . Pod的擴容和縮容 在實際生產系統中，我們經常會遇到某個服務需要擴容的場景，也可能會遇到由于資源緊張或者工作負載降低而需要減少服務實例數量的場景。此時我們可以利用RC的Scale機制來完成這些工作。以redis-slave RC為例，已定義的最初副本數量為2，通過kubectl scale命令可以將redis-slave RC控制的Pod副本數量從初始的2更新為3： #kubectl scale rc redis-slave --replicas=3 將--replicas設置為比當前Pod副本數量更小的數字，系統將會“kill掉”一些運行中的容器，以實現應用集群縮容： #kubectl scale rc redis-slave --replicas=1 除了scale方式，還有一種Horizontal Pod Autoscaler(HPA）方式 # . Pod滾動升級 當集群中的某個服務需要升級時，我們需要停止目前與該服務相關的所有Pod，然后重新拉取鏡像并啟動，如果集群規模比較大，則這個工作就變成了一個挑戰，而且先全部停止然后逐步升級的方式會導致較長時間的服務不可用。 滾動升級通過執行kubectl rolling-updata命令一鍵完成，該命令創建一個新的RC，然后自動控制就得RC中的Pod副本的數量逐漸減少到0，同時新的RC中的Pod副本的數量從0逐步增加到目標值，最終實現了Pod的升級。需要注意的是，系統要求新的RC需要與舊的RC在相同的命名空間（Namespace）內，不能吧別人的資產偷偷的轉移到自家名下。 需要注意： （1）RC的名字不能與舊的RC名字相同 （2）在Selector中應至少有一個Label與舊的RC的label不同，以標示其為新的RC。 運行kubectl rolling-update redis-master -f redis-masterController-v2.yaml等所有新的Pod啟動完成后，舊的Pod也被全部銷毀，這樣就完成了容器集群的更新工作。 另一種方法，不用配置文件，直接用kubectl rolling-update命令，加上--image參數指定新版鏡像名稱來完成Pod的滾動升級： #kubectl rolling-update redis-master --image=redis-master:2.0 更新后查看RC #kubectl get rc 如果在更新的過程中發現配置有誤，用戶可以中斷更新操作，并通過執行kubectl rolling-update-rollback完成Pod版本的回滾： #kubectl rolling-update redis-master --image=kubeguide/redis-master:2.0 --rollback 就可以恢復到更新前的版本了。