Kubernetes Scheduler 的作用是將待調度的 Pod 按照一定的調度算法和策略綁定到集群中一個合適的 Worker Node（以下簡稱 Node） 上澎办，并將綁定信息寫入到 etcd 中赛惩，之后目標 Node 中 kubelet 服務通過 API Server 監(jiān)聽到 Scheduler 產生的 Pod 綁定事件獲取 Pod 信息，然后下載鏡像啟動容器
從步驟上分為兩步：
- 預選，K8S會遍歷當前集群中的所有 Node榕莺，篩選出其中符合要求的 Node 作為候選
- 優(yōu)選俐芯，K8S將對候選的 Node 進行打分
當我在試著理解這兩個步驟的過程中，我不禁問了自己一個問題：如果沒有k8s這種容器編排系統钉鸯，也沒有docker, 同樣也面臨著大規(guī)模服務部署吧史，應該怎么做？
假設開發(fā)使用java完成了服務fun開發(fā)工作唠雕，然后將fun打成jar包扔給我部署（傳統部署常規(guī)操作）贸营，我只有有限的物理機，這些物理機上也零散的部署了其它服務岩睁，這個時候我會想一個問題：我應該將這個服務部署在哪臺機器上钞脂？
首先能想到的是找資源最空閑的機器，資源包括：
- CPU
- 內存
- 硬盤
...
也就是收集各物理機的可用資源進行編譯捕儒，如（cpu+內存+硬盤）
- s1: 2cpu+2G+20G
- s2: 1cpu+3G+10G
- s3: 5cpu+1G+200G
...
假設服務fun需要的資源是：0.2cpu+0.5G+1G冰啃，很顯然，前3臺機器都可以滿足需求刘莹，那為了保險起見阎毅，剩余可用資源當然是越多越好，那現在這種看似都可選的情況該如何是好呢点弯？我能想的是排序扇调，根據什么排序？權重抢肛，fun對資源的依賴也有權重的狼钮，比如權重由大到小的排序是 cpu->內存->硬盤， 權值分別為：3捡絮，2燃领，1
根據加權得到的結果是：
- s1: 2cpu+2G+20G -> 23+22+20=30
- s2: 1cpu+3G+10G -> 13+32+10=19
- s3: 5cpu+1G+200G -> 53+12+200=217
...
從我們定義的權重規(guī)則計算得到的結果看s3得分最高，所以目前s3是最佳選擇
這里可能存在一個問題锦援，就是比如我有1w臺機器猛蔽，那就需要獲取這1w臺機器的可用cpu、可用內存灵寺、可用硬盤曼库，然后加權，排序略板，取得分最高的機器毁枯，假設每臺機器獲取可用資源用時:1ms，那1w臺就需要10s, 這是相當可觀的時間叮称，假如最后的結果只有s1,s2,s3滿足條件种玛，也就是說剩余的9997臺機器是不符合需求的藐鹤，這基本上最差的情況的，此時應該如何赂韵？尋求局部最優(yōu)解
- 全局最優(yōu)： 1w臺機器里面加權后得分最高的機器
- 局部最優(yōu)： 前10臺機器里面加權后得分最高的機器
如果需要高可用部署娱节，我們往往需要部署多個服務實例，比如說3個fun祭示，高可用是為了避免其中某個實例因意外比如宕機而引起服務不可用肄满，那顯然最好的方式是fun服務分別部署在三臺不同的物理機上，也就是說fun服務的三個實例在物理機上部署是互斥的质涛。
再比如：fun服務需要強依賴服務dp稠歉，從通信角度講，本機通信顯然要比跨主機通訊要快也更穩(wěn)定汇陆，所以此時我更傾向于將fun與dp部署在一臺主機上怒炸。
在了解k8s的調度器之前我不會想到這些問題，初步了解之后毡代，就有些先入為主了横媚，k8s的調度所做的事情，在傳統運維部署的過程中月趟，同樣也會遇到灯蝴，或許也是這樣做的，所以會想到一個問題孝宗？k8s到底解決了什么問題穷躁？
首先k8s肯定解決了調度問題？上述的fun服務往往不是孤單的因妇，它需要依賴服務dp问潭，同樣其它服務也需要依賴fun，就依賴就需要知道服務地址婚被，那就需要服務發(fā)現了狡忙？k8s有coredns;需要將fun服務暴露到k8s集群外？沒問題址芯，k8s有ingress灾茁，在k8s之前，nginx在做著同樣的事情; 需要統一日志進行分析谷炸？可以接入nfs/ceph （當然北专，用沒用k8s都可以接入這兩個文件系統）......
乍一看，k8s似乎沒有解決新的問題旬陡？我的感覺拓颓，k8s解決的最大問題是：物理無關（怎么想起與女無瓜這個梗）。就是說我不需要關注物理機器了描孟，我不需要關心我的服務部署在哪臺真實的物理機器/ecs上驶睦，我的部署與調度都是基于資源來進行的砰左，我只知道有這個集群可以部署服務即可，至于這個集群是怎么保持可用性的场航、怎么擴展的缠导、機器狀況如何，我不關心旗闽，當然這需要云計算的支持，我認為這也是為什么k8s會與云原生緊密結合的原因蜜另，沒有了云計算适室，k8s的威力會大打折扣。
經過這一番自我解讀举瑰，我好像有點了解到IAAS捣辆，k8s是作為基礎設施存在的，為了用好這個基礎設施此迅，我們還需要搭建一個PAAS汽畴，比如Rancher在這塊就做的很好。
通過調度功能來思考k8s設計的原因耸序，當然我理解的并非全部忍些，過程相當有意思，談不上抽絲剝繭坎怪，不過k8s確實做了很多事情罢坝，目前看做的還很好。
Refer:
