Firewalld reload引起的ETCD超时故障排查

测试人员在系统使用过程中发现页面会时不时卡顿一会儿，查看日志后发现是由于etcd访问超时引起的：

# 访问超时

{"level":"warn","ts":"2022-03-30T17:35:37.733+0800","caller":"clientv3/retry_interceptor.go:62","msg":"retrying of unary invoker failed","target":"endpoint://client-81685990-3b94-4e45-a30b-3cd6b82579a5/nsp-etcd:22379","attempt":1,"error":"rpc error: code = Unknown desc = context deadline exceeded"}

# etcd切换leader

{"level":"warn","ts":"2022-03-30T17:35:34.001+0800","caller":"clientv3/retry_interceptor.go:62","msg":"retrying of unary invoker failed","target":"endpoint://client-81685990-3b94-4e45-a30b-3cd6b82579a5/nsp-etcd:22379","attempt":0,"error":"rpc error: code = Unavailable desc = etcdserver: leader changed"}

超时和重新选举的截图： 

学习了一下etcd的工作原理和raft协议，发现我们设置的参数对网络质量要求较高，—election-timeout值为100，100m收不到心跳就会重新选举，所以就需要检查是什么原因导致的超时。

写了个脚本对几个方向的网络目标进行长ping，ping的间隔设置为1秒10次，发现确实会偶尔出现丢包现象，因为丢包时间很短（少于1秒），因此使用常规的ping无法发现。

排查了各种会导致网络丢包的组件，最终定位在firewalld，每次修改规则后我们都使用了reload来重新加载规则，这种方式会导致系统iptables规则重置，出现短暂的丢包。

修改了firewalld的配置方式，问题得到了解决。