站在設計的角度上去考慮，任何乙個系統都會有優先順序的問題。最典型的栗子就是 作業系統的排程問題。分配之前的階段- 如何排pod的優先順序？如果學過作業系統，知道核心的排程流程，理解k8s的排程不會吃力。這其實就是學習的殊途同歸的地方，也是讀核心原始碼最大的魅力。
對於k8s也同樣是。不過k8s的排程問題沒有作業系統排程那麼複雜。簡單的來學習一下吧！
分配之後的階段-當資源不足時，如何搶占資源？
搶占策略是什麼？
對於提交的pod的申請，一定會有輕重緩急。比如，機器資源 90g記憶體。四個pod，乙個20g，那麼最後乙個pod肯定得不到分配。假如前邊的pod不是那麼重要，或者說優先順序沒有那麼高，則可以先把前邊的關了，先把後邊的pod起來。
在實際生產中，如果使用先到先得策略，是一種不公平的策略，因為公司業務裡面肯定是有高優先順序的業務和低優先順序的業務，所以優先順序策略會比先到先得策略更能夠符合日常公司業務特點。
接著介紹一下優先順序策略下的優先順序排程是什麼樣的乙個概念。比如說有乙個 node 已經被乙個 pod 占用了，這個 node 只有 2 個 cpu。另乙個高優先順序 pod 來的時候，低優先順序的 pod 應該把這兩個 cpu 讓給高優先順序的 pod 去使用。低優先順序的 pod 需要回到等待佇列，或者是業務重新提交。這樣的流程就是優先順序搶占排程的乙個流程。
在 kubernetes 裡，podpriority 和 preemption，就是優先順序和搶占的特點，在 v1.14 版本中變成了 stable。並且 podpriority 和 preemption 預設都是開啟的。
如何使用優先順序排程呢？需要建立乙個priorityclass，然後再為每個 pod 配置上不同的 priorityclassname，這樣就完成了優先順序以及優先順序排程的配置。
對於都未分配資源的pod，進入排程佇列以後，則根據優先順序來優先的分配資源。比方pod1和pod2，pod2的優先順序比較高，它們都在任務佇列，則下次資源分配一定是先分配pod2。
其實資源搶占，也是資源合理利用的一種手段。因為策略是由人定的，人可以根據任務的優先順序，來分配排程的優先順序。當資源不足時，具有優先順序的理應優先使用資源，可以把搶占優先順序低的pod的資源，從而做到資源最合理的利用。
上圖右側是整個優先順序搶占的排程流程，也就是 kube-scheduler 的工作流程。首先乙個 pod 進入搶占的時候，會判斷 pod 是否擁有搶占的資格，有可能上次已經搶占過一次。如果符合搶占資格，它會先對所有的節點進行一次過濾，過濾出符合這次搶占要求的節點，如果不符合就過濾掉這批節點。
接著從過濾剩下的節點中，挑選出合適的節點進行搶占。這次搶占的過程會模擬一次排程，也就是把上面優先順序低的 pod 先移除出去，再把待搶占的 pod 嘗試能否放置到此節點上。然後通過這個過程選出一批節點，進入下乙個過程叫 processpreemptionwithextenders。這是乙個擴充套件的鉤子，使用者可以在這裡加一些自己搶占節點的策略，如果沒有擴充套件的鉤子，這裡面是不做任何動作的。
接下來的流程叫做 pickonenodeforpreemption，就是從上面 selectnodeforpreemption list 裡面挑選出最合適的乙個節點，這是有一定的策略的。上圖左側簡單介紹了一下策略：
通過這五步序列策略過濾之後，會選出乙個最合適的節點。然後對這個節點上待搶占的 pod 進行 delete，這樣就完成了一次待搶占的過程。
k8s排程 原理 K8s排程原理和Pod生命週期
1 k8s排程原理 pod只存在某乙個物理節點上，可以執行多個container 2 pod的生命週期 暫停pod，可以暫停deployment kubectl get depolyment kubectl scale replicas 0 deployment 刪除pod。刪除之後，狀態變成suc...
k8s 問題跟進
大多數情況下，問題大多出在pod本身，我們可以按照如下命令進行分析定位問題 kubectl get pod 檢視是否存在不正常的pod kubectl describe pod podname n kube system journalctl u kubelet n 1000 a.txt 檢視kub...
K8s排程演算法註冊流程
我的k8s集群是二進位制搭建的，因此我在二進位制檔案中新增我的排程演算法，並且在相關檔案中註冊我的演算法。在kubernetes server二進位制檔案中 kubernetes pkg scheduler下有algorithm 和 algorithmprovider兩個模組 algorithm模組...