写在前面
每个人的环境都不一样，所以生产环境操作前一定要在你的测试环境中仔细验证后再操作。
以下内容纯属个人理解，并没有对错，只是参考，盗版不纠,才能有限，希望不误人子弟为好。
以下属于个人实验，实际运用当中需要结合实际需求，参考有风险，实施需谨慎。
文档信息
文档变更记录
最近接触了k8s集群，etcd集群等等，发现集群内如果时间不同步，会出现一些意想不到的问题。
所以这里主要讨论下集群下的时间同步问题，本文的基础是以RockyLinux 8为基础。你可能会使用ntpd，ntpdate这些工具进行时间同步，但是Centos 8系列中，这些工具已经被淘汰了，在基础仓库里无法找到了，
而且Centos 7也有chrony，所以这里着重介绍Chrony来实现集群内的时间同步。
这里希望阅读完这篇文档，能够帮助解决2个问题：
- 我该如何设计时间集群
- 实际应用需要注意哪些问题
官方文档：
https://chrony.tuxfamily.org/
https://chrony.tuxfamily.org/faq.html
从chrony的官方文档可以有一些常见的问题解答，不过国内无法访问。
巨人的肩膀：
https://help.aliyun.com/document_detail/92704.html
https://datatracker.ietf.org/doc/html/rfc1305
https://yfeng9186.gitee.io/blog/2020/2/linux-%E6%97%B6%E9%97%B4%E5%90%8C%E6%AD%A5%E4%B9%8Bchronyd
除了以上的链接，还有万能的互联网，如果侵权了，可以通过上方文档的邮箱联系我。
本文档的实验环境，是在本地PC上模拟，不是云主机，如果是其他环境请自行测试
时间管理的主要的两个目的：
- 对外，保证本地的时间和国际通用时间保持同步，通过NTP协议与时间源同步
- 对内，保证系统时间和硬件时间保持同步
首先我们先了解一下Linux中和时间有关的一些简单的概念，这些便于以下内容的展开
系统时间：会发现一些比如Universal time，system time，都表示是系统内核进行的处理，和硬件无关
UTC：整个地球分为二十四时区，每个时区都有自己的本地时间，在国际无线电通信场合，为了统一起见，使用一个统一的时间，称为通用协调时(UTC:Universal Time Coordinated)
时区：这里自己可以去网上搜一下，有详细的展开，主要是我们中国使用的是CST，系统默认不是，但是我们通常都是配置CST，所以需要注意一下。
硬件时间（RTC）： The Hardware Clock也可以叫real time clock也就是RTC，一般pc和服务器等设备都有一个和系统无关的小程序，通常是cmos电池维持其运行，不受服务器和操作系统的开启关闭影响，我们可以通过bios或者开机后通过系统设置进行校正。
https://zh.wikipedia.org/wiki/%E7%B6%B2%E8%B7%AF%E6%99%82%E9%96%93%E5%8D%94%E5%AE%9A
啥也不说了，佩服去吧。别说设计了，我看都看不懂NTP的算法，哈哈。
知其然知其所以然，无法更为详细的解释chrony同步时间的一个算法，所里这里只能对其现象进行一些实验。
更为深入的解析，我目前还无法做到，所以各位看官见谅。
如下图是NTP的一个交互过程。
https://www.cnblogs.com/pipci/p/12833228.html
上面说了NTP的协议标准，下面就看NTP协议的一些常见的具体实现，
1、以前Linux时间同步基本是使用 ntpdate 和 ntpd 这两个工具实现的，但是这两个工具已经很古老了
ntpd是步进式平滑的逐渐调整时间，而ntpdate是断点式更新时间。所以当时间偏差比较大的时候ntpd同步就会比较慢，所以经常会有人用crontab来配置ntpdate定时的去更新时间。
2、RHEL/CentOS 7.x及以上版本已经将 chrony 作为默认时间同步工具了，本文主要讨论的就是这个
3、其他Linux (如 ubuntu，debian，openSUSE) 使用 systemd-timesyncd 服务。
systemd-timesyncd是断点式更新时间，也就是时间不同立即更新，这样会对某些服务产生影响，所以在生产环境尽量不要用，在桌面环境或者是系统刚开机时来进行时间同步还是很好的。timesyncd 替代了 ntpd 的客户端的部分。默认情况下 timesyncd 会定期检测并同步时间。它还会在本地存储更新的时间，以便在系统重启时做时间单步调整。systemd-timesyncd只能作为客户端，不能作为NTP服务器，要成为NTP服务器，可以安装chrony、ntpd，或者open-ntp。推荐chrony
4、虚拟机，以下是Vmware的时间同步，但是这个需要安装Vmware tools，这个不是默认安装的，所以一般不用关心，还有就是Esxi等其他的虚机，也要注意这块问题。
这里就不讨论vmware tools的安装了，我目前的环境暂时用不到。而且即使是虚拟机，宿主机也是需要使用上面的一些工具实现时间同步
第一个问题，“我该如何设计时间集群”，这就是架构问题，比如我的k8s集群有3个master节点，一堆node节点，我需要保证整个集群节点的时间一致性。
首先假设每个节点都可以访问公网，那么我们直接都从公共ntp服务器来同步时间。这个时候多个server就是备份，但是要监控主机的公网状态，如果公网不行了，时间同步就会失败。
那如果是无法访问公网的情况，就需要在局域网内自己搭建ntp服务器，但是一个ntp服务器不行，一旦挂了，就会出现无法使用的情况，server可以配置多个用于备份，此时需要使用多个主机来部署ntp server，客户端指定多个ntp server，但是ntp server需要能保证访问公网。否则时间不准确的日志和告警等信息没有参考价值。
也就是说必须要ntp server能够访问公网。此时也需要有监控，否则ntp server无法访问公网提示还提供chrony服务就不合适。
可以把ntp server和etcd集群放在一起，不浪费资源。
http://www.ntp.org.cn/pool
https://www.ntppool.org/zh/
NTP（network time protocol），通过这个协议，来实现网络中时间的同步，端口是UDP 123
和dns类似，总是要有个节点作为参考。
中国国家授时中心 NTP服务器地址是 ntp.ntsc.ac.cn
估计其他公共的NTP服务器的时间源就是上面的地址，但是我们也不用使用这个作为自己的源，因为这个是在北京，就近原则。过去我经常使用的就是ntp.aliyun.com，但是如果说要配置一个公共ntp服务器地址，确实不必要，因为有pool这个东西，类似yum仓库优先使用mirrorlist而不用baseurl一样。
现在我们只需要在chrony中配置地址池的地址，而不是server的地址，它会选择合适的服务器作为源
默认硬件时间是UTC格式的时间，
主要是2个作用把系统时间同步到硬件时间上，或者把硬件时间同步到系统上。
如上可以看出来，RTC的时间会和系统时间发生一定的偏差，此时我们可以使用clock命令来手动的同步。一般默认RTC是使用的UTC格式时间，所以和Universal time对比即可。
RTC in local TZ是no的状态，也不建议修改为yes。
但是会发现RTC和Universal time总是会偏差，不能总是手动clock 吧，懒惰的人类自然是不用的，下面chrony服务配置中有个参数rtcsysnc 每隔11分钟会把系统时间同步到RTC中去。
hwclock --set --date 来修改rtc时间，以便测试。
可以看出来有显示上有一定的区别。
https://www.freedesktop.org/software/systemd/man/systemd-timedated.service.html#
timedatectl就是systemd-timedated.service的客户端
虽然各种把timedatectl和systemd-timesyncd.service联系在一起，在RockyLinux8的man timedatectl的example中也有systemd-timesyncd.service联系，给我造成了一定的误导。可以参考上面的“ntp实现”
NTP service有两个状态active和inactive，可以通过timedatectl set-ntp 来设置。
会把chronyd服务关掉，慎用。不仅仅是停止服务，还会把自启动关闭。
NTP service： 状态更新是比较及时的，ntp服务停了，就是inactive，开启就是active
System clock synchronized：状态就比较复杂一点，不确定这个是根据什么文件等来判断是yes还是no的。
首先chronyc tracking如果是local 本地源的话，这个状态一直是no的。如果chronyc sources没有源，此时也是no，而且如果是local 本地源也会导致chronyc sources没有源，如果有源但是没有状态是^*的，也是no，
有了^*但是system time这里不是0的也是no，
说明代表的意思就是在和时间源同步成功的情况下，并且系统时间同步成功，才会显示yes。
如下图，因为chrony的makestep 1 1， limit是正值，所以这里启动后几次后，就会是慢慢修订而不是直接同步。
所以 System clock synchronized 状态是no，等同步好了，就会变成yes
timedatectl list-timezones可以查看所有的时区
timedatectl set-timezone 然后从上面的Zone选择一个。就会把/etc/localtime文件软连接到指定的时区
问题：timedatectl timesync-status
这个可能安装桌面环境才需要。
server
peer
local
默认配置文件路径：/etc/chrony.conf
具体可以man chrony.conf查看帮助 ，也可以在线帮助，翻译方便。
https://chrony.tuxfamily.org/doc/4.1/chrony.conf.html
按功能分为以下部分的配置：
Time sources：设置时间源，例如：server，peer，pool。
Source selection：时间源的选择
NTP server：主要和作为ntp server相关的参数
Command and monitoring access ：主要是和chronyc相关的一些参数
System clock： 和系统时间相关的参数，把同步来的是时间同步到系统时间上去，例如：makestep
Real-time clock (RTC)：和rtc相关的一些参数，把同步来的时间同步到硬件时间上去，例如：rtcsync
logging：和chronyd日志相关的参数。
chronyd服务启动后会启用2个端口
123/udp 用于提供ntp server 服务
323/udp 用于提供chronyc连接的管理端口。
https://www.ntppool.org/zh/use.html
pool/server 用于指定chrony同步时间的时间源，两个指令可以同时使用
pool <hostname> [option]...
option有个maxsources默认是4，最大16。
如下图所示，pool是个公益项目，看自己需求，使用默认参数即可。没必要修改maxsources
server <hostname> [option]... 指令最好配置3个，用于备份，所以本地网络中最好有3个ntp server。这样即使1个挂了，还有备份。
iburst表示的是首次同步的时候快速同步，chronyc中可以使用交互式命令，online和offline快速启用和禁用server。实现这个过程。
如上我们指定了多个server和pool，如何选择时间源。
这里就需要时间源选择算法，核心就是在多个时间源中如何选择合适的一个时间源
stratumweight distance：stratumweight指令设置当chronyd从可用时间源中选择同步源时，每一stratum应添加多少同步距离。
默认情况下，该值是0.001秒。这意味着，在选择同步源的过程中，只有当时间源距离之间的差异以毫秒为单位时，时间源的stratum才有意义。在chronyd选择同步时间源时，即使处于stratum低层级的时间源距离更远，也比另一个处于stratum高层次的时间源更容易被选中。将stratumweight设置为0时，可以使chrongyd选择时间源时忽略stratum层次。
也就是说假设一个是10层，一个是3层，假设当前3层给的时间是10:00:001，10层给的时间是10:00:002此时看时间小的，不看stratum高的也就是数字小的，如果当前3层给的时间是10:00:009,10层给的是10:00:001，此时选择哪个source作为时间源呢？
allow指令：需要配置，让chronyd去响应客户端请求，如果allow后不跟子网或主机地址就是响应所有来自ipv4和ipv6的访问
bindaddress：chrony的ntp服务监听在哪个ip上
binddevice：chrony的ntp服务监听在哪个接口port：chrony对外提供ntp server的端口，默认是123，port可以配置为0，表示只作为ntp client同步时间，不提供ntp server服务。此时如果allow没配置的话，那么此时也不需要添加 port 0的指令。
！！！如果allow不开启的话，port和bindaddress、binddevice没有意义，因为不会监听。
local ：当本地ntp server的外部的time sources不可用时，可以用本地时间去给内部网络的客户端去同步时间。
这句话怎么理解呢，用人话就是，如下图，如果我不配置local指令，当无sources源可用的时候，不会启用local preference mode，无法提供ntp server的服务了。
如果配置了local指令，当chrony的其他源无法同步的时候，才会启用本地参考模式。否则不会启用，此时stratum是随着当前同步的时间源的值而变化，而不是配置的值。比如当前chrony同步的是源stratum是2，那么chrony服务器的stratum就是3，如果chrony同步的是源stratum是3，那么chrony服务器的stratum就是4。如果没有同步的源了，那么stratum就是配置的值了。
orphan说是在孤岛网络里使用，这个一直无法验证。即使我3台都配置了local stratum 10 orphan，但是都是^X的状态，不会说去选择reference id最小的，不知道为何。
https://access.redhat.com/documentation/zh-cn/red_hat_enterprise_linux/8/html/configuring_basic_system_settings/setting-up-chrony-for-a-system-in-an-isolated-network_using-chrony
把从时间源同步的时间同步到系统时间上。
makestep threshold limit threshold：表示阈值，系统时间和时间源之间的偏差，单位秒
不受limit的影响，这个是makestep的前提条件，也就是说如果本地和时间源的时间偏差超过多少秒，才会触发step断点式更新，直接同步时间。
limit：限制次数，允许chrony启动后，快速去修正同步多少次，超过次数后则会采用slew time的方式，慢慢的修正，如果相差时间过大，会很慢；如果为负值，则不限制次数，step方式去更新系统时间，
说是步进时钟（时间跳跃）可以快速修正偏差较大的时间误差，但是有可能会导致一些程序异常，因此应当慎用这个选项，但是不使用的话，会导致时间无法修复。不是更影响程序吗。
这里有个问题，为何不把threshold设置小，默认是1s，可以设置0.1s，这样影响应该就不大了吧。这里主要是影响程序的时间阈值不好判定，1s可以避免频繁的step 修正。当然如果设置为0.1也没有造成频繁的step修正的话，也可以设置为0.1s，看你能接受的时间偏差范围。
makestep 0.1 -1
rtcsync：rtcsync指令启用系统时间定期复制到 RTC 并且chronyd不会尝试跟踪其漂移的模式。该指令不能与rtcfile指令一起使用。
前提是，系统时钟必须是同步的，也就是system clock synchronized是yes的状态。
在 Linux 上，内核每 11 分钟执行一次 RTC 复制。
在 macOS 上，当系统时钟处于同步状态时， chronyd将每 60 分钟执行一次 RTC 复制。
在其他系统上，该指令什么也不做。
遇到的问题：
问题：如下图所示，没有生效，11分钟过去了，rtc依然没有从 system time同步。
修改rtcsync改为rtcfile，结果出现rtc不可用情况
以为master1是把公网关了，使用的是本地时间做为时间源。所以测试下master2，master2以master1作为时间，修改下master2的rtc时间，看master2会不会在11分钟的时候更新rtc时间。
果然在11分钟的时候更新了。
结论就是：
rtcsync同步的关键是要系统时钟同步状态是yes才可以。
rtcfile启用后，hwclock无法正常使用。rtcfile和hwclock是互斥的。
logdir定义了chronyd日志的目录
log 定义日志的文件，仅仅定义了logdir是没有用的。
rtc日志，需要配置rtcfile /var/lib/chrony/rtc，当chronyd退出或者其他原因会把便宜保存到/var/lib/chrony/rtc中，第一次不会生成这个文件。
rtcsync不能配置，配置了，也不会产生rtc.log
这里面就想看下chronyd服务自己的一些日志，但是没有。上面那些日志的格式，都是常人无法理解的信息。
下面系统日志提示的都是一些终结态的信息，其中的一些逻辑判断信息，这里没有。
所以你不知道为啥它就判断没有可用的源了，然后就检测到时间便宜了，然后又选择到了可用的时间源，然后由修订了时间。
客户端工具，本地的话建议使用交互式命令，方便，如下help可以看到所有支持的命令
MS：M代表source mode，一般都是^表示server，配置文件中指定的也是server
主要是S，source state，
？：代表不可用，
*：代表当前同步的时间源
+/-：
x：
Stratum：表示的是时间源的层级，不是自己的层级。取值范围是1-15
Poll： 表示对时间源进行轮询的频率。Poll 为6，表示每隔2^6=64s(秒)对该时间源轮询，Poll 为9就是每隔2^9=512s(秒)。chronyd会根据情况自动调整轮询频率，所以这里会看到这个值在变化。
Last sample ：
xxxx 【yyyy】 +/- zzzz 可以看到这里的单位有ns/us/ms/s
1秒(s) ＝1000毫秒(ms)
1毫秒(ms)＝1000微秒 (us)
1微秒(us)＝1000纳秒 (ns)
这一列显示了最后一次测量到的本地时间与时间源之间的偏移量。
yyyy表示实际测量的偏移量，。
xxxx的数字显示的是最初的测量值，经过调整后可以应用到本地时钟上。‘+/-’符号后的数字显示的是测量误差。‘+’表示本地时钟比时间源快。
zzzz
Stratum：这个是相对Reference id的层级，这里是3，说明Reference id的层级是2，在chronyc sources中看到的这个时间源的stratum值应该是2.
Ref time：就是上次同步的时间源给的时间
Update interval：同步的间隔，64s左右，基本上是chronyc sources中pool的时间，2^6=64s
System time：这个就是本地时间和时间源提供的Ref time之间的差距，这里是slow of Ntp time也就是比时间源慢了，因为我虚拟机挂机后打开的，因为我makestep的limit是正值，所以它只能slewing 慢慢的修正。
如果相差时间过大，那么slew修订的时间会巨慢，可以尝试date -s 先修订下时间
Frequency、Residual freq、Skew：ppm （part per million）百万分之一，算法需要的值，反正解释了我也不理解，就算了吧。
手动同步系统时间。
有一定延迟，说是强制同步系统时间，但是并不是像date -s 一样系统时间时间直接就变了。
而且会使chrony重新选择时间源，不知道这个命令的意义是啥，和重启chrony有啥区别
chronyd -q 'server ntp.aliyun.com iburst'
还不如在chrony启动前去执行这个命令，但是这玩意有和makestep 1 3里面的前几次跳跃式同步也没啥区别。
这里可以看到，chronyc tracking的时候，
Ref time是正确的，但是system time并没有修订。所以同步时间是没有问题的，但是没有把系统的时间给修订掉。
可以看到时间是慢慢调整，不是跳跃式的调整，此时相差时间太大，无法快速修订。
通过chronyc makestep快速同步了system clock，但是RTC时间chrony并没有间隔11分钟，把系统时间同步到rtc上，手动执行hwclock -w才同步。所以为什么rtc时间没同步呢。
这个问题在上面的配置部分，Real time clock部分有解释。但是为什么时间同步了，system clock sysnchronized还是没有变成yes，这里可能是状态的一个延迟问题。
结论就是：
当makestep threshold limit中，limit是正值的时候，Backward time能跃进的修订，但是Forward time慢慢修订。
当是负值的时候，Backward time和Forward time都能跃进的修订。
“Can't synchronise: no selectable sources” 这个不是关键问题，容易误导人
过了一个小时的时间，才判断时间源无效。此时local stratum 10生效。
因为我master1 时间和其他时间源相差过大，所以这里是x的状态，如果我把master2其他源去掉后重启
如下图。就是简单的局域网ntp client和server关系。当然备份的考虑，我这里办本地的ntp server可以多个。
下面一个问题就是多个ntp server的问题
当我把其中一个服务器上的chrony服务停掉后
发的包，181和183reference id报文里都是127.127.1.1，但是落地显示不一样呀。
结论就是：
如果所有ntp server都不能有自己的time source的话，就是不配置server，local preference mode，只能有一个，local stratum xxx 只能配置在一个server上，也就是只能有一个server。所以尽量保证ntp server可以访问internet的时间源，然后选择一个ntp server配置local stratum用来保底。
想要看同步的效果等，可以使用date来设置时间，然后来测试效果。
防止中间人攻击，使用安全的方式
到此这篇chronyd（chrony端口）的文章就介绍到这了,更多相关内容请继续浏览下面的相关推荐文章，希望大家都能在编程的领域有一番成就！版权声明：
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如若内容造成侵权、违法违规、事实不符，请将相关资料发送至xkadmin@xkablog.com进行投诉反馈，一经查实，立即处理！
转载请注明出处，原文链接：https://www.xkablog.com/hd-yjs/78052.html