作者：汪照輝 王作敬
容器技術應用雖然越來越廣越來越深入，但大多數(shù)仍然只是基于開源做一些測試和驗證工作。基于對容器平臺的應用和研究，以及對開源技術的理解，詳細探討了容器云平臺的設計和實現(xiàn)架構，提出“三視角、四層次、一閉環(huán)”設計方案，重點在于支撐業(yè)務應用的開發(fā)、托管和運營。
容器云、DevOps、微服務、三視角、四層次、一閉環(huán)
接《容器云平臺設計方案（上）》文章我們詳細探討下容器云平臺的設計方案。
從容器云平臺功能來看，可以劃分為平臺員管理視角（重點是資源管理）、租戶視角（重點是應用管理）和標準化交付視角（標準化鏡像交付）。不管私有容器云或公有容器云，都可以這么去考慮。使各部分職責清晰，功能明確，這也是DevOps協(xié)作與整合的要求。不能因為是私有容器云平臺就不分本地和云端，否則從技術上講那就沒有云計算的意義了，從業(yè)務上講也難以滿足復雜的業(yè)務場景管理需求。
從云計算租戶的視角來看，是利用云計算的資源來托管運維自己的業(yè)務應用，所以租戶不應該去關注資源的運維，租戶關心的是容器云平臺提供的服務能力和保證自己業(yè)務應用的正常運營所需要的能力。如果兩者匹配，將有助于租戶去運營自己的業(yè)務應用。租戶的需求就是我們建設容器云平臺的建設需求。
租戶可能來自不同的團隊、不同的部門、不同的項目組、甚至不同的公司。那從租戶視角看，首先可能需要支持不同的組織架構管理，組織架構下面有人員，每個人員或者每個組織有相應的角色，角色對應著權限。這就是支持多租戶首先要解決的權限管理問題。我們和廠商重構了多租戶權限體系，推出權限中心 組件服務，來支持不同的用戶、組、團隊、部門、公司等對于權限管理的需求。
圖 3 應用管理
有了權限體系的支撐，我們重點構建對業(yè)務應用的功能支撐。這里有幾個概念：應用、服務、服務實例。服務我們可以簡單理解為微服務，也就是提供某項能力的一個組件服務，服務通過編排為業(yè)務應用，而每個服務為了支持高負載又可能部署多個服務實例，所以就形成了應用——服務——服務實例三層關系。
服務也可以獨立部署為一個應用。微服務的基本原理就是讓一個小型應用專注地做好一件事情。比如說我們的權限中心，是一個獨立的微服務組件，但也可以部署為權限中心應用，提供權限管理服務。
應用管理主要是對服務的管理，服務的注冊發(fā)現(xiàn)、配置、流控、路由、負載均衡、轉換、熔斷、日志、監(jiān)控、告警等都需要相應的組件支持，這是容器云平臺能力建設的重點。容器云平臺建設的目的就是旨在支撐業(yè)務應用。
需要注意的是，我們建設容器云平臺，為了應用開發(fā)、應用托管和應用運維的能力，所以更確切的說是利用容器技術建設應用平臺，因此“容器”并不是主角，所以我們也一再強調(diào)并不需要在容器云平臺非要列出“容器”二字，我們僅僅使用容器技術而已。建設容器云平臺是為了承載業(yè)務應用，因此應用管理能力是核心。
談應用管理不得不先談多租戶，因為我們不可能一個“admin”就部署管理所有的業(yè)務應用服務。那是很恐怖的事情，特別采用了微服務，有沒有考慮過一個人能管理多少微服務？不要人為復雜化了。我們說了，復雜不是我們設計的初衷。所以我們需要考慮使用多租戶機制來隔離租戶之間的應用和資源，簡化運營管理。
應用管理分為兩個階段，在容器云平臺只實現(xiàn)運維管理，以鏡像倉庫為起點，完成應用生命周期管理。持續(xù)集成階段在標準化交付流程實現(xiàn)，終點是鏡像倉庫。因此鏡像倉庫是我們開發(fā)（Dev）和運維（Ops）的媒介。
理論上平臺管理是云端的功能，由云計算提供商來維護，但容器云本地化部署，不得不自己運維。雖然自己運維，也需要考慮本地云端和租戶的明確職責劃分。我們幾乎調(diào)研了所有的初創(chuàng)容器云廠商，這點做的都不好。就象剛才我們提到的，一個“admin”干了所有的事情。因此我們也重構了平臺管理服務能力。
圖 4 平臺管理
平臺管理重點在于基礎設施資源管理。當然平臺管理首先也會涉及權限管理，可以直接使用權限中心服務。這就是基于微服務架構構建容器云平臺（注：《以微服務的思想實施容器云》）的好處?；A設施資源包括計算資源、存儲資源、網(wǎng)絡資源以及操作系統(tǒng)。操作系統(tǒng)也是資源，不管物理機或者虛擬機，容器都需要運行在其之上，需要操作系統(tǒng)來支撐。平臺管理員負責這些資源的管理和運營運維，分配資源給租戶并監(jiān)控租戶資源的使用情況。平臺管理員根據(jù)租戶需求分配相應的資源。如果基礎設施層做了虛擬化，可能無法直接從虛擬機層面區(qū)分其宿主機配置差異，這可能需要我們做一些工作。比如我們在部署應用時，可能需要考慮其高可用部署，理論上就不應該部署兩個實例到一臺宿主機上，最好分布這些實例到不同的宿主機上，在部署的時候策略選擇需要能區(qū)分這些不同宿主機上的虛擬機，采用反親和性部署。
為了更好的支撐用戶的業(yè)務應用，需要提供一些通用或常用的中間件工具，比如kafka、MySQL、Tomcat等，因此我們規(guī)劃了公共鏡像倉庫，由平臺管理員來提供全平臺所有租戶可用的中間件工具，可以一鍵部署，快速完成環(huán)境配置，特別適合測試環(huán)境的快速構建。
租戶賬戶由平臺管理員來創(chuàng)建并由平臺管理員來維護。平臺管理員為每個租戶創(chuàng)建租戶賬戶并分配資源。每個租戶下的用戶和角色，由租戶自己管理維護。平臺管理只為每個租戶創(chuàng)建一個且僅有一個租戶賬戶。租戶賬戶全局唯一。
平臺管理除了對資源的基本的日志、監(jiān)控、告警能力之外，還有一點可能需要考慮平臺設置 能力。對于平臺全局性的一些配置提供用戶接口，用戶根據(jù)實際運行情況進行調(diào)整。
采用容器技術，很大程度上是為了標準化。容器引擎實現(xiàn)了基礎設施的標準化，容器鏡像實現(xiàn)了應用交付的標準化，而容器可以實現(xiàn)運維調(diào)度管理的標準化，鏡像倉庫則實現(xiàn)了分發(fā)部署的標準化。標準化交付的結果是Docker鏡像，我們希望一次構建，可以在任何地方運行（build once， run anywhere）。標準化交付流程也就是持續(xù)集成流程的終點是鏡像倉庫，鏡像倉庫作為持續(xù)集成和持續(xù)部署的媒介，完成測試的鏡像可以通過生產(chǎn)鏡像倉庫發(fā)布到生產(chǎn)環(huán)境。然后就是租戶視角的應用管理，持續(xù)的監(jiān)控應用服務的運行情況，并保持持續(xù)的反饋運行情況，以便及時的改進，形成一個良性循環(huán)。
我們之所以定義鏡像倉庫作為持續(xù)集成和持續(xù)發(fā)布的媒介，也是因為持續(xù)集成是開發(fā)階段，在這個階段我們往往關注的是“項目”，其所涉及的人員角色和運營階段不同，運營階段關注的是“應用”、“服務”，一個項目可能包含很多服務，甚至多個應用。為了更清晰的劃分職責，也簡化容器云平臺研發(fā)的難度，我們把標準化交付流程分離，成為一個獨立的組件或產(chǎn)品，類似于阿里的云效。復雜性永遠不是我們設計的初衷。用最簡單方式解決最復雜的問題才是我們所追求的。
標準化也帶給我們了敏捷研發(fā)能力。開發(fā)人員只關注業(yè)務邏輯的研發(fā)，不在考慮運行環(huán)境和非業(yè)務邏輯處理，比如路由和轉換，所有非業(yè)務邏輯的服務治理可以在API網(wǎng)關層實現(xiàn)。同時利用容器的特性，實現(xiàn)彈性伸縮等能力。運營人員對服務的運行情況保持持續(xù)的監(jiān)控，持續(xù)反饋服務運行狀況，比如服務運行異常，改進建議等，由開發(fā)人員持續(xù)改進服務，從而形成一個閉環(huán)流程。這就是我們期望的DevOps。
圖 5 標準化交付
圖 6 容器云平臺四層架構
在容器云平臺架構設計時，為了更好的保證松耦合等特性，縱向從三個視角來看，橫向根據(jù)相對獨立的基礎設施資源、資源調(diào)度管理框架、為了支撐業(yè)務應用需要建立的各項功能、以及業(yè)務應用概念，劃分為四層：基礎設施資源層、資源調(diào)度層、平臺層（業(yè)務應用支撐層）、業(yè)務應用層。
基礎設施資源層指的是基礎設施資源，也就是計算資源（CPU、內(nèi)存）、存儲資源、網(wǎng)絡資源以及操作系統(tǒng)資源。在這一層通常我們面對的是選擇物理機或者虛擬機的問題，是否選擇分布式存儲的問題，以及選擇什么容器網(wǎng)絡模式的問題等。這些問題討論的也很多，仁者見仁、智者見智，我們認為最終還是要基于自身的實際需求確定。另外需要考慮盡可能用簡單的方式來解決這些看起來復雜的問題。剛開始接觸容器或容器云，不理解不知道該怎么選擇很正常，但首先一點需要明確，就是需求定位問題：拿容器或容器云來做什么？然后基于需求可以確定這些基礎設施資源方案。
這里可能會忽略的一個問題是操作系統(tǒng)資源問題。不同操作系統(tǒng)會有差別，但對Linux來說，文件描述符等操作系統(tǒng)資源是需要根據(jù)實際需求做一些調(diào)整的。
基礎設施資源，你用或不用，它就在那里。資源調(diào)度層最重要的是對資源的抽象能力。有效并且安全的利用資源是我們在這層追求的目標。這其實應該算是IaaS層的能力，但目前容器似乎和IaaS的結合還不是很理想，所以直接管理IaaS的資源有些難度。通常情況下如果基于Vmvare虛擬化會相對簡單些。因此不管怎么爭論容器是基于物理機或者虛擬機，具體實際的情況最有發(fā)言權。脫離實際注定是不合適的。
Kubernetes提供了對集群、節(jié)點、CPU、內(nèi)存、存儲、網(wǎng)絡等的抽象支持，實現(xiàn)了對容器運行所需資源的調(diào)度管理。但某些節(jié)點可能需要預留一部分資源，也有一些應用需要限制它使用的資源量，這可能會涉及資源限額的配置。另外我們提到在為容器調(diào)度資源時，可能會面臨著親和性和非親和性的一些調(diào)度策略需求。物理機還好，對于經(jīng)過虛擬化抽象之后的虛擬機來說，會失去一些東西，因此容器調(diào)度可能會存在一些潛在的問題，這也是我們最初傾向于使用物理機的原因之一。不過由于我們的服務器都是很高的配置，為了有效且安全的利用資源，我們選擇虛擬化了一層實現(xiàn)更細的資源隔離。這和微服務的設計思想相同：化大為小，而容器通過編排調(diào)度實現(xiàn)了以小拼大。
要調(diào)度資源就需要知道調(diào)度哪些資源是合適的，需要對資源進行標注、打標簽。比如一臺物理服務器虛擬出了10臺虛擬機，在部署應用的時候兩個實例可能需要考慮反親和性策略，選擇10臺中的一臺部署應用實例，然后再選擇其他物理服務器虛擬出來的虛擬機中的一個，保證一個應用的兩個實例不會落在同一物理服務器之上。這要求我們在分配虛擬機時就要能標識其物理服務器屬性。
平臺層是容器云平臺建設的核心能力，是支撐業(yè)務應用的功能實現(xiàn)層。首先需要考慮和資源調(diào)度層實現(xiàn)松耦合架構。不管是Kubernetes或是Openshift，都面臨這快速迭代的問題，一年好幾個版本的迭代，如何能輕松的跟上這些產(chǎn)品版本迭代，是選擇容器云平臺不得不考慮的問題。因此與資源調(diào)度層必須采用松耦合架構，盡可能減少版本的迭代更新對平臺的影響。
多租戶機制實現(xiàn)租戶之間的隔離，也是為了化大為小，化繁為簡的需要。提供給每個租戶有相同的能力不同的資源，租戶按需使用資源運營應用。權限、認證、注冊發(fā)現(xiàn)、服務配置、日志、監(jiān)控、告警、API網(wǎng)關、部署管理、負載均衡、彈性伸縮、灰度發(fā)布、健康檢查、DNS服務、審計計費、統(tǒng)計分析等服務支撐能力都需要在這一層實現(xiàn)?？梢圆捎梦⒎战M件服務的形式實現(xiàn)，組件部署也可以根據(jù)實際采用非容器化部署，比如API網(wǎng)關，以非容器化集群方式部署，提供對7層服務調(diào)用的治理能力。
對于這些組件 的詳細設計和能力，我們也基本上都探討過，這里不在贅述。
業(yè)務應用層是企業(yè)真正關心的地方，也是我們構建容器云平臺的目的：支撐業(yè)務應用。在我們平臺層提供的能力完備的情況下，隨著微服務的建設，業(yè)務應用的研發(fā)將越來越敏捷?？梢酝ㄟ^簡單的服務編排就可以實現(xiàn)新的業(yè)務功能，部署為新的業(yè)務應用。就像樂高積木一樣，可以拼出不同的服務和應用。真正實現(xiàn)了敏捷！
從租戶視角容器云平臺更多是定位于一個應用管理和運營的平臺，它只是應用生命周期管理的一部分，應用的開發(fā)尚未納入進來。我們把應用的開發(fā)階段和流程分離，作為一個持續(xù)集成的組件，以鏡像倉庫為媒介，完成持續(xù)集成和持續(xù)部署的銜接，從而使持續(xù)集成-持續(xù)部署-持續(xù)發(fā)布-持續(xù)監(jiān)控-持續(xù)反饋-持續(xù)改進流程形成閉環(huán)DevOps鏈路。
持續(xù)集成完成標準化鏡像交付，持續(xù)部署完成測試和生產(chǎn)環(huán)境的鏡像部署，持續(xù)發(fā)布根據(jù)定義的發(fā)布規(guī)則發(fā)布生產(chǎn)可用服務，持續(xù)監(jiān)控實現(xiàn)對已發(fā)布服務和應用的持續(xù)健康檢查、異常告警等，持續(xù)反饋則實現(xiàn)健康檢查數(shù)據(jù)、異常告警數(shù)據(jù)等的收集分類、反饋，如果是代碼錯誤則自動記錄缺陷并轉研發(fā)人員（根據(jù)角色定義），啟動新一輪的流程（持續(xù)改進）。
容器云平臺的設計直接決定著其建設的能力，我們從不同角度分析和理解容器云的設計，融合微服務架構和DevOps方法論，來支持業(yè)務服務和業(yè)務應用的完整生命周期管理和治理，可以滿足不同復雜業(yè)務場景的需求，同時也支撐了客戶中心、服務中心系統(tǒng)的上線和運營。
聯(lián)系客服
