谈一谈k8s中scheduler组件的调度算法

Big Picture
K8S的调度说实话一般没啥人改，因为一般的体量，基于K8S内置的算法基本就满足了，但对于大体量和特殊场景来说，还是很有必要进行修改的，比如假设有好几种业务场景的pod，需要按需要调度到不同的rack上，传统做法当然可以对Node进行label，然后在不同业务的pod上做match，同样的，也可以修改调度器，在调度的时候自动进行调度，类似的场景有点像openstack的filter模块，所以理解K8S的调度还是非常有必要，毕竟先了解了，才能修改。

informer机制,调度的开始
K8S的内部通信都是基于HTTP的，一个控制器每次需要获取对象的时候都要访问 APIServer，这会给APIServer带来很高的压力，所以K8S 使用了一个叫做Informers 的内存缓存来解决这个问题，Informer可以几乎实时的监控对象的变化，而不需要轮询请求，这样就可以保证客户端的缓存数据和服务端的数据一致，就可以大大降低 APIServer 的压力了。

K8S的调度器会通过Informer，WATCH对于的API 对象，一旦发生有新的API对象被创建出来，且nodeName 字段为空，则Kube-scheduler任务这是个待调度的资源，变会触发上那个图的event handlers，将该API对象加到待调度队列，等待后续操作，这便是调度的第一个大循环。

筛选过程，调度的过程
在筛选过程，K8S会从待调度