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

一、 容器云的定位：

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

二、 持續集成和容器云平臺的關系：

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

三、 鏡像倉庫及鏡像管理

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

四、 多租戶

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

五、 平臺設置

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

六、 微服務和API管理

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

七、 應用管理

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

八、 服務治理

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

九、 容器內外部服務訪問

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

十、 結語

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