容器云經(jīng)常詢問(wèn)的常見問(wèn)題

有不少的朋友希望寫一些有關(guān)容器云平臺(tái)實(shí)際建設(shè)使用過(guò)程中的具體問(wèn)題，作為開發(fā)人員，這是基本思維，不過(guò)要作為架構(gòu)師，關(guān)注的就不應(yīng)該只是技術(shù)細(xì)節(jié)，更要在平臺(tái)建設(shè)全局上考慮。今天我們討論幾個(gè)有關(guān)容器云建設(shè)實(shí)踐的典型問(wèn)題，希望對(duì)大家有幫助。

一、 容器云的定位：

要建設(shè)容器云，首先要考慮清楚為什么要建設(shè)容器云，建設(shè)容器云用來(lái)做什么，或者說(shuō)它能做什么，容器云在云計(jì)算中又承擔(dān)什么樣的職責(zé)，跟各種主流技術(shù)又有什么樣的關(guān)系等等。把這些問(wèn)題考慮清楚了，也就知道該不該建設(shè)容器云，建設(shè)什么樣的容器云。我們技術(shù)人員最忌諱的就是人云亦云、邯鄲學(xué)步、東施效顰。無(wú)論我們是否有機(jī)會(huì)有平臺(tái)把自己的想法說(shuō)出來(lái)，堅(jiān)持自己的想法，不斷驗(yàn)證并完善自己的想法，深入土壤，總會(huì)長(zhǎng)成參天大樹的。容器云平臺(tái)說(shuō)到底只是工具，最終還是要服務(wù)于企業(yè)業(yè)務(wù)應(yīng)用的。再好的技術(shù)也只是工具，所以容器技術(shù)再牛，在容器云平臺(tái)中它也不是核心。那些把“容器”二字非要顯示在容器云平臺(tái)的人，明顯是不知道該干什么的。容器云平臺(tái)是來(lái)承載應(yīng)用的，所以應(yīng)用管理才是容器云平臺(tái)的核心，所有的能力都是圍繞應(yīng)用管理來(lái)建設(shè)的。不管容器云平臺(tái)的資源管理，容器云平臺(tái)的多租戶隔離機(jī)制，以及容器云平臺(tái)的安全、監(jiān)控、日志等組件，都要圍繞應(yīng)用管理來(lái)建設(shè)的，所有平臺(tái)核心不是“容器”，是“應(yīng)用”。所以容器云廠商要避免閉門造車，開發(fā)人員避免當(dāng)初生牛犢無(wú)知無(wú)畏了。而用戶需要考慮的是建設(shè)容器云是為了實(shí)現(xiàn)什么能力?，F(xiàn)在已經(jīng)過(guò)了容器技術(shù)概念驗(yàn)證的階段，容器云平臺(tái)需要產(chǎn)品化，不是幾項(xiàng)功能的堆砌就可以上生產(chǎn)用的。容器云平臺(tái)是工具，客戶要用它來(lái)管理應(yīng)用，為應(yīng)用提供資源，為應(yīng)用提供全生命周期運(yùn)營(yíng)管理的支撐工具。
容器云只是PaaS平臺(tái)的一種實(shí)現(xiàn)方式，我們更多的說(shuō)是一種輕量化實(shí)現(xiàn)。一些功能并不適合在容器云平臺(tái)上去實(shí)現(xiàn)。對(duì)于那些笨重的資源占用量大的無(wú)法利用容器技術(shù)特性的應(yīng)用，不建議在容器云上去做，無(wú)論是遷移還是新建。
至于說(shuō)容器云平臺(tái)產(chǎn)生的數(shù)據(jù)，那就交給數(shù)據(jù)平臺(tái)或大數(shù)據(jù)平臺(tái)進(jìn)行分析和處理。大數(shù)據(jù)應(yīng)用可以部署于容器云平臺(tái)；容器云平臺(tái)提供基礎(chǔ)設(shè)施資源，來(lái)支撐業(yè)務(wù)應(yīng)用，這些應(yīng)用包括大數(shù)據(jù)應(yīng)用。大數(shù)據(jù)應(yīng)用的數(shù)據(jù)來(lái)源于大數(shù)據(jù)平臺(tái)。容器云平臺(tái)和應(yīng)用等產(chǎn)生的數(shù)據(jù)又可以存儲(chǔ)于大數(shù)據(jù)平臺(tái)，用于分析、統(tǒng)計(jì)、數(shù)據(jù)挖掘等。

二、 持續(xù)集成和容器云平臺(tái)的關(guān)系：

CI/CD與容器云平臺(tái)的關(guān)系在我們以前的文章中也討論過(guò)多次，不過(guò)到目前為止，仍有許多的容器云廠商沒有轉(zhuǎn)過(guò)彎來(lái)。 首先來(lái)考慮一個(gè)問(wèn)題，你是否會(huì)把持續(xù)集成的代碼、編譯、打包的過(guò)程部署于生產(chǎn)環(huán)境？為什么？
如果真正懂IT治理過(guò)程的話，10個(gè)人有9個(gè)半是不會(huì)這么做的，這也是我們接觸容器云平臺(tái)這么久來(lái)讓我們覺得不可思議的地方。你說(shuō)容器技術(shù)調(diào)研、PoC驗(yàn)證可以這么做，生產(chǎn)還這么做？上生產(chǎn)還能拿小孩子過(guò)家家的玩藝兒去部署？是不是不可思議？目前大部分容器云產(chǎn)品至多算是個(gè)玩具，至多是PoC概念驗(yàn)證的工具，完全不具備生產(chǎn)部署的要求。這也是我們?yōu)槭裁匆辉購(gòu)?qiáng)調(diào)要把CI持續(xù)集成從容器云平臺(tái)資源和應(yīng)用管理分離出來(lái)，成為獨(dú)立的一個(gè)模塊或產(chǎn)品，實(shí)現(xiàn)標(biāo)準(zhǔn)化鏡像輸出能力的原因。
想想阿里為什么有個(gè)云效平臺(tái)，想想IBM為什么推出的是基于容器技術(shù)的微服務(wù)管理平臺(tái)，特別傳統(tǒng)行業(yè)，誰(shuí)會(huì)傻到在生產(chǎn)環(huán)境上去開發(fā)、編譯、測(cè)試？不過(guò)還真別說(shuō)，目前看到的容器云產(chǎn)品基本上都是傻傻的分不清。所以這也是我們重點(diǎn)提出來(lái)討論的原因。
持續(xù)集成流程終點(diǎn)應(yīng)該是鏡像倉(cāng)庫(kù)，持續(xù)集成只服務(wù)于開發(fā)測(cè)試階段，是不需要在生產(chǎn)環(huán)境中體現(xiàn)的。持續(xù)集成需要做的是實(shí)現(xiàn)自動(dòng)化的源碼檢查、編譯、單元測(cè)試、鏡像打包、鏡像上傳、鏡像安全掃描等能力。最重要的是不要讓用戶自己再寫docker file等，需要通過(guò)提示客戶輸入或選擇實(shí)現(xiàn)自動(dòng)化的docker file生成。減少終端客戶的學(xué)習(xí)成本。
既然這樣，那持續(xù)集成或pipeline工具就應(yīng)該單獨(dú)拿出來(lái)作為獨(dú)立的產(chǎn)品或組件，提供持續(xù)集成服務(wù)。就像jenkins那樣，配置一下jdk、maven、Git or SVN等工具，實(shí)現(xiàn)自動(dòng)化的docker file生成（選擇基礎(chǔ)鏡像，添加需要的文件等到基礎(chǔ)鏡像，設(shè)置端口影射等，自動(dòng)生成docker file），連接到鏡像倉(cāng)庫(kù)，上傳鏡像，完成這些步驟后在鏡像倉(cāng)庫(kù)就可以看到新的鏡像。這樣對(duì)用戶來(lái)說(shuō)很友好。至于說(shuō)是用jenkins或者自定義的pipeline，都沒什么關(guān)系。作為用戶我關(guān)注的是結(jié)果——鏡像，中間過(guò)程可以是透明的（除了需要選擇基礎(chǔ)鏡像，選擇上傳文件等UI交互操作）。

三、 鏡像倉(cāng)庫(kù)及鏡像管理

鏡像通常包含我們打包的應(yīng)用。但也有中間件鏡像，比如Kafka、MySQL等，這些中間件鏡像應(yīng)該由誰(shuí)來(lái)維護(hù)？租戶還是容器云平臺(tái)？我們說(shuō)容器云平臺(tái)是用來(lái)支撐業(yè)務(wù)應(yīng)用的，那么租戶關(guān)注的應(yīng)該是業(yè)務(wù)應(yīng)用鏡像。中間件鏡像就應(yīng)該由容器云平臺(tái)來(lái)提供。鏡像就可能分為平臺(tái)鏡像和租戶鏡像，那么鏡像倉(cāng)庫(kù)就需要區(qū)分平臺(tái)鏡像倉(cāng)庫(kù)和租戶鏡像倉(cāng)庫(kù)。平臺(tái)支持多租戶，租戶的鏡像倉(cāng)庫(kù)可能有很多個(gè)，甚至每個(gè)租戶都有多個(gè)鏡像倉(cāng)庫(kù)。平臺(tái)鏡像倉(cāng)庫(kù)中提供的鏡像是面向所有租戶的，每個(gè)租戶都可以使用平臺(tái)鏡像倉(cāng)庫(kù)中的所有鏡像，因此可以成為公共鏡像倉(cāng)庫(kù)， 每個(gè)租戶的鏡像倉(cāng)庫(kù)可以看作是私有鏡像倉(cāng)庫(kù)，所以對(duì)一個(gè)租戶來(lái)說(shuō)，有來(lái)自公共鏡像庫(kù)的公共鏡像和來(lái)自自有的私有鏡像可以用。
租戶是否可以有自己的中間件鏡像？當(dāng)然可以，公共鏡像庫(kù)沒有的鏡像，租戶需要自己來(lái)構(gòu)建。但對(duì)于企業(yè)私有云來(lái)說(shuō)，建議由容器云平臺(tái)來(lái)維護(hù)公用的鏡像，這也是規(guī)范化、標(biāo)準(zhǔn)化的要求。
還有個(gè)問(wèn)題是不同鏡像庫(kù)之間鏡像同步的問(wèn)題。比如從測(cè)試庫(kù)到生產(chǎn)庫(kù)。測(cè)試和生產(chǎn)通常網(wǎng)絡(luò)是隔離的，不通的，當(dāng)然可以通過(guò)雙網(wǎng)卡配置網(wǎng)絡(luò)使兩個(gè)網(wǎng)段相通，或者單向通信。也可以通過(guò)中轉(zhuǎn)機(jī)。但有個(gè)前提是，只有經(jīng)過(guò)鏡像安全檢查的鏡像才可以同步到生產(chǎn)鏡像庫(kù)。
還有就是鏡像版本控制，特別是開發(fā)測(cè)試環(huán)境，持續(xù)集成可能產(chǎn)生眾多版本的鏡像，我們團(tuán)隊(duì)幾天時(shí)間就發(fā)了好幾百個(gè)，時(shí)間長(zhǎng)了這個(gè)數(shù)會(huì)成為一個(gè)問(wèn)題，因此需要考慮限制可用鏡像版本，比如只保留最近的10版本，其他的版本都刪除。或者可以選擇保留的milestone里程碑的版本。

四、 多租戶

不得不再提這個(gè)問(wèn)題。雖然都聲稱支持多租戶，但是國(guó)內(nèi)私有云廠商還真沒有把多租戶做的比較好的。一個(gè)admin干了所有角色的工作。多簡(jiǎn)單??！是啊，好簡(jiǎn)單，也好幼稚！云平臺(tái)多租戶機(jī)制實(shí)現(xiàn)租戶之間的隔離，即便是私有容器云平臺(tái)，也是要實(shí)現(xiàn)多租戶隔離的。也可能面臨這部門之間資源使用的計(jì)量計(jì)費(fèi)，也可能面臨著業(yè)務(wù)監(jiān)管的硬性隔離要求。所以只要是云計(jì)算平臺(tái)，就要考慮多租戶機(jī)制，考慮租戶隔離需求。
多租戶除了資源隔離需求，也要求有完善的權(quán)限管理體系。容器云平臺(tái)管理員其實(shí)就是一個(gè)特殊的租戶，它關(guān)注的是資源管理；租戶關(guān)注的是業(yè)務(wù)應(yīng)用管理。整個(gè)平臺(tái)的權(quán)限體系是統(tǒng)一的。我們?cè)凇度萜髟茩?quán)限中心設(shè)計(jì)》一文中有過(guò)討論，基于角色的權(quán)限管理體系，支持任意組織架構(gòu)/用戶/角色的定義。

五、 平臺(tái)設(shè)置

這是我們?cè)谌萜髟破脚_(tái)首次提出的問(wèn)題，各廠商基本上也沒考慮到。容器云做產(chǎn)品化，在安裝初始化時(shí)可能需要做一些初始設(shè)置。平臺(tái)在日常運(yùn)行過(guò)程中，也可能需要調(diào)整某些平臺(tái)組件參數(shù)，更新設(shè)置，比如更新平臺(tái)頁(yè)面logo?；蛘卟藛雾?xiàng)中某項(xiàng)名稱有歧義，需要更改；或者需要設(shè)置不可見……容器云平臺(tái)需要提供一個(gè)接口來(lái)更改這些配置。這些可以統(tǒng)一放置于平臺(tái)設(shè)置中來(lái)實(shí)現(xiàn)。
雖然目前通過(guò)命令行可以做，但非常不友好，也容易出錯(cuò)。嚴(yán)重的失誤可能導(dǎo)致巨大的損失，因此該屏蔽的功能需要屏蔽掉，只提供可以操作的功能項(xiàng)，禁止直接終端訪問(wèn)容器集群節(jié)點(diǎn)等。不只是界面友好性的要求，更是安全的要求。

六、 微服務(wù)和API管理

我們說(shuō)了，容器云平臺(tái)是用來(lái)承載業(yè)務(wù)應(yīng)用的。容器的特性非常適合微服務(wù)化的應(yīng)用。但是有個(gè)問(wèn)題是，微服務(wù)組件可能有很多個(gè)服務(wù)實(shí)例，對(duì)外需要提供統(tǒng)一的接口API。那可能就需要考慮負(fù)載均衡，是客戶端負(fù)載均衡還是服務(wù)端負(fù)載均衡？容器的彈性伸縮、可遷移性使之在客戶端實(shí)現(xiàn)不是一個(gè)好辦法。另外，每個(gè)實(shí)例都需要在注冊(cè)中心注冊(cè)嗎？再說(shuō)，容器內(nèi)的服務(wù)注冊(cè)到注冊(cè)中心使用的是容器地址，是內(nèi)部地址，容器云平臺(tái)外部的服務(wù)是無(wú)法訪問(wèn)的。況且彈性伸縮的時(shí)候，容器遷移的時(shí)候會(huì)帶來(lái)延遲，這可能會(huì)導(dǎo)致超時(shí)等問(wèn)題。
目前不管采用SpringCloud或其他，都不足以滿足微服務(wù)在容器云平臺(tái)直接部署和方便管理的要求。要支撐微服務(wù)，一個(gè)重要的組件是API網(wǎng)關(guān)。其通常需要提供API網(wǎng)關(guān)能力、API管理能力，Open API Portal并不是必須的。
所有非業(yè)務(wù)功能都可以考慮在網(wǎng)關(guān)層實(shí)現(xiàn)，比如授權(quán)認(rèn)證、訪問(wèn)控制、負(fù)載均衡、服務(wù)編排、路由轉(zhuǎn)換、限流限額、過(guò)濾熔斷等。但要設(shè)置這些能力，是需要提供API管理能力的。
API網(wǎng)關(guān)提供了統(tǒng)一的接口服務(wù)和負(fù)載均衡等能力，那么在容器云平臺(tái)就不需要每個(gè)實(shí)例都再注冊(cè)到注冊(cè)中心，所有的服務(wù)對(duì)外有唯一的接口API，在容器云平臺(tái)內(nèi)部可以充分利用容器技術(shù)的特性。
如果要采用微服務(wù)架構(gòu)，一定需要關(guān)注API網(wǎng)關(guān)這個(gè)組件。商用的產(chǎn)品雖然貴，但功能強(qiáng)大，適合傳統(tǒng)的企業(yè)采用。

七、 應(yīng)用管理

應(yīng)該管理是容器云平臺(tái)的核心，不管是中間件應(yīng)用，實(shí)際的業(yè)務(wù)應(yīng)用，或者提供軟件服務(wù)的應(yīng)用等（應(yīng)用提供“服務(wù)”， 基礎(chǔ)設(shè)施服務(wù)、平臺(tái)服務(wù)、軟件服務(wù)中的“服務(wù)”和業(yè)務(wù)應(yīng)用下的“服務(wù)”或“服務(wù)實(shí)例”雖然都稱為“服務(wù)”，內(nèi)涵有點(diǎn)不同），平臺(tái)提供應(yīng)用托管、應(yīng)用運(yùn)維、甚至應(yīng)用開發(fā)的能力。目前更多的話是關(guān)注應(yīng)用運(yùn)維，很多時(shí)候我們可以稱之為“微服務(wù)平臺(tái)”。當(dāng)然在容器云平臺(tái)提供的中間件服務(wù)等，也涉及應(yīng)用開發(fā)的能力，提供類似Github、SVN的能力，加上運(yùn)維管理，就是應(yīng)用托管的能力。
我們建設(shè)容器云平臺(tái)不是為了管理容器，而是為了業(yè)務(wù)應(yīng)用，來(lái)支撐公司業(yè)務(wù)。因此在容器云平臺(tái)我們是不需要看到“容器”的，我們看到的是應(yīng)用、服務(wù)、服務(wù)實(shí)例，沒有“容器”什么事（至少表面上）。所以容器云平臺(tái)需要圍繞應(yīng)用全生命周期的管理來(lái)設(shè)計(jì)實(shí)現(xiàn)并支持這些需求。也這是下面服務(wù)治理的要求。

八、 服務(wù)治理

很多公司都在做微服務(wù)治理平臺(tái)，不管用gRPC或是Istio等，個(gè)人覺得完全沒有必要單獨(dú)實(shí)現(xiàn)一個(gè)微服務(wù)治理平臺(tái)，完全可以基于容器云平臺(tái)+商用API 管理工具（通常包含API 網(wǎng)關(guān)、API管理、API Portal甚至API 開發(fā)工具等）足矣。這也是我們強(qiáng)調(diào)容器云平臺(tái)要以應(yīng)用管理為核心的一個(gè)原因。治理，可以作為管理的一個(gè)方面。采用容器云平臺(tái)就要考慮充分利用容器技術(shù)的特性，采用微服務(wù)架構(gòu)也要考慮微服務(wù)的特性，把兩者結(jié)合起來(lái)充分利用其優(yōu)點(diǎn)避免其缺點(diǎn)，而不是分開考慮，是我們把微服務(wù)部署于容器云平臺(tái)時(shí)需要面對(duì)的課題。
API網(wǎng)關(guān)你可以看作是一個(gè)服務(wù)網(wǎng)關(guān)，在服務(wù)網(wǎng)關(guān)可以實(shí)現(xiàn)大部分非業(yè)務(wù)邏輯的治理能力，比如路由、限流、轉(zhuǎn)換、過(guò)濾、負(fù)載均衡、訪問(wèn)控制、授權(quán)認(rèn)證，甚至服務(wù)編排、統(tǒng)計(jì)計(jì)費(fèi)、注冊(cè)發(fā)現(xiàn)、日志監(jiān)控等，結(jié)合容器云平臺(tái)提供的權(quán)限、資源管理、應(yīng)用管理、租戶機(jī)制等可以實(shí)現(xiàn)服務(wù)治理的能力。這樣就簡(jiǎn)化了服務(wù)管理、服務(wù)治理的功能，成本也相對(duì)較小。我們一直的觀點(diǎn)就是盡可能選擇成熟的產(chǎn)品和方案，沒必要自己都趟一遍坑。

九、 容器內(nèi)外部服務(wù)訪問(wèn)

這應(yīng)該算是服務(wù)治理的內(nèi)容，不過(guò)我們覺得應(yīng)該是個(gè)典型問(wèn)題，因此提出來(lái)一起討論。服務(wù)部署于容器，注冊(cè)時(shí)用的是容器的地址。容器外的服務(wù)如果訪問(wèn)注冊(cè)中心，獲取到的服務(wù)地址也是這個(gè)容器地址，是無(wú)法解析的，況且容器地址可能會(huì)遷移，這就比較麻煩了。廠商提出要把外部的服務(wù)主機(jī)加入到容器網(wǎng)絡(luò)，雖然可以解決問(wèn)題，但不是一個(gè)好方法。前面我們提到API Gateway，它可以做這個(gè)事情。
如果用容器云，在服務(wù)部署時(shí)，不要自動(dòng)注冊(cè)，容器內(nèi)的訪問(wèn)使用容器的service機(jī)制，容器外的訪問(wèn)通過(guò)API網(wǎng)關(guān)，在API網(wǎng)關(guān)層實(shí)現(xiàn)服務(wù)注冊(cè)、路由、負(fù)載均衡等。其實(shí)在容器內(nèi)也有一層可以實(shí)現(xiàn)負(fù)載均衡，服務(wù)實(shí)例級(jí)別的。具體怎么實(shí)現(xiàn)，根據(jù)具體的業(yè)務(wù)需求來(lái)確定。彈性伸縮需求的，最好在容器層實(shí)現(xiàn)，就不需要在容器外考慮負(fù)載均衡等機(jī)制。
這樣其實(shí)是分兩個(gè)層次來(lái)考慮。API網(wǎng)關(guān)可以容器化也可以非容器化，我們基于部署、擴(kuò)展等要求建議是非容器化。為什么這么考慮？一是租戶隔離需求，租戶之間的訪問(wèn)要經(jīng)過(guò)API網(wǎng)關(guān)，即便是一個(gè)公司內(nèi)部，也要考慮建立明確的應(yīng)用隔離機(jī)制。二是封裝技術(shù)細(xì)節(jié)，簡(jiǎn)化開發(fā)要求。開發(fā)人員在實(shí)現(xiàn)服務(wù)或微服務(wù)時(shí)，不需要考慮服務(wù)注冊(cè)、負(fù)載均衡、熔斷等機(jī)制的實(shí)現(xiàn)，只關(guān)注于業(yè)務(wù)邏輯的實(shí)現(xiàn)，關(guān)注于容器多實(shí)例分布式訪問(wèn)需求。這樣就簡(jiǎn)化了，那些非業(yè)務(wù)邏輯的功能都交給API網(wǎng)關(guān)去做。
當(dāng)然容器內(nèi)部的訪問(wèn)使用容器平臺(tái)提供的Service方式?？梢詫?shí)現(xiàn)內(nèi)部的服務(wù)域名訪問(wèn)。

十、 結(jié)語(yǔ)

我們?cè)趯?shí)施過(guò)程中遇到了很多問(wèn)題，大家關(guān)注的比較多的可能就是這些細(xì)節(jié)的實(shí)現(xiàn)方案，我們也會(huì)逐步整理供大家參考，以期共同學(xué)習(xí)，大家在后期的實(shí)踐中能少走彎路。