樂視雲基於Kubernetes（k8s）的PaaS平臺建設_Kubernetes中文社群

本次分享主要介紹樂視雲兩代PaaS平臺的變遷過程，著重介紹第二代PaaS平臺LeEngine的架構設計和遇到的問題。

背景

2014年樂視雲開始嘗試Docker的推廣和使用，我們的團隊開始開發第一代容器雲平臺Harbor （分享網址：http://dockone.io/article/1091 ）。（在這裡提醒一下，這與VMware公司中國團隊為企業使用者設計的Docker Registry erver開源專案Harbor 重名）。

第一代容器雲平臺可以認為是一個開放的託管平臺。開發者可以將自己從公司申請的虛擬機器或者物理機新增到Harbor系統中進行託管管理，平臺基本包含：映象自動構建（CI），應用快速擴容、縮容、灰度升級，資源許可權管理，多叢集主機管理等功能。

由於那時容器才剛剛興起，剛開始在公司內部推動也有一定的阻力，剛開始給業務線推廣的時候，需要首先介紹Docker，介紹容器和虛擬機器的區別，然後再介紹平臺本身和使用方法，推廣成本以及業務線學習成本也比較高。接入Harbor上的業務的大多是業務線自己提供虛擬機器，而物理機佔少數。不過鑑於Harbor的易用程度，吸引了很多新業務接入。到現在為止Harbor已經完全實現開發自助化。業務自己新增主機，自主管理應用和容器，對應用進行升級、回滾，彈性伸縮，映象構建，現在已經穩定執行2年多。

第一代容器雲平臺不足之處

網路方面也是用的最基本的Nat，埠對映模式，存在效能問題。業務必須要知道容器對外映射出來的埠，對業務不透明，不便於報警和運維，也不便於對接負載均衡。

容器的分發排程全部自己開發，任務量大，當時沒有能夠做到容器自動遷移。
不支援應用的全球部署。
Harbor管理的計算資源需要業務線自己申請，計算資源可以是物理機也可以是虛擬機器，導致業務線需要關心底層的計算資源，計算資源無法對業務線完全透明。
為了降低使用者對Dockerfile的學習成本，我們對Dockerfile進行了封裝，只讓使用者寫Shell指令碼，因封裝的不合理，導致製作出的映象太大，尤其Maven專案，需要編譯，每次在Docker Build時候，都會重新下載依賴包，導致編譯過程長，映象大，並且容器內服務啟動方式不靈活。
監控報警機制不完善，沒有做到容器和應用級別的監控和報警。
映象倉庫Registry並沒有做得到像Docker Hub那樣使用者許可權劃分。

隨著Kubernetes在越來越多公司開始使用，樂視內部更多的團隊和業務線開始接受或者主動了解Docker，同時為了解決第一代平臺的存在問題和基於樂視現有服務部署情況，到2015年底，我們團隊計劃替換掉之前自己寫的排程方案，著手嘗試使用Kubernetes作為容器的排程引擎，在對比多套網路方案（Calico，Flannel等等）後，結合樂視現有狀況，採用Bridge模式，容器大二層網路方案。負載均衡使用Nginx，計算資源全部使用物理機，計算資源完全對業務透明。經過半年多的調研和開發，在2016年10月第二代PaaS平臺LeEngine在美國上線，半個月後，北京地區上線。LeEngine現在保持著一月一版本的開發迭代速度，到現在為止已經開發了3個版本。

LeEngine 採用全新的架構，主要面向於無狀態或者RPC應用。現在已經承接了樂視雲端計算，樂視體育章魚TV，風雲直播，樂視網樂看搜尋，雲相簿等近100多個重要業務，使用的客戶普遍反映一旦掌握了LeEngine的使用流程，從開發到上線部署，彈性伸縮，升級的效率可成倍增長，極大簡化了運維成本。LeEngine擁有極強的使用者粘性，吸引了很多業務線主動申請試用LeEngine，現階段已經不需要再增加額外的精力在公司內部推廣。

簡介

Kubernetes：Google開源的的容器編排工具，在整個2016年，越來越多的公司開始在線上使用Kubernetes，同時Kubernetes具備我們迫切需要的容器自動遷移和高可用功能。關於Kubernetes 的架構在這裡我就不多介紹了，雖然架構偏重，但是我們最終決定使用它，並且儘量只使用它的Pod，Replicationtroller和Service功能。

這裡首先解釋一下幾個概念：

使用者：樂視各個產品線下的產品、開發、測試、運維等人員。

Region：偏向於地理概念，例如北京和洛杉磯是兩個Region。同一個Region內要求內網可達，網路可靠，低延遲。同一個Region共用一套映象Registry，映象構建系統，負載均衡系統和監控報警系統，不同Region 共享全域性唯一的SDNS和GitLab程式碼倉庫。

Cell：我們現在使用的Kubernetes 1.2.0版本，理論上能控制1000個計算節點，為謹慎使用，規定一個Kubernetes叢集最大計算節點會控制在600個左右。 Cell 概念的引入是為了擴充單個Region下計算節點的規模，偏向於機房的概念，一個Cell 即一個Kubernetes叢集，每個Region下可以搭建多個Cell。所有Cell共享本Region下的映象Registry，映象構建系統，負載均衡系統和監控系統。為同一個Cell下的容器配置一個或者多個網段，每個網段劃分單獨的VLAN。同一Cell下的計算節點不會跨機房部署。

LeEngine Registry：基於Docker Registry 2.0做的部分修改，後端支援樂視雲的Ceph儲存。並仿照Docker Hub增加許可權和認證機制，只有擁有相應許可權的使用者才能對特定的映象進行Push和Pull操作。也可以設定映象公開，公開的映象任何使用者都可以Pull。

計算節點：物理機，Kubernetes的Node概念。

應用：定義提供相同業務邏輯的一組容器為一個應用，可以認為應用是一個微服務。這類應用要求是無狀態Web服務或者RPC類的服務。應用可以部署在多個Cell中。上文提到過，一個Cell可以認為是一個機房。LeEngine在一個Region下會至少部署2個Cell，部署應用時候，我們要求應用至少部署在2個Cell中，這樣即使一個機房出現網路故障時，另一個機房的應用容器還能繼續對外提供服務。一個應用下可以部署多個版本的容器，因此可以支援應用的灰度升級。訪問web類應用時候，我們強制要求這類應用（如果是線上應用）前面必須使用負載均衡，由我們的服務發現系統告訴負載均衡當前應用下有哪些容器IP。從Kubernetes層面講，我們規定一個應用對應Kubernetes下的一個Namespace，因此在應用的資料庫表中會存在一個Namespace的欄位，並需要全域性唯一，而應用的多個版本對應了在這個Namespace下建立的多個Replicationtroller。

Region、Cell 和kubernetes的關係：

架構平臺設計

容器直接執行在物理機上，計算節點全部由我們提供，業務線不需要關心，LeEngine可以作為一個企業解決方案對外全套輸出，平臺架構如下：

業務層：樂視使用容器的各個業務線，是LeEngine的終端使用者。
PaaS 層： LeEngine提供的各種服務，主要是完成對應用的彈性伸縮，灰度升級，自動接入負載均衡，監控，報警，快速部署，程式碼構建等服務。

宿主機資源層：主要指Docker 物理機叢集，幷包含IP池的管理。

使用者訪問部署在LeEngine上的應用時，首先通過SDNS智慧解析到對應的Nginx負載均衡叢集，然後由Nginx將請求打到對應的容器中。資料庫，快取等有狀態的服務並沒有在LeEngine體系之內，因為採用大二層網路，容器可以直接連線公司其他團隊提供的資料庫或者快取等服務。

下圖是為了更好的說明支援多地域，多kubernetes叢集的部署。

單一Region下單Cell部署圖：

我們將計算節點的管理網路和容器網路劃分開並給容器網路劃分單獨的VLAN。

成員、許可權管理

LeEngine下面定義了四大資源，應用、映象、映象分組和程式碼構建。為了團隊協同操作，這4大資源都增加了成員和許可權管理。成員和許可權仿照了GitLab進行了設計，成員角色分為：Owner、Master、Developer、Reporter、Guest。不同的角色針對不同的資源系統都定義了不同的許可權。比如應用，只有Owner和Master有許可權對應用部署新版本，彈性伸縮等等。假如一個使用者A建立了一個應用A1，那麼A就預設是應用A1的Owner，擁有對應用A1所有操作許可權，包括部署新版本，彈性伸縮，修改應用，刪除應用等所有操作。而使用者B此時對應用A1不可見，若想可見，必須由A對這個應用A1執行新增成員的操作，把B新增到A1中，並賦為除Owner以外的任何一個角色，若此時B被賦為Master角色，那B擁有了對應用A1部署新版本，彈性伸縮等許可權，反之則沒有。

根據上面的許可權設計，通過LeEngine的Console介面，不同的使用者登入後看到的僅僅是跟自己相關的資源，如下圖，在應用中，能看到我建立的以及我參與的應用：

在映象頁面，能夠看到我建立的以及我參與的映象，如下圖：

幫助文件會提供給使用者不同資源的許可權說明：

使用者端和管理端

LeEngine具有面向用戶端的Console介面和麵向運維管理員的boss介面，在使用者端使用者可以看到自己建立和參與的4種不同的資源。管理端則主要是對整個LeEngine平臺資源進行管理，包括使用者可使用最大資源的限制，負載均衡特殊配置，Cell叢集下的資源使用情況，操作頻率統計等等。

下圖是LeEngine測試環境boss系統關於操作頻率統計：

操作頻率包括每天所用應用的部署次數，程式碼的構建次數，映象的Push次數，彈性伸縮次數，在一定程度上能展示出業務線對LeEngine平臺本身的使用頻率。

LeEngine-core

LeEngine-core是LeEngine最終對外提供服務的API介面層（beego實現），所有4大資源的操作，包括許可權控制，都是通過這一層控制的。LeEngine只提供最原子的API介面，特殊業務線要想有特殊的需求，完全可以在現有API基礎上進行二次開發。

容器網路

容器採用大二層網路，因此可以保證外部服務可以直接連通容器，容器也可以直接連通外部服務，比如資料庫，快取等等。採用此種方案可以保證容器橫向可連線，縱向可訪問。外部想連線容器可以通過容器IP地址直接連線，也可以通過負載均衡方式進行訪問。而容器也可以直接訪問LeEngine體系外的虛擬，物理機資源，以及MySQL等元件服務。

我們自己寫了CNI外掛和CNICTL管理工具，支援新增多個IP段，用來防止IP資源不夠的情況。IP段的資訊存在了當前Kubernetes叢集裡的etcd中。我們會為每個Cell即每個Kubernetes叢集下都新增至少一個IP段，一般1024個IP地址22子網掩碼，單獨vlan防止廣播風暴，這需要提前跟網路部門規劃好IP段。如果這個IP段已經使用完，我們會使用CNICTL工具，重新增加一個新的IP段。

為了進一步保證業務容器在網路方面的穩定性，我們所有的計算節點都是4個網絡卡，2千兆，2萬兆，雙雙做bond，千兆bond1用來做管理網絡卡，萬兆bond1用來跑業務容器，每個計算節點在交付時候會建立一個OVS網橋，並將bond1掛載上去，上聯交換機做堆疊，計算節點儘量打散在多個不同機櫃中。

計算節點物理機上的Kubulet在建立Pod的PAUSE容器後，會呼叫我們自己CNI外掛，CNI會建立一個veth pair，一端扔到這個容器的Namespace中，並命名eth0，一端掛載到OVS網橋上，之後從etcd中大的IP段中找出一個連續16個IP地址的小段給這個計算節點，然後再從這個子段中找一個空閒的IP給這個容器，配置好容器IP，以及路由資訊，同時會根據配置來確定是否傳送免費ARP資訊，之後遵守CNI規範把相應的資訊返回給kubelet。當這個計算節點再次建立新的Pod時，會優先從這個子段中選擇空間的IP，若沒有空閒的IP地址，會重新計算一個子段給這個計算節點用。

現在CNI不能保證Pod刪掉重新建立時候IP保持不變，因此應用在每次升級操作後，容器IP地址會變，這就需要我們的服務發現與負載均衡做對接。

不過現在的這套方案也會存在一些問題：比如物理主機突然down掉，或者Docker程序死掉，導致本主機上所有容器掛掉，等kubelet重新啟動後，原來死掉的容器所佔用的IP並不會釋放。我們現在的解決方案是通過我們開發CNICTL命令來進行定期檢測。CNICTL提供一個check命令，會檢索etcd中所有分配的IP和對應的POD資訊，之後呼叫apiserver獲得所有Pod資訊，取差值則為沒釋放的IP地址。收到報警後，人工呼叫CNICTL的釋放IP功能，手動釋放IP。

服務發現

我們充分利用了Kubernetes的Service概念，前面已經提過，一個應用對應一個Namespace，一個版本對應一個RC，在使用者通過API請求建立應用時候，LeEngine核心API層：LeEngin-core會預設在對應的Kubernetes叢集中建立相關聯的Namespace，同時預設在這個Namespace下建立一個Service，並建立一個唯一的標籤屬性，使用者在部署新版本（RC）時候，LeEngine會給這個RC新增這個Service的唯一標籤。這樣就可以通過Service來發現後端的Endpoint。我們用Go寫了一個服務發現服務，通過watch api-server的API介面，自動歸類發現哪個應用下有IP變動，之後呼叫我們負載均衡的API介面，動態更改Nginx的後端upstream serverip。

在我們沒使用Kubernetes的健康探測功能之前，會有一定的機率出現容器建立完成，服務沒有完全啟動，這時候容器IP已經載入到負載均衡的情況，如果這時候如果剛好有請求過來，會出現請求失敗的現象。之後我們在最新一版中，加入了健康探測功能，使用者在給應用部署新版本時，允許使用者指定自己服務的監控探測HTTP介面，當容器內服務探測成功後，才會加入到負載均衡中去。而刪除容器則不會出現這種情況，執行RC縮容命令後，需要刪除的容器首先會立馬從負載均衡中刪除，之後才會執行容器的刪除操作。

負載均衡

我們並沒有使用Kubernetes的Proxy作為負載均衡，而是使用Nginx叢集作為負載均衡。Nginx我們原則上會部署在同一個Region下的多個機房中，防止因為機房網路故障導致全部的Nginx不可用，支援Nginx橫向可擴充套件，當負載均衡壓力過大時候，可以快速橫向增加Nginx物理機。為防止單一Nginx叢集下代理的Domain數目過多，以及區分不同的業務邏輯,比如公網和內網負載均衡，我們支援建立多個Nginx負載叢集。

下圖為使用者瀏覽請求路徑。

關於如何能夠通知Nginx叢集自動更新Upstream下的Server IP問題，我們在Nginx叢集外面用beego框架設計了一層API層：slb-core，專門對外提供API介面，具體結構如下：

etcd裡面存放每個domain的配置資訊。具體key結構如下：

/slb/{groupname or groupid}/domains/{domain_name}/

每一臺Nginx主機上都會安裝一個Agent，每個Agent監控他所屬的groupid 的key，比如/slb/2/，這樣可監控本Nginx 叢集下所有Domain的配置變化，Agent 將變化過的Domain 配置更新到Nginx下的目錄下，並判斷配置變化是否是更改的upstream下的Server IP還是其他配置，如果發現是其他配置更改，比如location或者增加header，則會reload nginx，如果發現單純更改upstream 下Server IP，則直接呼叫Nginx動態更改upstream ip的介面。

上層的slb-core 則會提供domain動態更改後臺upstream ip的介面，供服務發現呼叫。

如果多個互相關聯，互相呼叫的業務域名都同時被一個Nginx叢集所代理，若其中一個domain需要更改配置，導致需要reload nginx，很可能會出現reload 時間過長的問題。

基於這套架構，後端Nginx主機可以快速擴充套件，迅速增加到對應叢集中。由於增加了nginx test機制，當用戶更改domain的配置有語法問題，也不會影響負載均衡，還會保持上一個正確的配置。現在這套架構已經是樂視負載叢集的通用架構，承載了樂視上千個域名的負載均衡。

使用者在建立一個應用時候，如果需要負載均衡則需要填寫負載均衡域名，Nginx叢集等資訊，如下圖：

建立成功後，通過檢視應用的負載均衡導航欄可以知道這個應用負載均衡的CNAME和VIP資訊，等業務測試成功後，DNS系統上配置使域名生效。

如下圖：

下圖可以讓使用者檢視負載均衡Nginx配置資訊：

現階段Nginx負載均衡叢集並沒有按照一個應用來進行劃分，大多數情況是一個Nginx負載均衡叢集代理了多組domain。因此對於使用者端，為了防止業務線使用者惡意或者無意的隨便更改，而導致整個Nginx叢集出現問題，現階段使用者端無權更改Nginx配置，如果需要更改特殊配置，需要聯絡管理員，由管理員進行配置。後續我們會考慮給一個應用分配一組Nginx容器進行負載均衡代理，這樣使用者就會擁有Nginx配置更改的最高許可權。

LeEngine registry

LeEngine Registry是我們內部提供的映象倉庫，根據Docker Registry 2.0 版本：docker distribution做了修改，支援樂視Ceph後端儲存，同時使用auth-server 以及LeEngine 的許可權機制，定義使用者和許可權劃分。允許映象私有和公開。公開的映象任何使用者可以執行Pull 操作。私有的映象可以新增團隊成員，不同角色的成員具有不同的Push，Pull，刪除許可權。基於以上的設計LeEngine Registry 可以完全獨立於LeEngine對外提供映象倉庫服務，業務線如果不想使用LeEngine的程式碼構建功能，可以完全使用自己的構建方法，構建出映象來，之後Push 到LeEngine registry中。

如下圖是關於映象tag的相關操作：

成員：

動態：

LeEngine下4大資源：應用、映象、映象組織、程式碼構建，在每個資源頁裡都是有動態一欄，用來記錄操作記錄,方便以後的問題追蹤。

程式碼構建

為了快速將程式碼構建成Image，並Push到映象倉庫中，LeEngine後面會設定一組專門構建用的Docker物理機叢集，用來執行構建任務，每個構建物理機都會安裝一個Agent。

LeEngine的程式碼構建框架如下：

每個構建物理機上的agent 啟動後，都會將自己的資訊定期自動註冊到etcd中，表示新增一臺構建機，當Agent意外停止或者主機掛掉，etcd中的註冊資訊會失效，表示已經下線一臺構建機。另外Agent會監控自己的任務key，用來接收LeEngine-core下發的構建任務。

當有一個構建請求時會呼叫LeEngine-core的API，LeEngine-core會從etcd中選出一個合適的構建機（一般按照hash方式，儘量保證一個程式碼構建在同一臺物理機上構建，加快構建速度），然後將構建任務放到這個構建機的任務key中，對應的Agent監控到key變化後，會執行程式碼Clone，編譯，Build和Push操作。

Etcd在LeEngine中扮演這非常重要的角色，是各個模組通訊的訊息匯流排。

鑑於Maven專案，需要編譯，在第一代Harbor系統中，編譯步驟放在了Docker Build 過程中，由於Maven編譯需要大量的mvn依賴，每次編譯都需要重新下載依賴，導致編譯時間長，編譯的映象多大，因此我們在Build之前，會起一個Container，在Container中對程式碼進行編譯，並將mvn依賴的目錄對映到主機上，這樣同一個程式碼構建，在每次構建時候，都會共享同一個mvn依賴，不需要重新下載，加快編譯速度，同時還能保證不同的程式碼構建使用不同的mvn依賴目錄，保證編譯環境絕對純淨，最後只將編譯好的二進位制打到映象中，在一定程度上保證程式碼不外洩。

程式碼構建僅限於放在Git上的程式碼，現階段並不支援SVN，因此有的業務如果程式碼在SVN上，可以使用其他工具自己將程式碼製作成映象，然後Push到LeEngine Registry上。由於LeEngine Registry上對映象和映象倉庫做了許可權認證，保證了映象的安全。

程式碼構建支援手動構建和自動構建，在GitLab上設定相應的Web hook，這樣使用者只要提交程式碼，就會自動觸發LeEngine的程式碼構建功能。

下圖為建立程式碼構建的Web頁：

使用LeEngine的程式碼構建，我們要求使用者的程式碼裡需要自己寫Dockerfile，Dockerfile 裡FROM 的根映象可以使用LeEngine Registry 裡公開的映象，也可以使用Docker Hub裡公開的映象。

如果業務程式碼需要編譯，則可以指定編譯環境，編譯指令碼也是需要放到程式碼中。

下圖為手動構建頁面：

tag名如果不寫，LeEngine會根據當前分支下的commit號作為映象tag名。如果選用mvncache，則本次構建就會使用上次構建所下載的mvn依賴，加快構建速度。

下圖為構建結果：

構建過程：

構建日誌中，每一關鍵環節都記錄了耗時時間，以及具體的執行過程。

應用管理

應用支援垮機房部署，多版本灰度升級，彈性伸縮等功能。我們規定一個應用對應一個映象。

部署版本（一個版本即一個RC）時候，需要指定映象tag，容器數目，CPU，記憶體，環境變數，健康檢查等等引數，現在的健康檢查我們暫時只支援http介面方式：

由於大部分的升級，都是更改映象tag，因此每次部署新版本時候，LeEngine會在新彈出框內，將上一版本的容器數目，CPU，記憶體，環境變數，健康檢查等等引數自動填充到彈出框中，使用者只需選擇新的映象tag就可以了。因此最後灰度上線，只需要建立新版本等新版本的容器完全啟動，服務自動加入負載均衡後，再將舊版本刪除即可。

下圖為應用事件檢視：

應用事件主要收集的是應用在Kubernetes叢集中的事件資訊。

監控、告警系統

監控報警我們分PaaS平臺和業務應用兩大類。

PaaS平臺主要聚焦在基礎設施和LeEngine的各個服務元件的監控報警（比如主機CPU，記憶體，IO，磁碟空間，LeEngine各個服務程序等等），這一類使用公司統一的監控報警機制。

業務應用類，也就是跑在LeEngine上的各個業務線的監控和報警，需要由LeEngine進行對其進行監控和報警，觸發報警後，會通知給各個應用的負責人。我們採用了heapster 來收集容器的監控資訊和Kubernetes的各種事件。每個Cell叢集中都部署一個heapster，監控資料存放到influxdb中。設定了一個應用全域性對應一個Kubernetes的Namespace，因此我們能很好的聚合出應用和單個容器的監控資料。

如下圖針對應用的網路流量監控：

容器 IP，執行時間和狀態：

下圖是針對應用下單個容器的監控：

現在heapster 沒法收集容器的磁碟IO資料，後期我們會增加對於磁碟IO的監控收集，同時我們會豐富其他的監控資料（比如請求量等等）。關於報警，我們後期準備使用kapacitor 進行使用者自助化報警，讓使用者自定義設定針對於應用cpu，記憶體，網路，IO，容器重啟，刪除等的報警閥值。觸發報警後，會呼叫公司統一的告警平臺（電話，郵件，簡訊三種方式）對相關人員進行報警。預設報警人員為當前應用的Owner和Master角色的成員。此功能已經基本調研完成，計劃3月底上線。

日誌收集

根據公司具體狀況，容器的日誌收集暫時還沒有納入LeEngine範圍內，全部由業務線自己收集，然後統一收入到公司的日誌系統中或者由業務線自己搭建日誌儲存和檢索系統。我們後期會考慮日誌統一收集。

總結

一鍵式解決方案

LeEngine提供了程式碼構建，映象倉庫，應用管理，基本上實現了開發者一鍵式解決方案：

各個業務線開發人員只需要提交程式碼，剩下的就會根據打包和構建規則自動生成特定的映象版本，測試和運維人員只需要拿著對應的映象版本進行測試和線上升級即可，極大簡化開發運維工作。

減少運維成本

我們建議程式在容器內前臺啟動，利用Kubernetes的功能，程式死掉後，由kubelet自動拉起，實時保證線上容器例項數。若需要除錯，業務或者運維可以直接通過SSH連線到容器內排查問題。由於Kubernetes強大的容器自動遷移功能，即使後端物理主機出現宕機或者網路問題，也不會產生嚴重的問題，除非後端物理計算資源不夠，這在很大程度上減少了運維人員大半夜被叫起處理問題的次數。

計算資源對業務完全透明

底層計算資源完全由我們提供，業務線不用擔心資源的問題。

產品化

LeEngine在設計之初，保證儘量少的依賴其他外部資源和服務，整個LeEngine可以作為一個解決方案整體對外輸出。

存在的問題

任何一款產品不管怎麼設計，都有它的不足之處，LeEngine在上線之後，我們也收到了不少反饋和問題。

按照之前的運維習慣，運維人員在排查問題時候，經常會根據IP來進行區分，而LeEngine下的應用每次升級後，容器IP都會變化，這對傳統的運維造成一定的衝擊。我們現在的解決思路是，如果運維人員一定要通過IP去排查，我們會讓運維人員登入LeEngine的Console，檢視當前應用下的容器IP列表，之後再去逐個排查。同時有的業務會對IP進行訪問限制，針對這種情況，我們只能讓這些業務對一個IP段進行限制。
Kubernetes 1.2版本，對容器的swap並沒有控制，若業務應用有bug，出現大量的記憶體洩露，往往會把容器所在物理機的swap吃滿，而影響了物理機上其他的容器。我們現在的解決方案暫時只能通過報警方式，儘快讓使用者修復問題。
由於Dockerfile 和編譯指令碼都要求放在使用者Git程式碼中。會存在使用者Git使用不規範，不同分支程式碼互相merge，導致Dockerfile和編譯指令碼出現變化，導致構建出的映象與預期的不一樣，從而上線失敗。這種問題，我們只能要求業務線規範Git使用規範，LeEngine程式碼構建本身已經無法控制到這種細粒度。
現階段我們還沒法做到自動彈性擴容（給應用設定一個最小容器數目和最大容器數目的閥值，根據CPU、記憶體、IO、請求量或者其他值，自動覺得容器是否需要擴容，縮容）。

展望

Docker和Kubernetes也在飛速發展中，相信Kubernetes未來會有更加強勁的功能，我們後續也會考慮把有狀態的服務跑到Kubernetes中去，歡迎大家一塊探索。