K8S調度策略預研結論：
1、K8S的默認實現，提交順序和調度順序是一致的，即能夠保證先下發的Job先調度
2、在資源不足導致pending時，會unschedulableQ到隊列，當有新機器加入，會移到activeQ活躍隊列進行調度。這里又分為兩種情況
--在新機器加入的5分鍾左右，全部的請求已經創建job，依次進入unschedulableQ，那么加入activeQ隊列順序還是保持一致；
--新機器加入后，仍然有新創建的job，這時候加入activeQ隊列的順序就會不一致，即在ECS擴容的場景下，可能出現毛刺導致新提交的Job后調度
3、如果我們自己控制下發任務的時候等到調度成功再繼續下一個，這樣可以解決毛刺問題，但又會帶來新的問題
--調度不成功pending狀態下，下一個job如何處理，某一個job cpu較大，下一個job需求不大
--導致擴容速度變慢，，，只能每次擴一台
綜合考慮，可以認為K8S會總體上保證Job調度按照提交的時間順序進行；在擴容的場景下會有毛刺，但考慮到其他方案的副作用可以忽略不計
參考資料：
https://cn.bing.com/search?q=k8s+++deschedul&qs=n&FORM=BESBTB&sp=-1&pq=k8s+deschedul&sc=0-13&sk=&cvid=B16C790F4BEC477CB2E49DC255DE0652&ensearch=1
https://www.infoq.cn/article/or7CRphTDlX1IVhsFNgk
https://zhuanlan.zhihu.com/p/101908480
https://zhuanlan.zhihu.com/p/159736779
https://www.kubernetes.org.cn/7983.html
https://cn.bing.com/search?q=k8s+++get++pod+++status&qs=n&form=QBLH&sp=-1&pq=k8s+get+pod+status&sc=0-18&sk=&cvid=9D3E0184D67845119CAF88C5A237D0D7
https://blog.51cto.com/shunzi115/2449411
https://blog.csdn.net/u013812710/article/details/72886491
http://docs.kubernetes.org.cn/719.html
https://cn.bing.com/search?q=k8s++%E4%BA%8B%E4%BB%B6&qs=n&form=QBLH&sp=-1&pq=k8s+shijian&sc=0-11&sk=&cvid=9A602659849D4E30BFF67F3A23AE61C5
https://www.kubernetes.org.cn/1031.html
https://www.jianshu.com/p/335572c2c236
https://github.com/heptiolabs/eventrouter
https://zhuanlan.zhihu.com/p/59660536
https://cn.bing.com/search?q=k8s+++pod++++timeout&qs=n&sp=-1&pq=k8s+pod+timeout&sc=0-15&sk=&cvid=4DA2F0556D25448FB71C14248C25979B&first=6&FORM=PORE
https://zhuanlan.zhihu.com/p/145127061
https://cn.bing.com/search?q=crontab+shell+add&qs=n&form=QBLH&sp=-1&pq=crontab+shell+ad&sc=0-16&sk=&cvid=5EB6CF1B39B747519B92231C6EBF3426
https://stackoverflow.com/questions/5514269/write-a-shell-script-to-add-job-to-cron
https://stackoverflow.com/questions/42198960/how-to-add-a-crontab-job-to-crontab-using-a-bash-script
https://zhuanlan.zhihu.com/p/102469822