问题概述

在Kubernetes集群运维中，节点时间不一致是一个常见但容易被忽视的问题。当集群内部分节点的系统时间与主节点或NTP服务器偏差超过一定阈值（通常为5秒）时，会导致多种调度异常：Pod无法正常调度、kubelet证书验证失败、健康检查探针超时、甚至集群整体不稳定。本文针对该问题提供一套标准化的排查与修复流程。

问题原因分析

Kubernetes集群协调时间依赖NTP（Network Time Protocol）服务。时间不一致主要源于：

• 节点NTP服务未正确配置或未启动
• 防火墙规则阻止NTP端口（UDP 123）通信
• 硬件时钟漂移导致软件时间失准
• 虚拟机迁移后时间未同步

当证书签发时间（基于节点本地时间）与集群内部时间戳的差值超出容忍范围时，kubelet与apiserver之间的TLS握手会失败，导致节点状态变为NotReady，调度器自动将Pod分配到其他可用节点。

修复步骤

1. 检测节点时间偏差

登录每个节点，执行以下命令检查当前时间及与NTP服务器的偏移：

1. date — 查看系统时间
2. timedatectl status — 查看NTP服务状态
3. chronyc sources -v（使用chrony时）或 ntpq -p（使用ntpd时） — 查看同步状态

如果发现任何节点的偏差大于1秒，应立即修复。

2. 同步节点时间

推荐使用chrony作为NTP客户端（从CentOS 7/RHEL 7起默认）。以下以chrony为例：

# 安装chrony（如未安装）
yum install -y chrony
systemctl enable chronyd
systemctl start chronyd

# 强制立即同步
chronyc -a makestep

对于物理机或高度重视时间精度的环境，可在配置文件/etc/chrony.conf中添加多个可靠服务器：

• server ntp1.aliyun.com iburst
• server ntp2.aliyun.com iburst
• server cn.ntp.org.cn iburst

重启chronyd后验证：chronyc tracking | grep -i 'last offset'

3. 检查kubelet证书

如果时间偏差曾达到数小时，之前签发的kubelet证书可能已失效。建议重新生成证书：

1. 在Master节点删除旧的CertificateSigningRequest（CSR）：kubectl delete csr --all
2. 在受影响节点重启kubelet：systemctl restart kubelet
3. 等待CSR自动重新提交并批准：kubectl get csr | grep -i pending -> kubectl certificate approve

4. 验证调度恢复

检查节点状态是否恢复Ready：kubectl get nodes。然后尝试手动调度测试Pod：

kubectl run test-pod --image=nginx --restart=Never --node=<之前异常节点名>
kubectl delete pod test-pod

如果Pod成功运行，说明调度器已恢复正常。

集群层面的最佳实践

为避免时间不一致再次引发问题，建议实施以下措施：

• 统一NTP配置：通过Ansible、SaltStack或Kubernetes DaemonSet部署chrony配置模板。
• 在kubelet启动参数中增加时间容忍度（仅作为临时兜底）：--experimental-max-clock-skew=10s（Kubernetes v1.21后废弃，建议通过kubelet配置文件设置）。
• 监控告警：使用Prometheus + node_exporter的node_timex_offset_seconds指标，设置阈值每分钟检查。
• 物理机/云实例统一使用同一NTP源，避免不同机房提供不同时间标准。

通过上述方法，绝大多数节点时间偏差问题能在数分钟内得到修复，恢复集群的调度稳定性和可用性。