云原生后端微服務(wù)DevOpsAI 應(yīng)用【免費下載鏈接】rainbond無需學習 Kubernetes 的容器平臺在 Kubernetes 上構(gòu)建、部署、組裝和管理應(yīng)用無需 K8s 專業(yè)知識全流程圖形化管理項目地址https://gitcode.com/goodrain/rainbond點擊查看免費下載etcd 是 Rainbond 平臺底層依賴的關(guān)鍵分布式鍵值存儲組件本指南以倉庫內(nèi)置的 etcd 2.3 升級到 3.0 官方文檔third_party/coreos-etcd/Documentation/upgrades/upgrade_3_0.md為核心系統(tǒng)講解升級前置檢查、備份策略、混合版本行為、滾動升級五步操作法以及回退限制并結(jié)合倉庫源碼剖析版本協(xié)商與集群版本判定的底層原理幫助讀者在 Rainbond 環(huán)境中安全、可回退地完成 etcd 主版本升級。一、升級總覽一次零停機滾動升級在一般情況下etcd 從 2.3 升級到 3.0 可以做到零停機滾動升級其核心思想非常簡單逐個停止 etcd v2.3 進程并替換為 etcd v3.0 進程當集群中所有成員都運行 v3.0 之后v3.0 新增特性才對整個集群開放。這種逐個替換的方式之所以可行是因為 etcd 集群在設(shè)計上允許成員以混合版本運行一段時間詳見下文混合版本一節(jié)。在動手執(zhí)行升級之前務(wù)必通讀本指南的檢查清單并逐項準備尤其是健康檢查、數(shù)據(jù)備份與回退路徑不要跳過。從倉庫結(jié)構(gòu)看third_party/coreos-etcd 目錄完整內(nèi)置了 etcd 源碼與官方 Documentation本文所講的升級流程即對應(yīng)其中Documentation/upgrades/系列升級指南的第一篇Rainbond 自身的代碼則全部基于etcd v3 clientclientv3與 etcd v3 數(shù)據(jù)模型進行開發(fā)見 util/etcd/client.go 中NewClient的注釋new etcd client v3 for all rainbond module, attention: do not support v2因此在 Rainbond 語境下完成 2.3 → 3.0 的遷移意味著平臺各模塊能夠真正接入 v3 數(shù)據(jù)面與 v3 API。二、升級檢查清單Upgrade checklists2.1 版本前提Upgrade requirements升級到 3.0 的前提是當前正在運行的集群版本必須是 2.3 或更高。如果集群版本低于 2.3請先升級到 etcd 2.3 版本再執(zhí)行本指南的 3.0 升級流程此外為了確保滾動升級平滑進行運行中的集群必須是健康的healthy。在動手之前務(wù)必使用etcdctl cluster-health命令確認集群健康狀態(tài)。2.2 升級前準備Preparation先在預(yù)發(fā)/測試環(huán)境驗證升級 etcd 之前務(wù)必先在預(yù)發(fā)環(huán)境測試所有依賴 etcd 的服務(wù)確認無誤后再部署到生產(chǎn)環(huán)境備份數(shù)據(jù)目錄升級開始前按照官方 v2 管理指南中 Backing up the datastore 一節(jié)的方法備份 etcd 數(shù)據(jù)目錄倉庫中對應(yīng)文檔位于 third_party/coreos-etcd/Documentation/v2/admin_guide.md目錄內(nèi)亦提供基于 systemd 的備份腳本 third_party/coreos-etcd/contrib/systemd/etcd2-backup-coreos。如果升級過程中出現(xiàn)問題可以借助這份備份回退downgrade到原有 etcd 版本另外升級過程中還應(yīng)當為所有 etcd 成員都保存一份數(shù)據(jù)目錄備份這樣即使在集群整體升級完成之后也保留了將集群回退到 v2.3 狀態(tài)的可能性詳見下文回退一節(jié)。2.3 混合版本行為Mixed versions升級過程中etcd 集群支持成員以混合版本運行并統(tǒng)一按照最低公共版本the lowest common version的協(xié)議工作只有所有成員都升級到 v3.0 之后集群才被認定為完成升級在內(nèi)部etcd 各成員之間會相互協(xié)商以確定整個集群的版本cluster version該版本決定了對外上報的版本號以及可用的功能特性capabilities。倉庫源碼印證了這一機制third_party/coreos-etcd/etcdserver/cluster_util.go 中的decideClusterVersion函數(shù)會遍歷所有成員上報的Server版本取最小版本作為集群版本同時isCompatibleWithCluster/isCompatibleWithVersthird_party/coreos-etcd/etcdserver/cluster_util.go會校驗各成員的集群版本是否落在[MinClusterVersion, Version]范圍內(nèi)超出范圍的成員會被判定為不兼容。當集群版本最終變化時third_party/coreos-etcd/etcdserver/membership/cluster.go 會記錄 updated the cluster version from ... to ... 并將新版本持久化到 store——這正是升級日志中那條關(guān)鍵消息的來源。2.4 升級限制Limitations升級過程有兩個重要的時間預(yù)期請據(jù)此安排節(jié)奏數(shù)據(jù)量大于 50MB 時新升級的成員追上集群進度可能需要最多 2 分鐘。可以查看最近一次快照的大小來估算總數(shù)據(jù)量。換句話說最穩(wěn)妥的做法是每升級完一個成員后等待 2 分鐘再升級下一個數(shù)據(jù)總量達到 100MB 或更大時這次一次性追趕過程耗時會更長。管理超大規(guī)模 etcd 集群的運維人員可以在升級前聯(lián)系 etcd 團隊咨詢操作建議。2.5 回退Downgrade關(guān)于回退需要明確兩條規(guī)則一旦所有成員都升級到 v3.0集群整體版本即升級為 v3.0此時無法再回退從已完成升級的終態(tài)回退是不可能的只要還有任何一個成員仍停留在 v2.3整個集群及其操作就仍處于 v2.3 語義之下此時可以從這種混合集群狀態(tài)恢復(fù)為全部成員運行 v2.3 二進制。因此務(wù)必在升級前為所有 etcd 成員備份數(shù)據(jù)目錄為集群在完全升級后仍保留可回退能力。三、升級操作五步法Upgrade procedure下面以運行在本機的三節(jié)點 v2.3 etcd 集群為例給出完整的升級步驟。三個成員的客戶端端口分別為12379、22379、32379對應(yīng) peer 端口12380、22380、32380。第 1 步檢查升級前提確認集群健康且運行在 v2.3.x$ etcdctl cluster-health member 6e3bd23ae5f1eae0 is healthy: got healthy result from http://localhost:22379 member 924e2e83e93f2560 is healthy: got healthy result from http://localhost:32379 member 8211f1d0f64f3269 is healthy: got healthy result from http://localhost:12379 cluster is healthy $ curl http://localhost:2379/version {etcdserver:2.3.x,etcdcluster:2.3.8}etcdctl cluster-health輸出中每個成員都返回 healthy、最后一行輸出cluster is healthy說明集群健康/version接口返回etcdserver與etcdcluster兩個字段前者是服務(wù)版本后者是集群版本2.3.x / 2.3.8滿足升級前提。第 2 步停止現(xiàn)有 etcd 進程逐個停止 v2.3 etcd 進程。停止某個成員時其他成員會輸出預(yù)期中的錯誤日志——這是因為集群成員連接被暫時斷開了屬于正?，F(xiàn)象2016-06-27 15:21:48.624124 E | rafthttp: failed to dial 8211f1d0f64f3269 on stream Message (dial tcp 127.0.0.1:12380: getsockopt: connection refused) 2016-06-27 15:21:48.624175 I | rafthttp: the connection with 8211f1d0f64f3269 became inactive此時是一個理想的備份時機建議立即備份 etcd 數(shù)據(jù)目錄為可能出現(xiàn)的任何問題保留回退路徑$ etcdctl backup \ --data-dir /var/lib/etcd \ --backup-dir /tmp/etcd_backup第 3 步放入 v3.0 二進制并啟動新進程將二進制替換為 etcd v3.0 并啟動。新的 v3.0 成員會向集群發(fā)布自身信息09:58:25.938673 I | etcdserver: published {Name:infra1 ClientURLs:[http://localhost:12379]} to cluster 524400597fb1d5f6隨后驗證該成員乃至整個集群在新二進制下恢復(fù)健康$ etcdctl cluster-health member 6e3bd23ae5f1eae0 is healthy: got healthy result from http://localhost:22379 member 924e2e83e93f2560 is healthy: got healthy result from http://localhost:32379 member 8211f1d0f64f3269 is healthy: got healthy result from http://localhost:12379 cluster is healthy在整個集群全部升級完成之前已升級的成員會持續(xù)輸出如下告警日志這是混合版本階段的預(yù)期現(xiàn)象待所有成員都升級到 v3.0 后即會消失2016-06-27 15:22:05.679644 W | etcdserver: the local etcd version 2.3.7 is not up-to-date 2016-06-27 15:22:05.679660 W | etcdserver: member 8211f1d0f64f3269 has a higher version 3.0.0這兩條告警的源碼出處正是前面提到的decideClusterVersion當發(fā)現(xiàn)本機版本低于某個成員時會依次打出 the local etcd version ... is not up-to-date 與 member ... has a higher version ...見 third_party/coreos-etcd/etcdserver/cluster_util.go。第 4 步對其余成員重復(fù)第 2、3 步對所有剩余成員依次執(zhí)行停止 → 備份 → 啟動 v3.0并且如前文所述在數(shù)據(jù)量較大時每升級一個成員后等待約 2 分鐘給新成員留出追趕進度的時間。第 5 步完成當所有成員都升級完成后集群會報告升級到 3.0 成功2016-06-27 15:22:19.873751 N | membership: updated the cluster version from 2.3 to 3.0 2016-06-27 15:22:19.914574 I | api: enabled capabilities for version 3.0.0第一條日志即由 third_party/coreos-etcd/etcdserver/membership/cluster.go 中的集群版本更新邏輯輸出第二條則來自 third_party/coreos-etcd/etcdserver/api/capability.go 的UpdateCapability——集群版本提升后對應(yīng)版本的新增能力capabilities才會被啟用。使用 v3 API 再次確認所有端點健康$ ETCDCTL_API3 etcdctl endpoint health 127.0.0.1:12379 is healthy: successfully committed proposal: took 18.440155ms 127.0.0.1:32379 is healthy: successfully committed proposal: took 13.651368ms 127.0.0.1:22379 is healthy: successfully committed proposal: took 18.513301ms注意這里已切換為ETCDCTL_API3環(huán)境變量與endpoint health子命令這是 v3 API 對應(yīng)的健康檢查方式。四、進一步注意事項Further considerations升級到 v3 之后etcdctl 的環(huán)境變量體系發(fā)生了變化如果ETCDCTL_API2 etcdctl cluster-health工作正常但ETCDCTL_API3 etcdctl endpoint health報錯Error: grpc: timed out when dialing請務(wù)必使用 etcdctl 文檔中定義的新變量名v3 采用 gRPC 通信需要正確的端點與連接參數(shù)v3 相關(guān)的運維命令與 v2 差異明顯例如 v3 中查詢端點狀態(tài)使用ETCDCTL_API3 etcdctl --endpoints127.0.0.1:2379 endpoint status參見 third_party/coreos-etcd/Documentation/op-guide/versioning.md而 v3 的快照備份使用etcdctl snapshot save backup.db參見 third_party/coreos-etcd/Documentation/op-guide/maintenance.md。五、已知問題Known Issues官方文檔明確記錄的 v2.3 → v3.0 升級相關(guān)已知問題如下升級前請對照排查Go 版本與 etcd 版本兼容性使用 Go 高于 v1.7 構(gòu)建的 etcd v3.1 以下版本無法正常工作對應(yīng)官方 Issue 6951gRPC/HTTP2 傳輸錯誤如果 etcd 服務(wù)端日志出現(xiàn)transport: http2Client.notifyError got notified that the client transport was broken unexpected EOF.請確認 etcd 使用的是官方預(yù)編譯發(fā)布版或者滿足(etcd v3.1 且 go v1.7)或(etcd v3.1 且 go v1.6.x)的構(gòu)建組合升級期間禁止變更成員向 v2.3 集群添加 v3 節(jié)點是不被支持的可能觸發(fā) panic對應(yīng)官方 Issue 7429?；旌习姹局辉试S在 v3 遷移過程中存在請務(wù)必在所有成員升級完成后再進行任何成員變更增刪成員等。六、Rainbond 環(huán)境中的 etcd v3 落地參考完成 2.3 → 3.0 升級的最終目的是讓上層服務(wù)真正使用 v3 數(shù)據(jù)面。倉庫源碼顯示 Rainbond 各模塊對 etcd 的接入已經(jīng)全面基于 v3統(tǒng)一客戶端util/etcd/client.go 定義ClientArgs含Endpoints、DialTimeout、AutoSyncInterval及CaFile/CertFile/KeyFile三個 TLS 參數(shù)并通過NewClient創(chuàng)建clientv3.Client默認DialTimeout為 5 秒、AutoSyncInterval為 10 秒TLS 三項證書同時配置時才會啟用加密連接分布式鎖/選主util/etcd/etcdlock/master.go 基于clientv3/concurrency的Election與Session實現(xiàn)主節(jié)點選舉CreateMasterLock支持自定義選舉名稱、競選者標識與 lease TTL第三方服務(wù)發(fā)現(xiàn)worker/appm/thirdparty/discovery/etcd.go 展示了 Rainbond 作為 etcd v3客戶端消費數(shù)據(jù)的真實場景——通過cli.Get(ctx, key, c.WithPrefix())拉取端點列表并使用cli.Watch監(jiān)聽鍵變更實現(xiàn)第三方服務(wù)的動態(tài)發(fā)現(xiàn)與在線狀態(tài)同步。這些實現(xiàn)全部依賴 etcd v3 API 與 v3 存儲模型因此對運行 etcd 的版本有硬性要求——這也是本文檔所指導(dǎo)的 2.3 → 3.0 升級在 Rainbond 技術(shù)棧中具有實際意義的原因。若 Rainbond 環(huán)境內(nèi)的 etcd 仍運行在 2.x 版本請按照上述五步法完成升級使平臺各模塊能夠穩(wěn)定接入 v3 數(shù)據(jù)面。七、總結(jié)etcd 2.3 → 3.0 的升級是一條逐節(jié)點滾動替換的路徑升級前確認版本與健康狀態(tài)、為每個成員備份數(shù)據(jù)目錄升級中容忍混合版本與階段性的告警日志利用最低公共版本協(xié)商機制保證集群協(xié)議一致升級完成后以ETCDCTL_API3的 v3 命令驗證端點健康。牢記兩條紅線——完全升級后不可回退、升級期間不得變更成員——即可在 Rainbond 環(huán)境中以最小風險完成這次關(guān)鍵的存儲層主版本遷移。贊分享云原生后端微服務(wù)DevOpsAI 應(yīng)用【免費下載鏈接】rainbond無需學習 Kubernetes 的容器平臺在 Kubernetes 上構(gòu)建、部署、組裝和管理應(yīng)用無需 K8s 專業(yè)知識全流程圖形化管理項目地址https://gitcode.com/goodrain/rainbond點擊查看免費下載相關(guān)推薦Rainbond 內(nèi)置 etcd 集群從 3.0 滾動升級到 3.1 全流程指南Rainbond 內(nèi)置 etcd 集群從 3.0 滾動升級到 3.1 全流程指南 導(dǎo)讀本指南圍繞 etcd 官方升級文檔 upgrade_3_1.md ht云原生后端微服務(wù)DevOpsAI 應(yīng)用Rainbond 內(nèi)嵌 etcd 升級指南從 v2.3 到 v3.x 的零停機滾動升級與 API 遷移Rainbond 內(nèi)嵌 etcd 升級指南從 v2.3 到 v3.x 的零停機滾動升級與 API 遷移 本篇技術(shù)指南以 Rainbond 倉庫內(nèi)嵌的 etcd云原生后端微服務(wù)DevOpsAI 應(yīng)用Rainbond 內(nèi)置 etcd 升級指南從 3.4 到 3.5 的滾動升級完整手冊Rainbond 內(nèi)置 etcd 升級指南從 3.4 到 3.5 的滾動升級完整手冊 導(dǎo)讀 etcd 是 Rainbond 控制面API 服務(wù)、構(gòu)建任務(wù)、事云原生后端微服務(wù)DevOpsAI 應(yīng)用上一篇archinstall Python 插件機制解析加載方式、on_* 鉤子與自研插件實踐下一篇Windows 11終極優(yōu)化指南免費開源工具Win11Debloat讓你的系統(tǒng)性能提升51%創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考