• 注冊中心式CP，東西向流量；
• 云原生網(wǎng)關(guān)式CP，南北向流量；
• ServiceMesh式CP，東西向、南北向流量；
• CMDB式CP，運(yùn)維、架構(gòu)依賴式流量；

這種方式是如何微服務(wù)的訪問呢？

• 網(wǎng)關(guān)+CMDB完成應(yīng)用訪問路由和應(yīng)用系統(tǒng)的關(guān)聯(lián)；

• 微服務(wù)+CMDB完成應(yīng)用系統(tǒng)和服務(wù)器資源的關(guān)聯(lián)；

福兮禍所依

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

• underlay網(wǎng)絡(luò)，那容器IP可以直接關(guān)聯(lián)業(yè)務(wù)網(wǎng)段，通過CMDB按業(yè)務(wù)、應(yīng)用系統(tǒng)與容器IP進(jìn)行關(guān)聯(lián)；

當(dāng)然，天無絕人之路！

禍兮福所伏

Init容器+PostStart

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

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

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

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

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

此種方案的優(yōu)點是方案可行，但是在實際聯(lián)調(diào)過程中有以下幾個關(guān)鍵點：

• 使用 Init 注冊要優(yōu)于 PostStart，因為為保證注冊信息上報的準(zhǔn)確性，PostStart的等待時間一定要比 Readiness 時間長，否則未等到 Readiness 檢測通過就上報會產(chǎn)生部分垃圾數(shù)據(jù)；

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

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

此種方案的優(yōu)點是方案可行，但是在實際聯(lián)調(diào)過程中有以下幾個關(guān)鍵點：

• 使用 Init 注冊要優(yōu)于 PostStart，因為為保證注冊信息上報的準(zhǔn)確性，PostStart 的等待時間一定要比 Readiness 時間長，否則未等到 Readiness 檢測通過就上報會產(chǎn)生部分垃圾數(shù)據(jù)；

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

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

K8S事件監(jiān)控+MQ

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

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

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

這種方案的優(yōu)勢在于靈活可控，但集成難度也相應(yīng)增加：

• 有一定的開發(fā)成本，例如事件監(jiān)控服務(wù)（go開發(fā)）、單獨的消費(fèi)者服務(wù)（python、go、java均可）、CMDB及其他組件（根據(jù)其開發(fā)語言所定）；

• 隨著中間組件的引入，不穩(wěn)定性增加，例如網(wǎng)絡(luò)抖動、單點mq或mq高可用切換可能會導(dǎo)致生產(chǎn)/消費(fèi)有問題，如果這期間恰好發(fā)生容器事件，可能會導(dǎo)致生產(chǎn)事故；

• 消息冪等性，為了保證事件消息不遺漏，事件監(jiān)控服務(wù)多副本情況下會發(fā)送重復(fù)消息，因此會導(dǎo)致重復(fù)消費(fèi)，因此我們需要在下游考慮消息的冪等性；

總結(jié)