怎么样判定集群的最大节点数？

目前kubernetes调度器的调度方式是Pod-by-Pod，也是当前调度器不足的地方。主要瓶颈如下：

1. kubernets目前调度的方式，每个pod会对所有节点都计算一遍，当集群规模非常大，节点数很多时，pod的调度时间会非常慢。 这也是percentage-of-nodes-to-score 尝试要解决的问题
2. pod-by-pod的调度方式不适合一些机器学习场景。 kubernetes早期设计主要为在线任务服务，在一些离线任务场景，比如分布式机器学习中，我们需要一种新的算法gang scheduler，pod也许对调度的即时性要求没有那么高，但是提交任务后，只有当一个批量计算任务的所有workers都运行起来时，才会开始计算任务。 pod-by-pod 方式在这个场景下，当资源不足时非常容易引起资源死锁。
   3。 当前调度器的扩展性不是十分好，特定场景的调度流程都需要通过硬编码实现在主流程中，比如我们看到的bindVolume部分， 同样也导致Gang Scheduler 无法在当前调度器框架下通过原生方式实现
   一般来说，建议节点数控制在1200个左右。

这个问题真不好回答，一般最新版k8S 支持的理论值是5000 节点，但实际生产环境中少有人如此，这个牵扯到许多问题，如你的node 资源配置的是多大，是大资源node为主还是以小资源为主，你的应用所需资源量，应用所需的副本数，你团队的技术支撑能力等等这些都决定了你合适多大的节点集群（其中还有多处涉及对K8S的改造）。
大节点你应用的副本数就有限，一旦出现问题，对整个业务的影响也较大，使用小节点，对主控集群组件的资源要求就较高（节点通信频繁，资源浪费可能更多），一般来讲500-600左右是个相对合适的体量，再大你的团队可能会遇到多个技术问题的挑战，得不偿失。