Hyper容器雲及雲上運維

作為一家專注於虛擬化容器技術的創業公司，可以說在國內的容器創業圈裡算是比較獨特的。截至目前，除了自主打造了一套相容oci的容器runtime，在github上維護了若干個開源專案之外，我們還做了一套公有雲服務（

關於hyper，大家比較好奇，本文將從三個方面重點分享hyper的原理和容器雲運維：從docker到hyper container，hyper container用於公有雲，容器雲上運維的變化。

docker大家應該非常熟悉，四年前，從乙個相對單純的runtime發展到今天，包含集群管理、容器編排、各種網路/儲存外掛程式等複雜的生態系統，甚至連作業系統打包都給放進去了（前不久dockercon上發布的linuxkit）。docker這項技術出來之後受到大家極大地關注和追捧，可以說引發了眾多領域的巨大變革，各種聚焦容器技術的開源專案、創業公司更是如雨後春筍。

但是，我們把目光回到最初，docker剛開始出來的時候，它的本質是什麼？我們認為， docker本質上由兩大塊組成：容器技術 + docker image。

docker基本原理

docker image是docker最天才的一項創造。雖然它所用到的各種技術是之前就有的，但把這些技術以這樣的姿勢組合起來，之前真的是沒有人想到。我們可以認為這是一種新的應用打包方式，但是它又超越了以前傳統的rpm、deb打包，rpm、deb只是把應用的檔案堆在一起，頂多再加上一些pre-install、post-install指令碼，外部通yum、apt來解決依賴關係。而docker image不僅僅是把應用的檔案給打進去，還包括了這個應用所有的依賴，再底下就是核心了。而且不止如此，它還把應用執行的一些資訊，比如user、worker dir等都給放進去，非常規範地把這個應用的方方面面都給描述出來，這個是一項前所未有的技術。

而容器技術，最早docker用的就是lxc，跟我們廣泛使用的虛擬機器相比，它看起來很像虛擬機器，但比虛擬機器輕很多，建立速度為毫秒級。非常輕量，沒有虛擬機器vcpu、記憶體等方面的效能損耗，但同時它的缺點就是隔離度比虛擬機器要弱很多，因為容器是利用核心的namespace、cgroup等技術來進行環境的隔離和資源的限制，乙個宿主上的所有容器共享同乙個核心，相對而言攻擊面就會大很多。

關於這一點，圈內有很多爭議，有人認為容器的安全性可以不斷改進，最終達到乙個可用的程度，但另一派就覺得由於它的原理是共享核心，所以從根本上就不可能做到足夠的安全。爭論很多，但無論如何，「容器的隔離性比虛機弱」是業界的共識，如果實在不放心，就把容器放到虛機裡面去用吧。事實上這也是幾乎所有公有雲提供容器執行的方式：先給使用者建立虛機，然後再在虛機裡面跑使用者的容器。沒有公有雲敢冒險直接在物理機上起容器分給多個租戶去用。

既然如此，我們就產生了乙個想法：可否直接把虛機跟docker image對接起來？回過頭來想，容器的本質到底是什麼？我們認為容器的本質，其實是邊界。舉乙個生活中的例子，我們拿乙個杯子去裝水，這個杯子有底、有側邊，這個底和側邊就把杯子裡外的空間隔離開了，我們稱之為乙個容器。對於lxc而言，它是通過namespace來做邊界；而對於vm，如果把虛擬的硬體當做邊界，vm也可以看做一種容器。只不過lxc是乙個比較易碎的玻璃杯，甚至是紙杯，而vm則是更加堅固的不鏽鋼杯子。我們用vm替換lxc直接跟docker image對接，就得到了虛擬化容器，我們稱之為hyper container。這樣一來，隔離性的問題就解決了。但同時它還能不能保持之前的輕量和快速，這是需要考慮的問題。

hyper技術原理

docker/hyper容器啟動過程對比

接下來，我們來hyper解決輕量和快速的問題。顯然hyper container比lxc要重，我們需要想辦法盡量使它輕量化。

首先，加快容器啟動速度。起乙個虛機大概需要兩三秒，雖然時間也不太長，但比容器還是慢多了，怎樣加快呢？1，精簡vm配置和核心；2，我們做了乙個vm cache功能，預先準備虛機池，使用者run容器的時候，直接從虛機池裡選取，再動態調cpu和記憶體。最終我們把run乙個容器的時間縮短到了300多毫秒，跟lxc差不多了。

另一方面，降低記憶體開銷。每乙個虛機都有自己的核心和initrd，會占用一部分記憶體，如果宿主上同時running幾十上百個容器，這個消耗不容忽視。怎麼辦呢？我們的核心大牛又搞出了一項技術，就是讓同一臺宿主上的所有hyper container共享同乙份核心和initrd，大大減少了記憶體開銷。最終效果就是每個hyper container額外的記憶體開銷小於10m。

通過上述努力，hyper container終於做到了既輕快，又安全，完美地解決了問題。怎麼樣，完美嗎？大家都是搞技術的，實事求是講，沒有完美的方案。大家可以看出來，hyper container畢竟是在虛擬機器裡面跑應用，跟物理機裡直接跑lxc容器相比，效能上還是會打個折扣。魚和熊掌不可兼得，一定是捨棄一些東西、取得一些東西，拋開實際場景去談方案的優劣都是耍流氓。

應該說，hyper container最合適的場景是在公有雲上。前面也提到了，目前市面上所有的公有雲提供容器的服務，都是先給使用者建立虛擬機器集群，再在集群上面構建容器平台，然後再去跑容器。這個層次結構就比較複雜，因為在公有雲上，安全是必須要考慮的問題。假如直接在物理機上起容器分給多租戶，某乙個租戶的容器被人黑進來了，就很可能突破容器的隔離進而控制整個宿主，這個後果是很嚴重的。但如果使用了hyper container，就可以把使用者容器直接跑在物理機上，因為hyper container是虛機級別的隔離度。這樣一來，雲的部署架構就可以很大地簡化，可以只留一層排程。從使用者視角來看，管理的複雜度也大大降低了，因為不用再關心集群的事情，直接就使用容器。

hyper container 用於公有雲

有了這個最基本的功能之後，我們又做了一些比較上層的建築：1，hyper compose，相容docker compose規範，本地docker compose到雲上無縫過渡；2，hyper service，源自kubernetes的概念；3，hyper cron，這是乙個比較獨特的服務，就像在linux裡設定cron任務一樣，可以在我們的雲上來設定在什麼時間run什麼樣的容器；4，hyper func，乙個以docker為中心的serverless解決方案。

最後想分享一下我對於容器時代運維的一些思考。在容器時代，很多運維理念跟以前不太一樣了。

資源視角。以前，資源就是機器，不管是物理機還是虛機。但是在容器雲上不再有機器的概念了，只需要考慮這個應用需要多少資源，就建立多大的容器，這個是乙個很大的變化。

環境配置管理。傳統的運維都會有一套配置管理的工具（例如puppet）來保證集群中每台機器的配置一致，但是在容器時代，乙個應用所需要的依賴、配置全部打包進映象裡了，puppet就不再需要了。不過呢，容器映象的打包、儲存、分發也是需要整套的流程，這個事情其實並不簡單，複雜度甚至可能更高。

應用的變更。傳統的運維方式，就是就是把應用的二進位制檔案編譯好了扔到伺服器上，替換舊的，重啟服務，發現有問題趕緊把舊檔案換回來，回滾服務，這是典型的變更方式。到了容器時代還是變成了映象，要公升級乙個服務時候，重新build映象，分發，重新建立容器。

metrics 資訊收集/監控。傳統的方式，在機器上放agent，收集各種metrics，包括應用程序的資訊。而用容器部署之後，應用都放進容器裡了，原先收集資訊的方式可能就不靈了。容器有它的一套規範。

綜合起來看，每乙個方面，使用容器後並不一定變得更簡單，有時反而會變複雜。我認為很長時間內這兩種部署方式還會同時並存。不過從長遠看，把容器各方面彙總起來作為乙個完整的生態去看，它帶來的總的好處還是會超過付出的成本。一開始運維可能很不適應，但是我相信未來的趨勢是容器，我們要往這個方向去努力。

Hyper容器雲及雲上運維

Hyper容器雲及雲上運維

Hyper容器雲及雲上運維

雲上RAC部署 運維及實踐案例

相關推薦

雲上RAC部署運維及實踐案例