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！