首页/网络/常用端口速查/10259 kube-scheduler 安全口
10000-19999 注册端口49 条

10259 kube-scheduler 安全口

K8s 调度器的 HTTPS 端点:暴露调度指标与健康状态;旧版不安全端口 10251 已移除,集群审计按 10259 收口。

常用端口速查网络更新于 2026-10-13

10259 是什么

10259 是 kube-scheduler 的安全端口(HTTPS):调度器通过它暴露健康状态与调度相关指标。调度是容器落地的关键一环,Pod 卡在 Pending 时,先确认调度器健康,再看事件里的 FailedScheduling 原因,比逐个节点核对资源更快定位问题。与 controller-manager 一样,它的历史不安全端口 10251 已经被移除,审计时不要再用旧端口做判断依据。

基本信息

服务kube-scheduler secure(10259)
协议TCP/HTTPS
用途调度器健康与指标
配套端口6443、10257
已移除10251(历史不安全端口)
安全等级仅控制面内网

典型使用场景

  • Pending 排障:检查调度器健康与调度失败原因
  • 资源规划:通过调度指标观察资源碎片与利用率
  • 指标采集:纳入集群监控与告警
  • 控制面基线:核对端口暴露范围
  • 调度策略调整:优先级与抢占配置变更的验证
  • 高可用巡检:确认 Leader 实例与调度连续性

Pending 常见原因

原因表现核对方式
资源不足事件提示资源不足查看节点可分配资源
污点与容忍节点存在不被容忍的污点查看节点 Taints
亲和性规则无满足规则的节点核对 affinity 配置
调度器异常事件长时间不更新检查调度器健康与日志

健康与事件核对

健康与事件核对
curl -sk https://cp01:10259/healthz | head -c 100        # 调度器健康
kubectl get events --field-selector reason=FailedScheduling | tail -5
kubectl describe pod <pod> | tail -20                    # 事件区最关键
kubectl get nodes -o custom-columns=NAME:.metadata.name,CPU:.status.allocatable.cpu
# 调度器日志: kubectl -n kube-system logs kube-scheduler-<cp01>
调度失败信息几乎都写在事件里:先 describe Pod 再看调度器指标,顺序反了会在指标里绕很久。
调度器高可用时只有一个实例在工作:看到其他实例日志安静属正常现象,不要误判为组件挂掉。
改调度策略不做灰度会影响全局:优先级、抢占与拓扑约束的调整可能触发大范围重新调度,业务会同时抖动。
资源碎片比总量更容易被忽略:节点总资源充足但碎片化时,大规格 Pod 依然调度不上去,容量评估要同时看两者。
调度指标应与业务指标放在同一个时间轴上比对:很多「集群不稳」的结论,最后都指向某个业务在批量重建 Pod。

易错点

  • 调度器指标口开放到集群外:内部调度延迟与队列深度被第三方观测
  • 只看资源不看污点:节点明明有空闲却调度不上去,常见于被污点挡住
  • 改调度策略不做灰度:全局策略调整后大范围 Pod 重新调度,业务可能同时抖动
  • 把 Pending 都归因于资源不足:忽略亲和性、拓扑与卷约束,排查方向会跑偏
  • 调度器多实例却不核对 Leader:以为都在工作,实际只有一台在承担调度

数据来源与参考

  • Kubernetes 官方文档(scheduler 10259)

相关工具

​‌‌​​‌​​​‌‌​‌‌‌‌​‌‌​​​‌‌​‌‌‌​​‌‌​​‌​‌‌‌​​‌‌‌​​​‌​‌‌​‌​​‌​‌‌‌​​​‌​‌‌​‌​​‌​‌‌​​​‌‌​‌‌‌​‌​​​‌‌​‌‌‌‌​​‌​‌‌‌​​‌‌​​​‌‌​‌‌​‌‌‌‌​‌‌​‌‌​‌