背景

• 注冊中心式CP，東西向流量；
• 云原生網關式CP，南北向流量；
• ServiceMesh式CP，東西向、南北向流量；
• CMDB式CP，運維、架構依賴式流量；

這種方式是如何微服務的訪問呢？

• 網關+CMDB完成應用訪問路由和應用系統的關聯；

• 微服務+CMDB完成應用系統和服務器資源的關聯；

福兮禍所依

• overlay網絡，那東西向流量就必須使用注冊中心或ServiceMesh解決方案，與CMDB再集成意義不大；

• underlay網絡，那容器IP可以直接關聯業務網段，通過CMDB按業務、應用系統與容器IP進行關聯；

當然，天無絕人之路！

禍兮福所伏

Init容器+PostStart

• Init容器， 在 Pod 內的應用容器啟動之前運行， 它們總是運行到完成。如果 Pod 的 Init 容器失敗，kubelet 會不斷地重啟該 Init 容器直到該容器成功為止。
• PostStart鉤子，回調在容器被創建之后立即被執行。但是，不能保證回調會在容器入口點（ENTRYPOINT）之前執行。沒有參數傳遞給處理程序。
• PreStop鉤子，在容器因 API 請求或者管理事件（諸如存活態探針、啟動探針失敗、資源搶占、資源競爭等） 而被終止之前，此回調會被調用。

那么 K8S 中的這幾種原生特性，是如何讓容器化和 CMDB 結合呢？

與 CMDB Agent 采集主機數據上報不同的是，Pod在啟動過程中：

• 由于Init容器最先啟動，此時可將容器字段，如IP、容器名等信息注冊至CMDB；

• 如果不使用init容器，也可以通過 PostStart 鉤子將容器信息注冊至CMDB；
• 上報后容器信息并不保證可正常使用，因為需要經過 Readiness、Liveness等檢測；
• 如果容器啟動不成功，通過PreStop鉤子可將容器信息從 CMDB 反注冊；

此種方案的優點是方案可行，但是在實際聯調過程中有以下幾個關鍵點：

• 使用 Init 注冊要優于 PostStart，因為為保證注冊信息上報的準確性，PostStart的等待時間一定要比 Readiness 時間長，否則未等到 Readiness 檢測通過就上報會產生部分垃圾數據；

• 上報后容器信息并不保證可正常使用，因為需要經過 Readiness、Liveness 等檢測；

• 如果容器啟動不成功，通過 PreStop 鉤子可將容器信息從 CMDB 反注冊；

此種方案的優點是方案可行，但是在實際聯調過程中有以下幾個關鍵點：

• 使用 Init 注冊要優于 PostStart，因為為保證注冊信息上報的準確性，PostStart 的等待時間一定要比 Readiness 時間長，否則未等到 Readiness 檢測通過就上報會產生部分垃圾數據；

• 無論是PostStart、PreStop只支持簡單的命令行，還需要由默認的分隔符“，”限制，這意味著太過復雜的參數如json格式就會被意味隔斷，從而導致請求錯誤；

總結，受限于PostStart、PreStop的特性及便捷性，他們在給你帶來可能性的同時也可能會束縛你前進的腳步！

K8S事件監控+MQ

Event 是集群中某個事件的報告，它一般表示系統的某些狀態變化。Event 的保留時間有限，觸發器和消息可能會隨著時間的推移而演變。

• 事件監聽服務，每隔一定頻率從 kube-apiserver 同步事件，并且K8S提供了類庫專門來監聽集群內的事件變化，然后再觸發自己寫的業務邏輯；

• 事件監聽服務需要對事件相關服務進行健康檢查，只有正常啟動的服務才會將消息發送至mq，因此這需要微服務要有一定的接入標準及規范；
• 事件監聽服務作為 MQ 生產者，根據集群事件可根據ns、IP、port等所需內容進行定制化收集，并將這些內容發送至mq上指定的topic；
• 至于消費方案可以有多種，一種方案是可以訂制單獨的消費者服務，消費mq上topic 信息與下游的 CMDB 及其他組件進行注冊/反注冊；另一種方案是CMDB及其他組件直接消費 topic 上的信息，完成注冊/反注冊；

這種方案的優勢在于靈活可控，但集成難度也相應增加：

• 有一定的開發成本，例如事件監控服務（go開發）、單獨的消費者服務（python、go、java均可）、CMDB及其他組件（根據其開發語言所定）；

• 隨著中間組件的引入，不穩定性增加，例如網絡抖動、單點mq或mq高可用切換可能會導致生產/消費有問題，如果這期間恰好發生容器事件，可能會導致生產事故；

• 消息冪等性，為了保證事件消息不遺漏，事件監控服務多副本情況下會發送重復消息，因此會導致重復消費，因此我們需要在下游考慮消息的冪等性；

總結