Kubernetes Linux Pod调度优化有五种方法：一、配置节点亲和性与反亲和性；二、启用污点与容忍机制；三、合理设置资源请求与限制；四、部署自定义调度器；五、启用拓扑分布约束实现跨域均衡。
如果您在 Kubernetes 集群中部署 Linux Pod 时遇到资源利用不均、节点负载过高或调度延迟等问题，则可能是由于默认调度策略未适配实际工作负载特征。以下是针对 Linux Pod 调度策略进行优化的具体实践方法：
一、配置节点亲和性与反亲和性
节点亲和性用于将 Pod 主动调度到满足特定标签条件的节点上，反亲和性则避免多个同类 Pod 被集中调度至同一节点，从而提升高可用性与资源隔离性。
1、为目标节点添加标签，例如执行
kubectl label nodes node-01 disktype=ssd。
2、在 Pod 的 spec 中添加affinity.nodeAffinity.requiredDuringSchedulingIgnoredDuringExecution字段，指定匹配规则。
3、若需分散同类型 Pod，配置affinity.podAntiAffinity.requiredDuringSchedulingIgnoredDuringExecution，使用topologyKey: topology.kubernetes.io/zone实现跨可用区分散。
二、启用污点与容忍机制控制调度流向
污点（Taint）可阻止 Pod 调度到特定节点，而容忍（Toleration）则允许被污点标记的节点接纳特定 Pod，二者结合可用于构建专用节点池或隔离敏感工作负载。
1、对目标节点添加污点，例如执行
kubectl taint nodes node-02 dedicated=ai:NoSchedule。
2、在对应 Pod 的 spec 中添加tolerations字段，包含key: dedicated, operator: Equal, value: ai, effect: NoSchedule。
3、验证调度结果，运行
kubectl get pods -o wide确认 Pod 已调度至带对应容忍的节点。
三、调整资源请求与限制以影响调度决策
Kubernetes 调度器依据 Pod 的requests值进行节点筛选，若 requests 设置过低，可能导致节点资源超售；设置过高则引发调度失败或资源闲置。
1、分析历史监控数据，使用
kubectl top nodes和kubectl top pods获取 CPU 与内存实际使用峰值。
Docker Desktop（linux）
当前 Docker 最新稳定版本之一，主要针对稳定性和兼容性进行了修复优化，适合生产环境与日常开发使用。该版本继续强化 AI 开发支持、容器日志管理以及 Docker Engine 的安全能力，对 Windows/macOS/Linux 平台兼容性进行了进一步优化。
下载2、在容器 spec 中显式设置resources.requests为观测到的 P95 使用量，resources.limits设为 P99 值并预留 20% 缓冲。
3、删除并重建 Pod，观察调度器是否选择更匹配资源余量的节点，执行kubectl describe pod
四、部署自定义调度器替代默认 kube-scheduler
当默认调度器无法满足复杂策略（如基于网络拓扑延迟、磁盘 IOPS 或自定义成本模型）时，可通过部署独立调度器接管特定 Pod 的调度逻辑，实现细粒度控制。
1、编写调度器程序，监听带有特定
schedulerName: my-scheduler的 Pod，并实现调度决策逻辑。
2、将调度器以 Deployment 方式部署至集群，赋予其system:kube-scheduler ClusterRole 权限。
3、在目标 Pod 的 spec 中设置schedulerName: my-scheduler，确保仅该类 Pod 由自定义调度器处理。
五、启用拓扑分布约束实现跨域均衡
拓扑分布约束（Topology Spread Constraints）可强制 Pod 按照指定拓扑域（如 zone、region 或自定义标签）均匀分布，避免单点故障放大与资源倾斜。
1、确认集群节点已打上
topology.kubernetes.io/zone或等效标签。
2、在 Pod spec 中添加topologySpreadConstraints列表，指定maxSkew: 1, topologyKey: topology.kubernetes.io/zone, whenUnsatisfiable: DoNotSchedule。
3、创建多个副本的 Deployment，执行kubectl get pods -o wide --sort-by=.spec.nodeName验证各 zone 下 Pod 数量差异是否在 maxSkew 范围内。