时间同步

概述 一次线上故障让我彻底重视起时间同步这件事。某天凌晨，业务反馈 HTTPS 请求大面积失败，报错 SSL_ERROR_BAD_CERTIFICATE。排查了两个小时，翻遍网络拓扑、防火墙规则、证书配置，都没问题。最后有人无意间看了眼系统时间——比真实时间快了 12 秒。就这 12 秒，让服务器在验证客户端证书的 notBefore 时间时判定"证书尚未生效"，拒绝了所有握手。 这不是孤例。时间不同步在分布式系统里是一颗隐形地雷：Kerberos 认证对时间偏差容忍只有 5 分钟，超了直接拒登；Kubernetes 节点时间偏差过大，kubelet 心跳过期，Pod 被驱逐；MySQL 主从复制依赖时间戳，偏差大会导致 binlog 顺序错乱；分布式事务的二阶段提交，节点间时钟不同步会让超时判断失效。 时间同步听起来简单——装个 NTP 客户端，指向时间服务器就完事了。但生产环境的坑远不止于此：虚拟机时钟漂移、容器里没有 NTP 守护进程、多机房时钟源选型、chrony 和 ntpd 冲突、证书续期任务因时间跳变失败。这篇文章把这些问题一次性讲清楚，给出生产可用的配置和排障思路。 从 ntpd 到 chrony：为什么换了 ntpd 是老牌的时间同步服务，跑了二十多年。但从 RHEL 8、CentOS 8、Ubuntu 20.04 开始，主流发行版默认都换成了 chrony。原因不是 ntpd 不好，而是 chrony 在几个关键场景下表现更好： 对比维度 ntpd chrony 首次同步速度 慢，需要逐步逼近 快，iburst 几秒内拉到毫秒级 网络中断后恢复 慢，重新同步耗时长 快，历史漂移率记录加速收敛 虚拟机时钟漂移 处理差，容易抖动 处理好，driftfile 自动补偿 资源占用 较高 更低 离线保持 漂移大 driftfile 让离线也能维持 是否支持时间服务器功能 是 是（allow 指令） 关键区别在首次同步速度。ntpd 出于"不能让时间跳变"的设计哲学，启动后是缓慢逼近目标时间，可能要十几分钟才稳定。chrony 的 iburst（initial burst）选项，启动时一次性发 4 个探测包，几秒内就能完成首次同步。这对虚拟机、容器这种频繁启停的场景至关重要——你不可能等 10 分钟才让一个容器的时间正确。...