云原生場(chǎng)景下，容器化和微服務(wù)還有必要組“CP”嗎？
背景
注冊中心式CP，東西向流量； 云原生網(wǎng)關(guān)式CP，南北向流量； ServiceMesh式CP，東西向、南北向流量； CMDB式CP，運維、架構依賴(lài)式流量；
這種方式是如何微服務(wù)的訪(fǎng)問(wèn)呢？
網(wǎng)關(guān)+CMDB完成應用訪(fǎng)問(wèn)路由和應用系統的關(guān)聯(lián)； 微服務(wù)+CMDB完成應用系統和服務(wù)器資源的關(guān)聯(lián)；
福兮禍所依
overlay網(wǎng)絡(luò )，那東西向流量就必須使用注冊中心或ServiceMesh解決方案，與CMDB再集成意義不大；
underlay網(wǎng)絡(luò )，那容器IP可以直接關(guān)聯(lián)業(yè)務(wù)網(wǎng)段，通過(guò)CMDB按業(yè)務(wù)、應用系統與容器IP進(jìn)行關(guān)聯(lián)；
當然，天無(wú)絕人之路！
禍兮福所伏
Init容器+PostStart
Init容器， 在 Pod 內的應用容器啟動(dòng)之前運行， 它們總是運行到完成。如果 Pod 的 Init 容器失敗，kubelet 會(huì )不斷地重啟該 Init 容器直到該容器成功為止。 PostStart鉤子，回調在容器被創(chuàng )建之后立即被執行。但是，不能保證回調會(huì )在容器入口點(diǎn)（ENTRYPOINT）之前執行。沒(méi)有參數傳遞給處理程序。 PreStop鉤子，在容器因 API 請求或者管理事件（諸如存活態(tài)探針、啟動(dòng)探針失敗、資源搶占、資源競爭等） 而被終止之前，此回調會(huì )被調用。
那么 K8S 中的這幾種原生特性，是如何讓容器化和 CMDB 結合呢？
與 CMDB Agent 采集主機數據上報不同的是，Pod在啟動(dòng)過(guò)程中：
由于Init容器最先啟動(dòng)，此時(shí)可將容器字段，如IP、容器名等信息注冊至CMDB；
如果不使用init容器，也可以通過(guò) PostStart 鉤子將容器信息注冊至CMDB； 上報后容器信息并不保證可正常使用，因為需要經(jīng)過(guò) Readiness、Liveness等檢測； 如果容器啟動(dòng)不成功，通過(guò)PreStop鉤子可將容器信息從 CMDB 反注冊；
此種方案的優(yōu)點(diǎn)是方案可行，但是在實(shí)際聯(lián)調過(guò)程中有以下幾個(gè)關(guān)鍵點(diǎn)：
使用 Init 注冊要優(yōu)于 PostStart，因為為保證注冊信息上報的準確性，PostStart的等待時(shí)間一定要比 Readiness 時(shí)間長(cháng)，否則未等到 Readiness 檢測通過(guò)就上報會(huì )產(chǎn)生部分垃圾數據；
上報后容器信息并不保證可正常使用，因為需要經(jīng)過(guò) Readiness、Liveness 等檢測；
如果容器啟動(dòng)不成功，通過(guò) PreStop 鉤子可將容器信息從 CMDB 反注冊；
此種方案的優(yōu)點(diǎn)是方案可行，但是在實(shí)際聯(lián)調過(guò)程中有以下幾個(gè)關(guān)鍵點(diǎn)：
使用 Init 注冊要優(yōu)于 PostStart，因為為保證注冊信息上報的準確性，PostStart 的等待時(shí)間一定要比 Readiness 時(shí)間長(cháng)，否則未等到 Readiness 檢測通過(guò)就上報會(huì )產(chǎn)生部分垃圾數據； 無(wú)論是PostStart、PreStop只支持簡(jiǎn)單的命令行，還需要由默認的分隔符“，”限制，這意味著(zhù)太過(guò)復雜的參數如json格式就會(huì )被意味隔斷，從而導致請求錯誤；
總結，受限于PostStart、PreStop的特性及便捷性，他們在給你帶來(lái)可能性的同時(shí)也可能會(huì )束縛你前進(jìn)的腳步！
K8S事件監控+MQ
Event 是集群中某個(gè)事件的報告，它一般表示系統的某些狀態(tài)變化。Event 的保留時(shí)間有限，觸發(fā)器和消息可能會(huì )隨著(zhù)時(shí)間的推移而演變。
事件監聽(tīng)服務(wù)，每隔一定頻率從 kube-apiserver 同步事件，并且K8S提供了類(lèi)庫專(zhuān)門(mén)來(lái)監聽(tīng)集群內的事件變化，然后再觸發(fā)自己寫(xiě)的業(yè)務(wù)邏輯；
事件監聽(tīng)服務(wù)需要對事件相關(guān)服務(wù)進(jìn)行健康檢查，只有正常啟動(dòng)的服務(wù)才會(huì )將消息發(fā)送至mq，因此這需要微服務(wù)要有一定的接入標準及規范； 事件監聽(tīng)服務(wù)作為 MQ 生產(chǎn)者，根據集群事件可根據ns、IP、port等所需內容進(jìn)行定制化收集，并將這些內容發(fā)送至mq上指定的topic； 至于消費方案可以有多種，一種方案是可以訂制單獨的消費者服務(wù)，消費mq上topic 信息與下游的 CMDB 及其他組件進(jìn)行注冊/反注冊；另一種方案是CMDB及其他組件直接消費 topic 上的信息，完成注冊/反注冊；
這種方案的優(yōu)勢在于靈活可控，但集成難度也相應增加：
有一定的開(kāi)發(fā)成本，例如事件監控服務(wù)（go開(kāi)發(fā)）、單獨的消費者服務(wù)（python、go、java均可）、CMDB及其他組件（根據其開(kāi)發(fā)語(yǔ)言所定）； 隨著(zhù)中間組件的引入，不穩定性增加，例如網(wǎng)絡(luò )抖動(dòng)、單點(diǎn)mq或mq高可用切換可能會(huì )導致生產(chǎn)/消費有問(wèn)題，如果這期間恰好發(fā)生容器事件，可能會(huì )導致生產(chǎn)事故；
消息冪等性，為了保證事件消息不遺漏，事件監控服務(wù)多副本情況下會(huì )發(fā)送重復消息，因此會(huì )導致重復消費，因此我們需要在下游考慮消息的冪等性；
