背景

• 注冊(cè)中心式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ò)，那東西向流量就必須使用注冊(cè)中心或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)用容器啟動(dòng)之前運(yùn)行， 它們總是運(yùn)行到完成。如果 Pod 的 Init 容器失敗，kubelet 會(huì)不斷地重啟該 Init 容器直到該容器成功為止。
• PostStart鉤子，回調(diào)在容器被創(chuàng)建之后立即被執(zhí)行。但是，不能保證回調(diào)會(huì)在容器入口點(diǎn)（ENTRYPOINT）之前執(zhí)行。沒有參數(shù)傳遞給處理程序。
• PreStop鉤子，在容器因 API 請(qǐng)求或者管理事件（諸如存活態(tài)探針、啟動(dòng)探針失敗、資源搶占、資源競(jìng)爭(zhēng)等） 而被終止之前，此回調(diào)會(huì)被調(diào)用。

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

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

• 由于Init容器最先啟動(dòng)，此時(shí)可將容器字段，如IP、容器名等信息注冊(cè)至CMDB；

• 如果不使用init容器，也可以通過 PostStart 鉤子將容器信息注冊(cè)至CMDB；
• 上報(bào)后容器信息并不保證可正常使用，因?yàn)樾枰?jīng)過 Readiness、Liveness等檢測(cè)；
• 如果容器啟動(dòng)不成功，通過PreStop鉤子可將容器信息從 CMDB 反注冊(cè)；

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

• 使用 Init 注冊(cè)要優(yōu)于 PostStart，因?yàn)闉楸ＷC注冊(cè)信息上報(bào)的準(zhǔn)確性，PostStart的等待時(shí)間一定要比 Readiness 時(shí)間長(zhǎng)，否則未等到 Readiness 檢測(cè)通過就上報(bào)會(huì)產(chǎn)生部分垃圾數(shù)據(jù)；

• 上報(bào)后容器信息并不保證可正常使用，因?yàn)樾枰?jīng)過 Readiness、Liveness 等檢測(cè)；

• 如果容器啟動(dòng)不成功，通過 PreStop 鉤子可將容器信息從 CMDB 反注冊(cè)；

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

• 使用 Init 注冊(cè)要優(yōu)于 PostStart，因?yàn)闉楸ＷC注冊(cè)信息上報(bào)的準(zhǔn)確性，PostStart 的等待時(shí)間一定要比 Readiness 時(shí)間長(zhǎng)，否則未等到 Readiness 檢測(cè)通過就上報(bào)會(huì)產(chǎn)生部分垃圾數(shù)據(jù)；

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

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

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

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

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

• 事件監(jiān)聽服務(wù)需要對(duì)事件相關(guān)服務(wù)進(jìn)行健康檢查，只有正常啟動(dòng)的服務(wù)才會(huì)將消息發(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)方案可以有多種，一種方案是可以訂制單獨(dú)的消費(fèi)者服務(wù)，消費(fèi)mq上topic 信息與下游的 CMDB 及其他組件進(jìn)行注冊(cè)/反注冊(cè)；另一種方案是CMDB及其他組件直接消費(fèi) topic 上的信息，完成注冊(cè)/反注冊(cè)；

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

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

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

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

總結(jié)