• 當你在 pod.spec 設定 nodeselector 的時候，kubernetes 是怎麼找到合適的 Node？為

• 什麼我們不會看到 Hot Spot Node，也就是一個 Node 上面出現 30+ Pod，但是另一個 Node 卻一個都沒有？

這兩個問題可以瞭解 kube-scheduler 的兩個階段： Filter 以及 Score。

kube-scheduler 的排程算法主要有兩個階段，第一個階段是 Filter，篩選符合資格的 Node，再來是 Score 階段，會根據策略為篩選過後的 Node 計算分數，然後根據分數把 Pod 排程到分數最高的 Node 上。

NodeSelector 作用於 Filter 這個一階段，如果 pod.spec 裡面有設定 nodeSelector，Filter 階段會根據 nodeSelector 篩選符合資格的 Node。

篩選之後，kube-scheduler 會根據 Node 上面的 CPU, Memory計算分數，其算法是透過 NodeResourcesFit 來達成。

我們藉由兩個使用情境介紹了 kube-scheduler 的兩階段算法，但是如果想要處理更複雜的業務要怎麼辦？

如果你在每一個 Zone 配置 30 個 Node，但 kube-proxy 只會把每一個 Pod 放到 routing table，於是，為了減少不必要的東西向流量，你啟用了 Topology Aware Routing，希望讓 frontend Pod 可以溝通在同一個 Zone。

這麼做解決了網路拓樸問題後，你想要確保每一個 AZ，甚至每一個 Node 上面都有至少一對 frontend 以及 backend，你該怎麼做？

如果你的資料庫，以 AWS RDS 為例，放在 A-zone，所以你希望 backend 靠近 A-zone，所以你用了 nodeselector 把 backend 佈署到 A-zone。 但是你的 AWS RDS 有啟動 Multiple-AZ 的功能，當 A-zone 出現問題的時候會 Failover 到 B-zone，由於用了 NodeSelector，這時候你的 Pod 不會跟者 failover 到 zone-b，資料庫過去了但是 backend 沒有過去，造成了 P0 事件，我們要怎麼避免？

由於應用情境會有不同的需求，Kubernetes 要怎麼讓用戶靈活地制定排程策略？

於是，迎接了 Kubernetes Scheduler Framework。