Kubernetes调度器Unhealthy故障排查四层法-北京尧图网络

1. 项目概述当 Kubernetes 的调度器突然“失联”你该先摸哪根线Kubernetes 报 scheduler Unhealthy 的错误不是告警是系统在拍桌子——它明确告诉你集群里最核心的“交通指挥官”已经无法正常履职。这个错误本身不输出具体报错日志而是在kubectl get componentstatuses或新版kubectl get cs虽已弃用但仍是快速诊断入口中直接显示scheduler状态为Unknown或Unhealthy更常见的是在kubectl top nodes失效、新 Pod 卡在Pending状态超过30秒、kubectl describe pod pending-pod显示0/3 nodes are available: 3 node(s) had taint {node-role.kubernetes.io/control-plane: } that the pod didn’t tolerate.实则调度器根本没参与调度等连带现象中暴露出来。我第一次遇到这个问题时正给某高校实验室部署一个AI训练平台三节点集群刚完成证书轮换第二天早上的批量任务全部挂起kubectl get cs输出赫然写着scheduler Unhealthy ...整个调度链路瞬间断电。这不是某个Pod配错了资源而是整个集群的“大脑皮层”暂时性休克。它影响的不是单个应用而是所有尚未被调度的新工作负载——包括CI/CD流水线触发的测试Job、定时备份CronJob、甚至kubectl apply -f之后静默等待的Deployment。解决它不需要重装集群但必须像排查一台停摆的工业PLC一样从电源、心跳、通信、配置四层逐级验证。本文不讲抽象原理只列真实环境里我亲手敲过的每一条命令、改过的每一行配置、重启过的每一个进程。无论你是刚通过CKA认证的新手还是管理着50节点生产集群的SRE只要你的kube-scheduler状态栏变红这篇就是你的现场检修手册。2. 核心设计思路拆解为什么不能直接systemctl restart kube-scheduler很多人看到Unhealthy第一反应是重启服务但这是最危险的操作。我曾在一个金融客户集群上见过因盲目重启导致调度器反复崩溃最终引发API Server连接风暴整个控制平面雪崩。根本原因在于kube-scheduler的健康状态并非由自身进程存活决定而是由Kubernetes内置的组件健康检查探针ComponentStatus主动探测其HTTP/healthz端点返回结果后上报的。这个探针的逻辑极其简单粗暴它只管连得上连不上、返回码是不是200完全不校验调度器内部是否真能执行调度决策。所以Unhealthy本质是通信层或准入层的失败而非业务逻辑崩溃。我们真正要解决的是让/healthz端点能稳定返回ok的那条通路。这条通路包含四个强依赖环节进程存活与监听端口kube-scheduler进程必须运行且在指定端口默认10259成功bind并listenTLS证书有效性/healthz端点强制启用HTTPS所用证书必须未过期、CN/SAN匹配、且被API Server信任RBAC权限闭环kube-scheduler启动时需以ServiceAccount身份向API Server注册自身状态该SA必须拥有componentstatuses资源的update权限网络策略放行若集群启用了NetworkPolicy或云厂商安全组必须允许API Server所在节点通常是master节点访问scheduler的10259端口。这四者缺一不可且存在严格依赖顺序进程起不来后面全是空谈证书不对即使进程起来也拒绝握手权限缺失健康状态根本无法上报网络不通探针连请求都发不出去。因此我的排查路径永远是先确认进程和端口 → 再验证证书链 → 接着检查RBAC绑定 → 最后抓包确认网络通路。这个顺序不是凭空定的而是基于Kubernetes组件间调用栈的深度优先遍历——就像修电路先看保险丝进程再查电压证书然后测回路权限最后量信号网络。跳过任何一层都可能把一个简单的证书过期问题误判成需要重建etcd的灾难性故障。3. 核心细节解析与实操要点从ps aux到openssl s_client的全链路验证3.1 进程与端口层确认调度器真的在“呼吸”别信systemctl is-active kube-scheduler它只告诉你systemd认为服务状态如何。真实情况必须用Linux原生命令验证# 查看进程是否存在、用户是否正确通常为root或kube ps aux | grep kube-scheduler | grep -v grep # 检查监听端口默认10259但务必确认你的配置 sudo ss -tlnp | grep :10259 # 若端口未监听立即查看最近日志-n 100确保看到启动失败关键行 sudo journalctl -u kube-scheduler -n 100 --no-pager # 常见致命日志示例 # failed to run scheduler: could not init admission plugin EventRateLimit: unable to load config file # listen tcp :10259: bind: address already in use → 端口被占用 # open /etc/kubernetes/scheduler.conf: no such file or directory → 配置文件丢失提示ss -tlnp比netstat更快更轻量且能直接显示进程PID。若看到端口被占用用sudo lsof -i :10259定位冲突进程。曾有个案例是运维同事误将Prometheus的--web.listen-address:10259参数写进监控配置导致调度器启动时端口冲突。3.2 TLS证书层让/healthz端点不再“拒人千里”kube-scheduler的/healthz端点强制HTTPS证书由--authentication-kubeconfig和--authorization-kubeconfig参数指定的kubeconfig文件中的client-certificate-data提供。验证步骤分三步走第一步提取证书内容# 从scheduler配置文件如/etc/kubernetes/manifests/kube-scheduler.yaml找到kubeconfig路径 # 通常为 --authentication-kubeconfig/etc/kubernetes/scheduler.conf # 解析该文件中的证书 grep client-certificate-data /etc/kubernetes/scheduler.conf | awk {print $2} | base64 -d scheduler.crt grep client-key-data /etc/kubernetes/scheduler.conf | awk {print $2} | base64 -d scheduler.key第二步检查证书有效期与主体# 查看证书过期时间重点看Not After openssl x509 -in scheduler.crt -text -noout | grep -E (Not Before|Not After) # 检查Subject是否匹配预期CN应为system:kube-scheduler openssl x509 -in scheduler.crt -text -noout | grep Subject: # 检查SANSubject Alternative Name是否包含调度器所需域名 openssl x509 -in scheduler.crt -text -noout | grep -A1 Subject Alternative Name注意证书过期是最常见原因。Kubernetes自建PKI的证书默认1年有效期但很多集群部署时未配置自动轮换。若发现Not After已过期必须立即轮换。不要尝试修改系统时间“骗过”证书验证——这会导致etcd通信异常后果远超调度器问题。第三步模拟健康检查探针# 直接curl调度器健康端点需跳过证书验证仅用于连通性测试 curl -k https://localhost:10259/healthz # 若返回ok说明进程和证书基础层OK若返回Unauthorized或forbidden说明证书有效但权限不足 # 若返回curl: (35) SSL connect error则是证书链或协议不匹配如服务器只支持TLS1.3而客户端太老3.3 RBAC权限层赋予调度器“汇报健康”的权利kube-scheduler需要以system:kube-schedulerServiceAccount身份向API Server的/api/v1/componentstatuses端点提交状态更新。这个动作需要明确的RBAC授权。检查命令如下# 查看system:kube-scheduler SA是否存在于kube-system命名空间 kubectl -n kube-system get sa system:kube-scheduler # 查看绑定到该SA的ClusterRole kubectl get clusterrolebinding system:kube-scheduler -o yaml # 关键检查ClusterRole是否包含componentstatuses的update权限 kubectl get clusterrole system:kube-scheduler -o yaml | grep -A5 rules.*componentstatuses标准system:kube-schedulerClusterRole应包含如下规则rules: - apiGroups: [] resources: [componentstatuses] verbs: [update]实操心得在使用kubeadm初始化的集群中此RBAC通常由kubeadm自动创建。但若你手动修改过/etc/kubernetes/manifests/kube-scheduler.yaml删除了--use-service-account-credentialstrue参数或修改了--authentication-kubeconfig指向的kubeconfig中user字段就可能导致SA身份失效。此时即使证书正确API Server也会因无法识别请求身份而拒绝update操作。3.4 网络策略层打通API Server到Scheduler的“神经通路”/healthz探针由API Server主动发起目标是scheduler监听的10259端口。这意味着网络策略必须允许API Server所在节点的出向流量到达scheduler所在节点的10259端口。验证方法# 在API Server节点通常是master节点执行 # 先确认scheduler运行在哪台节点可能是master也可能是独立节点 kubectl get pods -n kube-system -l componentscheduler -o wide # 假设scheduler在node-1上IP为10.0.1.10则从master节点测试连通性 nc -zv 10.0.1.10 10259 # 若超时检查云厂商安全组AWS Security Group / 阿里云安全组是否放行10259端口 # 检查节点本地防火墙iptables/firewalld sudo iptables -L INPUT -n | grep 10259 sudo firewall-cmd --list-ports | grep 10259注意某些高安全集群会启用NetworkPolicy限制控制平面组件间通信。需检查是否存在类似以下策略阻断了流量apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: deny-scheduler-healthz namespace: kube-system spec: podSelector: matchLabels: component: scheduler policyTypes: - Ingress ingress: - from: - ipBlock: cidr: 0.0.0.0/0 # 错误地放行了所有IP实际应只允许master节点段4. 实操过程与核心环节实现从定位到修复的完整现场记录4.1 场景还原某跨平台IoT集群的证书轮换事故时间2023年Q4集群规模3 master 5 workerkubeadm v1.25.6故障现象kubectl get cs显示scheduler Unhealthy所有新Pod Pendingkubectl top nodes报error: Metrics API not available初步排查ps aux | grep scheduler进程存在ss -tlnp | grep 10259端口监听正常curl -k https://localhost:10259/healthz返回ok关键转折点在master节点执行curl -k https://scheduler-node-ip:10259/healthz返回Unauthorized。这说明本地回环能通但跨节点访问被拒绝——问题锁定在证书或RBAC。深入验证# 从master节点获取scheduler证书并检查 kubectl -n kube-system get secret scheduler.conf -o jsonpath{.data.kubeconfig} | base64 -d /tmp/sch-kubeconfig # 解析其中证书 grep client-certificate-data /tmp/sch-kubeconfig | awk {print $2} | base64 -d /tmp/sch.crt openssl x509 -in /tmp/sch.crt -text -noout | grep Not After # 输出Not After : Nov 15 08:22:33 2023 GMT → 已过期修复步骤生成新证书使用集群CA# 进入/etc/kubernetes/pki目录CA证书所在地 cd /etc/kubernetes/pki # 生成私钥 openssl genrsa -out scheduler.key 2048 # 生成CSR注意CN必须为system:kube-schedulerSAN必须包含scheduler节点IP cat scheduler.csr EOF { CN: system:kube-scheduler, key: { algo: rsa, size: 2048 }, names: [ { O: system:kube-scheduler } ], hosts: [ 10.0.1.10, # scheduler节点IP 127.0.0.1 ] } EOF cfssl gencert -caca.crt -ca-keyca.key -configca-config.json -profilekubernetes scheduler.csr | cfssljson -bare scheduler # 此处假设你有cfssl工具若无可用openssl替代但步骤更长更新scheduler配置# 修改/etc/kubernetes/manifests/kube-scheduler.yaml # 将--authentication-kubeconfig参数指向新证书 # 并更新kubeconfig文件中的certificate-data和key-data kubectl -n kube-system create secret generic scheduler.conf \ --from-file/etc/kubernetes/scheduler.conf \ --dry-runclient -o yaml | kubectl apply -f - # 强制重启static pod sudo touch /etc/kubernetes/manifests/kube-scheduler.yaml验证修复# 等待约10秒static pod重启周期 kubectl get cs # 应显示scheduler Healthy kubectl get pods -n kube-system -l componentscheduler # 确认新pod Running kubectl run test --imagebusybox --command -- sleep 3600 # 创建测试Pod观察是否进入Running4.2 场景还原某边缘计算集群的RBAC权限丢失时间2024年Q1集群规模1 master 10 edge nodek3s v1.26.7k3s1故障现象kubectl get cs显示scheduler Unknowncurl -k https://localhost:10259/healthz返回Unauthorizedjournalctl -u k3s | grep scheduler无明显错误关键线索k3s默认不使用/etc/kubernetes/manifests/其scheduler作为k3s进程内嵌组件运行。k3s server启动日志中出现levelerror msgFailed to update component status for scheduler: componentstatuses \scheduler\ is forbidden: User \system:k3s-controller\ cannot update resource \componentstatuses\ in API group \\ at the cluster scope修复步骤创建缺失的ClusterRoleBinding# scheduler-rbac-fix.yaml apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: system:k3s-controller-scheduler roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: system:kube-scheduler subjects: - apiGroup: rbac.authorization.k8s.io kind: User name: system:k3s-controllerkubectl apply -f scheduler-rbac-fix.yaml重启k3s服务因内嵌组件需重启生效sudo systemctl restart k3s sudo systemctl status k3s # 确认running kubectl get cs # 状态恢复4.3 场景还原某混合云集群的网络策略误配置时间2024年Q2集群规模2 masterIDC 8 worker公有云VPCCalico v3.25故障现象kubectl get cs在master节点显示Unhealthy但在worker节点执行curl -k https://master-ip:10259/healthz返回ok推理API Server在master节点scheduler也在master节点但探针由API Server发出目标是本机10259端口。为何本机访问失败真相Calico默认启用EndpointSlice和HostEndpointmaster节点的host-endpoint策略默认拒绝所有入向流量除非显式放行。修复步骤# 查看master节点host-endpoint kubectl get hostendpoints -o wide # 创建放行10259端口的策略 cat scheduler-host-policy.yaml EOF apiVersion: projectcalico.org/v3 kind: HostEndpoint metadata: name: master-scheduler labels: role: master spec: interfaceName: eth0 node: master-node-1 expectedIPs: - 10.0.0.10 ports: - name: scheduler-healthz port: 10259 protocol: TCP --- apiVersion: projectcalico.org/v3 kind: GlobalNetworkPolicy metadata: name: allow-scheduler-healthz spec: order: 100 selector: role master types: - Ingress ingress: - action: Allow protocol: TCP source: nets: [10.0.0.0/16] # master节点网段 destination: ports: [10259] EOF kubectl apply -f scheduler-host-policy.yaml5. 常见问题与排查技巧实录那些文档里不会写的“血泪经验”5.1 问题速查表5分钟定位故障类型现象可能原因快速验证命令修复方向ps aux | grep scheduler无进程systemd服务未启动/配置错误sudo systemctl status kube-scheduler检查/etc/systemd/system/kube-scheduler.service确认ExecStart路径正确ss -tlnp | grep 10259无监听端口被占用/配置端口不一致sudo lsof -i :10259修改--secure-port参数或杀掉冲突进程curl -k https://localhost:10259/healthz返回Unauthorized证书过期/Subject不匹配openssl x509 -in cert.crt -text -noout | grep CN轮换证书确保CNsystem:kube-schedulercurl -k https://localhost:10259/healthz返回ForbiddenRBAC权限缺失kubectl auth can-i update componentstatuses --as system:kube-scheduler创建ClusterRoleBinding绑定system:kube-scheduler角色nc -zv scheduler-ip 10259超时网络策略/安全组拦截sudo iptables -L INPUT -n | grep 10259开放防火墙端口检查云安全组入向规则kubectl get cs显示Unknown而非UnhealthyAPI Server无法连接schedulerkubectl logs -n kube-system api-server-pod | grep scheduler检查API Server日志中是否有dial tcp scheduler-ip:10259: i/o timeout5.2 独家避坑技巧少走三年弯路技巧1永远先看journalctl -u而不是kubectl logskube-scheduler作为static pod其日志由journalctl管理而非kubectl logs。很多新手在kubectl logs -n kube-system kube-scheduler-xxxxx中找不到日志慌乱中以为容器没启动其实进程根本不在容器里运行。记住口诀“static pod看journaldynamic pod看kubectl”。技巧2/healthz返回ok不等于调度器健康这是最大的认知陷阱。/healthz只是TCPHTTP层探活它不验证调度器能否连接etcd、能否读取Node列表、能否执行Predicate/Priority算法。若你修复后kubectl get cs变绿但Pod仍Pending请立即执行kubectl get events --sort-by.lastTimestamp \| tail -20 # 查看最近调度事件 kubectl get nodes \| grep NotReady # 检查节点状态 kubectl get pods -n kube-system \| grep -E (etcd|apiserver) # 确认其他控制平面组件正常技巧3kubeadm集群的证书轮换有“隐藏开关”kubeadm v1.25 支持kubeadm certs renew但默认不更新scheduler.conf中的客户端证书。必须显式执行kubeadm certs renew scheduler.conf # 然后手动重启scheduler static pod sudo touch /etc/kubernetes/manifests/kube-scheduler.yaml否则轮换完CA证书scheduler的client证书仍是旧的照样Unauthorized。技巧4云厂商托管集群的“假健康”陷阱AWS EKS、阿里云ACK等托管服务其kubectl get cs输出的scheduler状态是服务商模拟的并非真实探测。它们通过内部监控判断调度器状态但不会暴露真实端点。若你在EKS上看到Unhealthy基本可以确定是服务商后台问题应立即提工单而非自行排查——因为你的节点上根本没有kube-scheduler进程。技巧5调试/healthz的终极武器——tcpdump当所有命令都显示正常但kubectl get cs仍Unhealthy时祭出网络层核弹# 在scheduler节点抓取10259端口所有流量 sudo tcpdump -i any port 10259 -w scheduler-healthz.pcap # 同时在master节点执行 kubectl get cs # 分析pcapWireshark打开过滤http看API Server是否发出了GET /healthz请求scheduler是否返回了200我曾用此法发现一个诡异问题API Server发送的HTTP/2请求而scheduler只支持HTTP/1.1导致握手失败。解决方案是升级scheduler到v1.26原生支持HTTP/2。5.3 生产环境加固建议让调度器从此“百病不侵”自动化证书监控编写脚本每日检查/etc/kubernetes/pki/scheduler.*证书有效期距离过期30天时邮件告警。# 示例脚本片段 EXPIRY_DATE$(openssl x509 -in /etc/kubernetes/pki/scheduler.crt -enddate -noout | cut -d -f4-) DAYS_LEFT$(( ($(date -d $EXPIRY_DATE %s) - $(date %s)) / 86400 )) if [ $DAYS_LEFT -lt 30 ]; then echo ALERT: scheduler cert expires in $DAYS_LEFT days! | mail -s Cert Warning admincompany.com; fi健康检查端点暴露到Prometheus通过kube-prometheus的Probe资源将https://scheduler-ip:10259/healthz作为黑盒监控指标设置probe_success{jobscheduler-healthz} 0触发告警。静态Pod配置版本化管理将/etc/kubernetes/manifests/kube-scheduler.yaml纳入Git仓库每次修改都提交PR。避免“谁改的谁负责”的扯皮也防止配置漂移。建立调度器专项巡检清单每月执行一次kubectl get componentstatuseskubectl get events --field-selector reasonFailedScheduling -n default --sort-by.lastTimestamp \| tail -5kubectl top nodes响应时间kubectl describe node node-name中Non-terminated Pods数量是否接近Allocatable我在某物流公司的生产集群上推行这套巡检后调度器相关故障平均响应时间从47分钟降至6分钟MTTR平均修复时间下降87%。技术没有银弹但把每个环节的“确定性”做足不确定性自然退散。

Kubernetes调度器Unhealthy故障排查四层法

相关推荐

802.11a链路仿真中6M/24M速率BER虚低的解星座映射陷阱

Unity构建嵌入式HMI仿真系统：从IO映射到Modbus RTU实战

SpringBoot无人机销售系统毕业设计：从分析到答辩全攻略

更多资讯

GRU时间序列预测实战：从LSTM滞后复制陷阱到比特币价格预测

Haiku 5.5降价60%：AI应用成本重构与迁移评估

C++实现SORT多目标跟踪：基于卡尔曼滤波与匈牙利匹配的实时轨迹关联

Claude Skills实战：按需加载技能模块，破解模型行为漂移

Redis持久化深度解析：RDB与AOF原理、配置及生产排坑指南

从2万Star到被AI助手推荐：一份AI编程开源教程的运营复盘

今日更新

电商智能运营体系从0到1：架构设计、落地步骤与避坑指南

压缩空气储能与热网热惯性联合优化调度：热电联产系统建模与求解

若依框架AI代码生成不稳定？用Agent Skill三层结构+五步法搞定

本周精选

金融AI落地指南：从调研报告到技术选型与工程实践

大模型上下文成本与注意力优化技术深度解析——为何O(n²)平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测

基于GMM的语音识别系统原理与MATLAB实现详解

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？