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

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

一、 容器云的定位：

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

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

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

三、 鏡像倉庫及鏡像管理

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

四、 多租戶

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

五、 平臺設(shè)置

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

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

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

七、 應(yīng)用管理

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

八、 服務(wù)治理

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

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

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

十、 結(jié)語

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