kubernetes從入門到精通系列目錄：
Master 主要是運行集群的控制平面組件的，apiserver、scheduler、controlermanager，Master 還依賴與 etcd 這樣的存儲節點。
kubeadm 部署的集群會將 Master 的控制組件都運行為靜態 POD 了，從本質來講，這些組件就是運行在 Master 節點專為集群提供服務的進程，Master 是不負責運行工作負載的。
node 節點是負責運行工作負載 POD 的相關節點，用戶只需要將運行任務提交給 Master 就可以了，用戶無需關心運行在哪個 node 節點上，Master 整合了所有 node 為一個虛擬的資源池。
17.1 POD創建流程
用戶創建的任務最終應該運行在哪個 node 節點上，是由 Master 節點上的 scheduler 決定的，而 scheduler 也是允許用戶定義它的工作特性的，默認情況下，我們沒有定義它，其實是使用的默認的 scheduler 調度器。
當我們使用 kubectl describe pods myapp 查看 POD 信息時候，會有一個 Events 字段中，有關於調度結果的相關信息。
Scheduler 會從眾多的 node 節點中挑選出符合 POD 運行要求的節點，然後將選定的 node 節點信息記錄在 etcd 中，kubelet 始終 waitch 著 apiserver 上的關於本節點的信息變化，kubelet 就會去 apiserver 獲取關於變化信息的配置清單，根據配置清單的定義去創建 POD。
17.2 Service創建過程
當用戶創建一個 service 的時候，這個請求會提交給 apiserver，apiserver 將清單文件寫入 etcd 中，然後每個 node 節點上的 kube-proxy 會 waitch apiserver 關於 service 資源的相關變動，發生變化時候，每個節點的 kube-proxy 會將 service 創建為 iptables/ipvs 規則。
從通信角度來講：kubectl、kubelet、kube-proxy 都是 apiserver 的客戶端，這些組件與 apiserver 進行交互時候，數據格式為 json，內部的數據序列化方式為 protocolbuff。
17.3 資源限制維度
- 資源需求：運行 POD 需要的最低資源需求
- 資源限制：POD 可以佔用的最高資源限額
17.4 Scheduler 調度過程
- 預選階段：排除完全不符合運行這個 POD 的節點、例如資源最低要求、資源最高限額、端口是否被佔用
- 優選階段：基於一系列的算法函數計算出每個節點的優先級，按照優先級排序，取得分最高的 node
- 選中階段：如果優選階段產生多個結果，那麼隨機挑選一個節點
- POD 中影響調度的字段，在 kubectl explain pods.spec 中
<code>nodeName # 直接指定 POD 的運行節點
nodeSelector # 根據 node 上的標籤來對 node 進行預選，這就是節點的親和性
/<code>
- 其他影響調度的因素
節點親和性調度：表現為 nodeSelector 字段
POD 間親和性：POD 更傾向和某些 POD 運行在一起，例如同一個機房、同一個機器
POD 間反親和性：POD 和某 POD 更傾向不能運行在一起，這叫反親和性，例如：監聽同一個 nodeport，有機密數據的
Taints（汙點）：給某些 node 打上汙點，
Tolerations（汙點容忍）：一個 POD 能夠容忍 node 上的汙點，如果運行過程中 node 出現新的汙點，那麼 POD 可以
驅逐POD：node 給一個限定的時間，讓 POD 離開這個節點。
17.4 預選因素
下面的預選條件需要滿足所有的預選條件才可以通過預選
- CheckNodeConditionPred
<code>檢查節點是否正常
/<code>
- GeneralPredicates
子策略作用HostName檢查主機名稱是不是 pod.spec.hostname 指定的 NodeNamePodFitsHostP orts檢查 Pod 內每一個容器 pods.spec.containers.ports.hostPort 清單是否已被其它容器佔用，如果有所需的 HostPort 不滿足需求，那麼 Pod 不能調度到這個主機上MatchNodeSel ector檢查 POD 容器上定義了 pods.spec.nodeSelector 查看 node 標籤是否能夠匹配PodFitsResou rces檢查 node 是否有足夠的資源運行此 POD 的基本要求
- NoDiskConflict（默認沒有啟用）
<code>檢查 pod 定義的存儲是否在 node 節點上使用。
/<code>
- PodToleratesNodeTaints
<code>檢查節點的汙點 nodes.spec.taints 是否是 POD 汙點容忍清單中 pods.spec.tolerations 的子集
/<code>
- PodToleratesNodeNoExecuteTaints
<code>檢查 pod 是否容忍節點上有 NoExecute 汙點。NoExecute 這個汙點是啥意思呢。如果一個 pod 上運行在一個沒有汙點的節點上後，這個節點又給加上汙點了，那麼 NoExecute 表示這個新加汙點的節點會驅逐其上正在運行的 pod；不加 NoExecute 不會驅逐節點上運行的 pod，表示接受既成事實，這是默認策略。
/<code>
- CheckNodeLabelPresence（默認沒有啟用）
<code>檢查節點上指定標籤的存在性，如果節點有pod指定的標籤，那麼這個節點就被選中。
/<code>
- CheckServiceAffinity（默認沒有啟用）
<code>一個 Service 下可以有多個 POD，比如這些 POD 都運行在 1、2、3 機器上，而沒有運行在 4、5、6 機器上，那麼CheckServiceAffinity 就表示新加入的 POD 都集中運行在 1、2、3 機器上，這樣集中好處是一個 Service 下 POD 之間內部通信的效率變高了。
/<code>
- MaxEBSVolumeCount
<code>確保已掛載的亞馬遜 EBS 存儲卷不超過設置的最大值，默認39
/<code>
- MaxGCEPDVolumeCount
<code>確保已掛載的GCE存儲卷不超過設置的最大值，默認16
/<code>
10 MaxAzureDiskVolumeCount
<code>確保已掛載的Azure存儲卷不超過設置的最大值，默認16
/<code>
- CheckVolumeBinding
<code>檢查節點上的 PVC 是否被別的 POD 綁定了
/<code>
- NoVolumeZoneConflict
<code>檢查給定的 zone (機房) 限制前提下，檢查如果在此主機上部署 POD 是否存在卷衝突
/<code>
- CheckNodeMemoryPressure
<code>檢查 node 節點上內存是否存在壓力
/<code>
- CheckNodeDiskPressure
<code>檢查磁盤 IO 是否壓力過大
/<code>
- CheckNodePIDPressure
<code>檢查 node 節點上 PID 資源是否存在壓力
/<code>
- MatchInterPodAffinity
<code>檢查 Pod 是否滿足親和性或者反親和性
/<code>
17.5 優選函數
在每個節點執行優選函數，將結果每個優選函數相加，得分最高的勝出。
- least_requested.go
<code>選擇消耗最小的節點（根據空閒比率評估 cpu(總容量-sum(已使用)*10/總容量)）
/<code>
- balanced_resource_allocation.go
<code>均衡資源的使用方式，表示以 cpu 和內存佔用率的相近程度作為評估標準，二者佔用越接近，得分就越高，得分高的勝出。
/<code>
- node_prefer_avoid_pods.go
<code>看節點是否有註解信息 "scheduler.alpha.kubernetes.io/preferAvoidPods" 。沒有這個註解信息，說明這個節點是適合運行這個 POD 的。
/<code>
- taint_toleration.go
<code>將 pods.spec.tolerations 與 nodes.spec.taints 列表項進行匹配度檢查，匹配的條目越多，得分越低。
/<code>
- selector_spreading.go
<code>查找當前 POD 對象對應的 service、statefulset、replicatset 等所匹配的標籤選擇器，在節點上運行的帶有這樣標籤的 POD 越少得分越高，這樣的 POD 優選被選出。 這就是說我們要把同一個標籤選擇器下運行的 POD 散開(spreading)到多個節點上。
/<code>
- interpod_affinity_test.go
<code>遍歷 POD 對象親和性的條目，並將那些能夠匹配到節點權重相加，值越大的得分越高，得分高的勝出。
/<code>
- most_requested.go
<code>表示儘可能的把一個節點的資源先用完，這個和 least_requested 相反，二者不能同時使用。
/<code>
- node_label.go
<code>根據節點是否擁有標籤，不關心標籤是什麼，來評估分數。
/<code>
- image_locality.go
<code>表示根據滿足當前 POD 對象需求的已有鏡的體積大小之和來選擇節點的。
/<code>
- node_affinity.go
<code>根據 POD 對象中的 nodeselector，對節點進行匹配度檢查，能夠成功匹配的數量越多，得分就越高。
/<code>
17.6 選擇函數
當通過優選的節點有多個，那麼從中隨機選擇一臺
閱讀更多 Echa攻城獅 的文章
