k8s--记一次“怪异”的时间修改导致的系列问题

IT那活儿 2022-02-14

3152

点击上方“IT那活儿”，关注后了解更多精彩内容！！！

故障背景

某日，k8s上运行的一些业务反应服务出现异常，几个业务均出现不同程度的业务慢或者业务无法使用的情况，而且访问ceph集群也出现缓慢或者mount的fs无法读取等问题。

经过简单的分析，最后汇总了各自业务问题后，我们发现了业务客户端时间与当前时间都存在相差8小时的问题，导致了业务的失败。

以下将整个事件的前因后果及分析过程与大家分享一下。

分析过程

1. 因为本人负责k8s的后端ceph存储，所以在接到问题的第一时间后，检查了ceph的存储情况，确实发现了有少许客户端响应超时的问题，具体如下：

2. 为了查看具体的客户端信息，登录mds服务器，运行ceph daemon mds.`hostname` dump_blocked_ops 查看具体被阻塞的客户端如下：

3. 通过以上可以看到具体的客户端为client.151504，然后通过ls命令查看具体客户端使用的目录，判断使用目录为/we***，进而锁定业务W以及客户端IP为IP-9。

ceph tell mds.`hostname` client ls |grep -E "inst|num_caps|root”

4. 因为业务使用的是容器运行，对于ceph集群来说，只能查到客户端的宿主机具体地址IP-9，具体对应的容器已经无法查到了。

于是通知管理k8s集群的同事，检查对应的IP-9主机上的W业务所使用的容器是否正常。

5. 经过检查容器确实对ceph的目录访问出现卡顿而且ls等命令无法正常显示出。

同时进一步检查日志等情况，会发现时间偏差的告警。

6. 再进一步检查服务器时间，date显示时间与当前时间相差8小时。

于是对服务器的messages日志进行分析，发现时间被更改，而且NTP同步暂未完成。

业务恢复

原因确认是时间异常后，对此IP-9服务器的时间进行同步并恢复，但业务自愈性较差，于是对容器内的业务进程进行了重启恢复，重启后业务恢复正常，ceph侧的异常客户端告警warn也消失了，状态恢复为OK。

锁定“真凶”

虽然业务恢复，但是更改时间的根因却一直未找到，直到锁定了近期刚迁移进来的业务A。

因为A主机所在的IP-8主机才出现过同样时间异常的问题，而服务异常后，我们将此服务A由IP-8主机迁移到了IP-9主机。

巧的是迁移后的第二天就再次出现了文中的上述问题，于是在询问了业务A的相关人员后，最终锁定了“真凶”就是业务A。

业务A因为容器内使用的是UTC时区，所以应用date显示的时间数字与我们一般使用的CST时区在数字上相差了8小时。

但是其实两者时间是一致的，只是显示的差异问题。所以，我们的业务A相关人员就对容器里的时间进行了手动修改，然后影响到了整台宿主机。

问题复盘

虽然“真凶”最终抓获，但是容器更改的时间影响了宿主机，这显然是一个并不合理的解释。

因为理论上容器所拥有的权限更改时间这种类似的操作是不允许延伸到影响容器所在的宿主机的。

于是，为了进一步了解这个bug一样的设定，我们深入分析了一下容器所使用的镜像。

最终定位是因为此业务A镜像的加入集群，并未进行镜像安全相关的扫描和审核，导致使用的自有容器镜像默认具有很高的权限，进而导致了容器中更改时间影响到了宿主机。

此结论我们在经过审核的镜像中得到验证，使用date修改审核过的容器的时间，并不会影响宿主机时间。

至此，“怪异”的事件总算最终尘埃落定。而且还需提醒一下小伙伴们使用date命令时，一定要留意命令结果中显示的是CST还是UTC或者其他时区，要修正时间的话，切记要先修正了时区后，再修正时间。

在看

文章转载自IT那活儿，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。