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