一、scheduler介紹

　　scheduler主要任務按照一定規則把定義的pod分配到叢集的node上。scheduler作為單獨的程式執行，啟動之後會一直監聽API server，獲取podSpec.NodeName為空的pod，對每個pod都會建立一個binding，表明該pod應該放到哪個node上。排程會考慮到很多問題：
　　效率：排程的效能要好，能夠儘快地對大批量的pod完成排程工作；
　　公平：如何保證每個節點都能被分配資源；
　　資源高效利用：叢集所有資源最大化被使用；
　　靈活：允許使用者根據自己的需求控制排程的邏輯。
排程過程：
　　1）過濾掉不滿足條件的node，這個過程稱為predicate；如果在predicate過程中沒有合適的節點，pod會一直在pending狀態，不斷重試排程，直到有節點滿足條件。經過這個步驟，如果有多個節點滿足條件，就繼續priority過程。
　　2）對通過的node按照優先順序排序，該過程稱為priority；
　　3）最後從中選擇優先順序最高的node。
　　該過程任何一步驟錯誤，就直接返回錯誤。
predicate有一系列的演算法可以使用：
　　podFitsResources：節點上剩餘的資源是否大於pod請求的資源；如果不滿足，直接pass掉該node。
　　podFitsHost：如果pod指定了nodeName，檢查節點名稱是否和NodeName匹配；如果不滿足，直接pass掉該node。
　　podFitsHostPorts：節點上已經使用的port是否和pod申請的port衝突；如果不滿足，直接pass掉該node。
　　podSelectorMatches：過濾掉和pod指定的label節點是否匹配；如果不匹配，直接pass掉該node。
　　NoDiskConflict：已經mount的volume和pod指定的volume是否衝突；如果衝突，直接pass掉該node，除非它們都是隻讀。
priority：優先順序由一系列鍵值對組成，鍵是該優先順序項的名稱，值是它的權重（該項的重要性）。這些優先順序選型包括：
　　LeastRequestedPriority：通過計算CPU和memory的使用率來決定權重，使用率越低權重越高。換句話說，這個優先順序指標傾向於資源使用比例更低的節點。
　　BalanceResourceAllocation： 節點上CPU和memory使用率越接近，權重越高；該鍵與上面的鍵一起使用，不應單獨使用。
　　ImageLocalityPriority：傾向於已經有要使用映象的節點，映象總大小值越大，權重越高。
　　通過演算法對所有的優先順序專案和權重進行計算，得出最終結果。
自定義排程器：
　　除了K8S自帶的排程器default-scheduler，你可以編寫自己的排程器。通過spec:schedulername引數指定排程器的名字，可以為pod選擇某個排程器進行排程。
node親和性
　　pod.spec.affinity.nodeAffinity
　　preferredDuringSchedulingIgnoredDuringExecution:軟策略，pod優先排程到該node;若不滿足則可進行其他排程；pod有多個軟策略時，則會優先選擇權重較高的node；
　　requiredDuringSchedulingIgnoredDuringExecution:硬策略，pod必須排程到該node；若不滿足則不排程，會報錯；

kubectl get node --show-labels #查詢node的label；

kubernetes.io/hostname為鍵名，k8s-node02為鍵值。

鍵值運算關係：
　　In:label的值在某個列表中；
　　NotIn：label的值步在某個列表中；
　　Gt：label的值大於某個值；
　　Lt：label的值小於某個值；
　　Exists:某個label存在；
　　DosesNotExist：某個label不存在；

pod親和性
　　pod.spec.affinity.podAffinity/podAntiAffinity
　　preferredDuringSchedulingIgnoredDuringExecution:軟策略，；
　　requiredDuringSchedulingIgnoredDuringExecution:硬策略；
親和性/反親和性排程策略比較如下：

案例1：node親和性---硬策略

cat >node_hard_policy.yaml<<eof
apiVersion: v1
kind: Pod
metadata:
    name: nod-affinity-required
    labels:
        app: nod-affinity-required
spec:
    containers:
    - name: nod-affinity-required
      image: hub.atguigu.com/library/nginx:latest
    affinity:
        nodeAffinity:
            requiredDuringSchedulingIgnoredDuringExecution:
                nodeSelectorTerms:
                - matchExpressions:
                  - key: kubernetes.io/hostname
                    operator: NotIn
                    values:
                    - k8s-node02
eof
kubectl apply -f node_hard_policy.yaml
kubectl get pod -o wide
kubectl delete -f node_hard_policy.yaml
kubectl get pod -o wide
kubectl apply -f node_hard_policy.yaml
kubectl get pod -o wide
kubectl delete -f node_hard_policy.yaml
kubectl apply -f node_hard_policy.yaml
kubectl get pod -o wide

結果顯示：硬策略要求必須每次不能排程到node2節點。當修改為IN時，會立即排程到node2；當修改為排程到不存在的node時，則會任務會pending。

案例2：