EKS 1.23集群级默认PodTopologySpread配置报错及疑问

1. 为什么kubectl apply KubeSchedulerConfiguration会报错？ #

首先要明确：KubeSchedulerConfiguration不是可以通过kubectl apply直接提交的集群API资源，它是kube-scheduler组件启动时加载的配置文件，而非集群内可创建的CRD或原生API对象。

对于EKS托管集群，kube-scheduler由AWS负责管理，用户无法直接修改其默认配置文件。你尝试通过kubectl apply提交这个配置时，Kubernetes API Server会因为找不到对应的API组/版本/Kind而报错——这就是你遇到“无法识别该Kind和版本”的核心原因，不管换哪个API版本，这个操作本身就是错误的。

2. EKS 1.23中配置集群级默认PodTopologySpread的正确方式 #

在EKS 1.23中，要设置集群级默认PodTopologySpread约束，有两种可行方案：

• 方案一：部署自定义调度器
  你可以部署自己的kube-scheduler实例，在其启动参数中指定包含默认PodTopologySpread规则的KubeSchedulerConfiguration配置文件（对应API版本为kubescheduler.config.k8s.io/v1beta2，因为EKS 1.23对应Kubernetes 1.23，该版本仅支持v1beta2及更早的调度器配置版本）。之后将需要应用该规则的Pod通过spec.schedulerName指定使用自定义调度器。
• 方案二：使用Mutating Admission Webhook
  编写并部署Mutating Webhook，在Pod创建时自动注入PodTopologySpread约束，实现类似集群级默认的效果。这种方式不需要修改调度器，而是通过拦截Pod创建请求来添加规则。

3. 集群级默认约束是否需要指定命名空间？ #

集群级的默认PodTopologySpread约束是全局生效的，不需要指定命名空间。如果是通过自定义调度器配置的默认规则，会对所有使用该调度器的Pod生效（无论所属命名空间）；如果是通过Mutating Webhook实现，可根据需求选择是否过滤命名空间，但默认全局生效的话无需指定。

内容的提问来源于stack exchange，提问作者jrz