openshift 4.20（也包括最近的4.19等） 和之前的 版本在配置NTP上有巨大差别。

分析完美。

如何理解openshift 4.20 NTP给master节点配置NTP的配置案例文件，下面的文件如何保证master时间同步： variant: openshift version: 4.20.0 metadata: name: 99-master-chrony-conf-override labels: machineconfiguration.openshift.io/role: master storage: files: - path: /etc/chrony.conf mode: 0644 overwrite: true contents: inline: | # Use public servers from the pool.ntp.org project. # Please consider joining the pool (https://www.pool.ntp.org/join.html). # The Machine Config Operator manages this file server openshift-master-0.<cluster-name>.<domain> iburst server openshift-master-1.<cluster-name>.<domain> iburst server openshift-master-2.<cluster-name>.<domain> iburst stratumweight 0 driftfile /var/lib/chrony/drift rtcsync makestep 10 3 bindcmdaddress 127.0.0.1 bindcmdaddress ::1 keyfile /etc/chrony.keys commandkey 1 generatecommandkey noclientlog logchange 0.5 logdir /var/log/chrony # Configure the control plane nodes to serve as local NTP servers # for all compute nodes, even if they are not in sync with an # upstream NTP server. # Allow NTP client access from the local network. allow all # Serve time even if not synchronized to a time source. local stratum 3 orphan

这个配置文件非常巧妙地解决了隔离网络中 Master 节点时间同步的问题。让我们一步步解析它如何保证 Master 时间同步：

核心机制分析

1. 相互引用形成对等网络

bash

server openshift-master-0.<cluster-name>.<domain> iburst 
server openshift-master-1.<cluster-name>.<domain> iburst
server openshift-master-2.<cluster-name>.<domain> iburst

• 关键点：每个 Master 节点都使用 相同的配置文件，将自己的两个同伴作为 NTP 服务器

• 结果：形成了 环形/全网状的 NTP 对等体网络

  text

  每个 Master 都有相同的配置 → 相互同步 → 形成共识

2. local stratum 3 的关键作用

bash

local stratum 3 orphan

这行配置是整个设计的核心：

• local stratum 3：告诉 chrony，即使无法与任何配置的 server 同步（因为大家都是 "server"，没有外部源），也以 stratum 3 的层级对外提供时间服务

• orphan：启用孤儿模式，当多个节点都配置了 orphan 时，它们会通过一种选举机制选择最合适的时间源

3. 工作原理时序

text

第一阶段（初始化）：
1. Master-0 启动：尝试从 Master-1、Master-2 同步，但它们可能也刚启动
2. Master-1 启动：同样尝试从 Master-0、Master-2 同步
3. Master-2 启动：尝试从 Master-0、Master-1 同步

第二阶段（共识形成）：
1. 每个节点都发现无法从"server"列表获得可靠时间
2. 由于配置了 `local stratum 3`，每个节点都启用自己的本地时钟（stratum 3）
3. chrony 的孤儿模式开始工作：
   - 节点比较彼此的本地时钟
   - 选举出"最佳"的时钟作为参考（通常是硬件最稳定的）
   - 其他节点逐渐向这个"最佳时钟"靠拢

第三阶段（稳定运行）：
1. 所有三个节点收敛到共识时间
2. 每个节点既是 server（被同伴查询）也是 client（查询同伴）
3. 持续相互校准，抵消单个节点的时钟漂移

4. allow all 的作用

bash

allow all

• 允许所有计算节点连接这些 Master 同步时间

• 但这不是 Master 之间同步的关键，只是为了让 Worker 能连入

更深层的技术保障

Chrony 的算法保证

1. 交叉验证：每个 Master 从另外两个同伴获取时间，进行交叉比较

2. 异常排除：如果某个 Master 的时钟异常漂移，会被另外两个"投票"排除

3. 加权平均：最终时间是对多个源进行加权平均的结果，不是简单的少数服从多数

Stratum 层级的巧妙运用

text

假设场景：
Master-0 硬件时钟稍微快些
Master-1、Master-2 时钟接近但稍慢

chrony 的处理：
1. 三者都宣称自己是 stratum 3
2. 通过交换时间信息，发现 Master-0 的时间与其他两个差异较大
3. Master-1 和 Master-2 形成"多数派"
4. 最终三者都收敛到 Master-1/Master-2 的平均时间附近

为什么这比简单配置一个 NTP 服务器更好？

方案	高可用性	自动容错	精度保证
指定一个主 Master 为时间源	❌ 单点故障	❌	❌
本配置文件（相互同步）	✅ 三节点互为备份	✅ 自动排除异常节点	✅ 通过共识提高精度

实际部署时的注意事项

1. 初始时间不能偏差太大

虽然这个方案能处理时钟漂移，但如果三个节点初始时间差太大（比如几分钟），需要：

• 在安装前手动同步一次时间

• 或者确保 BIOS 时间大致相同

2. 网络延迟的影响

在配置中，所有 server 都是使用域名，确保：

• 集群 DNS 正常工作

• 节点之间网络延迟低且稳定

3. 验证同步状态

部署后应该检查：

bash

# 在每个 Master 节点上执行
chronyc sources -v
chronyc tracking

应该看到每个节点都从另外两个节点同步，并且 dispersion（离散度）很小。

总结设计哲学

这个配置体现了 "去中心化共识" 的思想：

• 没有指定的"主"时间服务器

• 每个节点平等参与时间共识

• 通过算法自动达成一致并维持稳定

• 天然具备高可用和容错能力

这正是 OpenShift 在隔离网络环境中不依赖外部 NTP 服务器仍能保证时间同步的聪明之处。它利用了 chrony 的强大功能，将三个 Master 节点构建成一个自洽、弹性、一致的时间同步集群。