OpenShift 4中etcd同步时间的调整

OpenShift Etcd集群每隔100ms会检测心跳。若是OpenShift的环境网络条件差，Master节点之间网络延迟超过100ms，则可能致使群集中的不稳定和频繁的leader change（详见https://access.redhat.com/solutions/4885601）。EtcdLeader的选举，默认必须在1s以内完成，不然OpenShift集群为了保护etcd数据的一致性，将暂停对集群的配置更改类操做。出现以下报错：

查看etcd的日志，能够看到以下内容（网络延迟过大，形成etcd member没法同步）

此外，存储的超时也会对Etcd形成严重影响。要排除磁盘缓慢致使的Etcd警告，能够监视指标backend_commit_duration_seconds（p99持续时间应小于25ms）和wal_fsync_duration_seconds（p99持续时间应小于10ms）以确认存储速度正常（详见https://access.redhat.com/solutions/4770281）。须要注意的是，若是存储已经出现明显的性能问题，就没必要再进行测试。Etcd用于保存OpenShift全部的元数据和资源对象，官方建议将Master和Etcd部署在相同的节点，也就是Etcd数据保存在Master节点的本地磁盘，默认在/var/lib/etcd/目录下，该目录最小须要20 GB大小的存储。因此最好master本地使用SSD磁盘。OCP4.8将容许为etcd设置独立的磁盘。

针对OCP上ectd集群的同步时延较小的状况，能够根据环境考虑适当调整。相关的参数主要有两个：

name:ETCD_ELECTION_TIMEOUT

name:ETCD_HEARTBEAT_INTERVAL

第一个参数的默认值：

"name":"ETCD_ELECTION_TIMEOUT","value":"1000"

第二个参数的默认值：

"name":"ETCD_HEARTBEAT_INTERVAL","value":"100"

    那么，ETCD_HEARTBEAT_INTERVAL 100ms的这个数值小不小？其实不小！Heartbeat Interval是leader给follower发送心跳的时间间隔，这个时间值应该是两个peer之间的RTT(round-trip time)值，其默认值是100ms。ElectionTimeout则是心跳超时时间，若是这个时间超时后follower尚未收到leader发来的心跳，则follower就认为leader失联，而后发起election，默认值是1000ms。

HeartbeatInterval通常取值集群中两个peer之间RTT最大值，取值范围是[0.5 xRTT, 1.5 x RTT)。若是这个值过大，则会致使很晚才会发现leader失联，影响集群稳定性。Election Timeout则依赖Heartbeat Interval和集群内全部RTT值的平均值，通常取值平均RTT的十倍，这个值的最大值是50,000ms（50s）,这个值只有在全球范围内部署的时候才使用。在全美大陆，这个值应该是130ms，而美国和日本之间则应该是350-400ms，全球范围的RTT通常是5s，因此全球范围的Election Timeout取值50s做为上限为宜。

因此是，跨美国大陆的网络延迟，应该是130ms，那在数据中心内部，OCP这个数字设置为100ms，一点也不小。若是大于这个值，说明数据中心内部网络真的很差。对于数据中心，首先应该考虑的是应该如何下降网络延时，而不是调大这个参数，不然业务的性能也会受影响。但若是非要调大这个数字，好比在开发测试环境，网络就是差，短期就是不想或者不能改善网络。有没有办法？

有。

OCP4上etcd是static pod，咱们能够经过修改pod的yaml文件来修改配置。yaml文件位于三个master节点上的/etc/kubernetes/manifests/etcd-pod.yaml中，并且有四处修改的位置。而且三个master节点都须要修改（记住，是三个master节点，每一个参数有4处修改的位置！！）。

咱们将ETCD_ELECTION_TIMEOUT设置为5s，将ETCD_HEARTBEAT_INTERVAL设置为1s。第一个值至少是第二个值的5倍，不然会报错！（--election-timeoutshould be at least as 5 times as --heartbeat-interval）

配置修改后，etcd static pod会自动重启，让配置生效。

咱们确认配置已经生效，首先oc rsh到etcd pod中，查看环境变量（参数以环境变量方式注入）：

# oc rsh etcd-master-0.weixinyucluster.bluecat.ltd

咱们验证删除etcd pod看配置是否还有效。

将etcd pod删除，pod自动重建后，配置依然有效。

咱们经过oc describe也能够验证参数：

接下来，咱们验证重启master节点，配置是否有效。重启master0.

master0重启完毕：

节点重启后，etcd会有初始化的操做：

很快，初始化成功，etcd pod的三个容器都启动了：

查看我修改的参数，依然有效：

最后，咱们验证升级OCP集群，这个参数是否还有效：

升级前：

升级：

升级后，咱们再查看设置的参数，发现已经被重置。

结论：两个参数的设置，对于OCP重启、etcd pod删除仍然有效。但对于升级，配置会失效。若是须要对应的数值，须要从新设置。但生产上，仍是先把网络优化好，再安装OCP！