[[186080]]

操作系統(tǒng)我們知道:

完整的操作系統(tǒng)=內(nèi)核+apps 

內(nèi)核負(fù)責(zé)管理底層硬件資源，包括CPU、內(nèi)存、磁盤等等，并向上為apps提供系統(tǒng)調(diào)用接口，上層apps應(yīng)用必須通過系統(tǒng)調(diào)用方式使用硬件資源，通常并不能直接訪問資源。apps就是用戶直接接觸的應(yīng)用，比如命令行工具、圖形界面工具等(linux的圖形界面也是作為可選應(yīng)用之一，而不像windows是集成到內(nèi)核中的)。同一個(gè)內(nèi)核加上不同的apps，就構(gòu)成了不同的操作系統(tǒng)發(fā)行版，比如ubuntu、rethat、android(當(dāng)然內(nèi)核通常針對(duì)不同的發(fā)行版會(huì)有修改)等等。因此我們可以認(rèn)為，不同的操作系統(tǒng)發(fā)行版本其實(shí)就是由應(yīng)用apps構(gòu)成的環(huán)境的差別(比如默認(rèn)安裝的軟件以及鏈接庫、軟件包管理、圖形界面應(yīng)用等等)。我們把所有這些apps環(huán)境打成一個(gè)包，就可以稱之為鏡像。問題來了，假如我們同時(shí)有多個(gè)apps環(huán)境，能否在同一個(gè)內(nèi)核上運(yùn)行呢?因?yàn)椴僮飨到y(tǒng)只負(fù)責(zé)提供服務(wù)，而并不管為誰服務(wù)，因此同一個(gè)內(nèi)核之上可以同時(shí)運(yùn)行多個(gè)apps環(huán)境。比如假設(shè)我們現(xiàn)在有ubuntu和fedora的apps環(huán)境，即兩個(gè)發(fā)行版鏡像，分別位于/home/int32bit/ubuntu和/home/int32bit/fedora，我們最簡單的方式，采用chroot工具即可快速切換到指定的應(yīng)用環(huán)境中，相當(dāng)于同時(shí)有多個(gè)apps環(huán)境在運(yùn)行。

容器技術(shù)

我們以上通過chroot方式，好像就已經(jīng)實(shí)現(xiàn)了容器的功能，但其實(shí)容器并沒有那么簡單，工作其實(shí)還差得遠(yuǎn)。首先要作為云資源管理還必須滿足：

1.資源隔離

因?yàn)樵朴?jì)算本質(zhì)就是集中資源再分配(社會(huì)主義)，再分配過程就是資源的邏輯劃分，提供資源抽象的實(shí)現(xiàn)方式比如我們熟悉的虛擬機(jī)等，我們把資源抽象一次劃分稱為單元。單元必須滿足隔離性，包括用戶隔離(或者說權(quán)限隔離)進(jìn)程隔離、網(wǎng)絡(luò)隔離、文件系統(tǒng)隔離等，即單元內(nèi)部只能感知其內(nèi)部的資源，而不能感知單元以外的資源(包括宿主資源以及其他單元的資源)。

2.資源控制

即為單元分配資源量，能控制單元的資源***使用量。單元不能使用超過分配的資源量。當(dāng)然還包括其他很多條件，本文主要基于這兩個(gè)基本條件進(jìn)行研究。 顯然滿足以上兩個(gè)條件，虛擬機(jī)是一種實(shí)現(xiàn)方式，這是因?yàn)椋?/p>

• 隔離毋容置疑，因?yàn)椴煌奶摂M機(jī)運(yùn)行在不同的內(nèi)核，虛擬機(jī)內(nèi)部是一個(gè)獨(dú)立的隔離環(huán)境
• hypervisor能夠?qū)μ摂M機(jī)分配指定的資源

基于虛擬機(jī)快速構(gòu)建應(yīng)用環(huán)境比如vagrant等。但是虛擬機(jī)也帶來很多問題，比如：

• 鏡像臃腫龐大，不僅包括apps，還必須包括一個(gè)龐大的內(nèi)核
• 創(chuàng)建和啟動(dòng)時(shí)間開銷大，不利于快速構(gòu)建重組
• 額外資源開銷大，部署密度小
• 性能損耗
• …

有沒有其他實(shí)現(xiàn)方式能符合以上兩個(gè)條件呢?容器技術(shù)便是另一種實(shí)現(xiàn)方式。表面上和我們使用chroot方式相似，即所有的容器實(shí)例內(nèi)部的應(yīng)用是直接運(yùn)行在宿主機(jī)中，所有實(shí)例共享宿主機(jī)的內(nèi)核，而虛擬機(jī)實(shí)例內(nèi)部的進(jìn)程是運(yùn)行在GuestOS中。由以上原理可知，容器相對(duì)于虛擬機(jī)有以上好處：

• 鏡像體積更小，只包括應(yīng)用以及所依賴的環(huán)境，沒有內(nèi)核。
• 創(chuàng)建和啟動(dòng)快，不需要啟動(dòng)GuestOS，應(yīng)用啟動(dòng)開銷基本就是應(yīng)用本身啟動(dòng)的時(shí)間開銷。
• 無GuestOS，無hypervisor，無額外資源開銷，資源控制粒度更小，部署密度大。
• 使用的是真實(shí)物理資源，因此不存在性能損耗。
• 輕量級(jí)
• …

但如何實(shí)現(xiàn)資源隔離和控制呢?

1. 隔離性

主要通過內(nèi)核提供namespace技術(shù)實(shí)現(xiàn)隔離性，以下參考酷殼:

Linux Namespace是Linux提供的一種內(nèi)核級(jí)別環(huán)境隔離的方法。不知道你是否還記得很早以前的Unix有一個(gè)叫chroot的系統(tǒng)調(diào)用(通過修改根目錄把用戶jail到一個(gè)特定目錄下)，chroot提供了一種簡單的隔離模式：chroot內(nèi)部的文件系統(tǒng)無法訪問外部的內(nèi)容。Linux Namespace在此基礎(chǔ)上，提供了對(duì)UTS、IPC、mount、PID、network、User等的隔離機(jī)制。

Linux Namespace 有如下種類，官方文檔在這里《Namespace in Operation》

由上表可知，通過Namespaces技術(shù)可以實(shí)現(xiàn)隔離性，比如網(wǎng)絡(luò)隔離，我們可以通過sudo ip netns ls查看網(wǎng)絡(luò)命名空間，通過ip netns add NAME增加網(wǎng)絡(luò)命名等。

2.資源控制

內(nèi)核實(shí)現(xiàn)了對(duì)進(jìn)程組的資源控制，即Linux Control Group，簡稱cgoup，它能為系統(tǒng)中運(yùn)行進(jìn)程組根據(jù)用戶自定義組分配資源。簡單來說，可以實(shí)現(xiàn)把多個(gè)進(jìn)程合成一個(gè)組，然后對(duì)這個(gè)組的資源進(jìn)行控制，比如CPU使用時(shí)間，內(nèi)存大小、網(wǎng)絡(luò)帶寬、磁盤讀寫等，linux把cgroup抽象成一個(gè)虛擬文件系統(tǒng)，可以掛載到指定的目錄下，ubuntu14.04默認(rèn)自動(dòng)掛載在/sys/fs/cgroup下，用戶也可以手動(dòng)掛載，比如掛載memory子系統(tǒng)(子系統(tǒng)一類資源的控制，比如cpu、memory，blkio等)到/mnt下：

sudo mount -t cgroup -o memory memory /mnt 

掛載后就能像查看文件一樣方便瀏覽進(jìn)程組以及資源控制情況，控制組并不是孤立的，而是組織成樹狀結(jié)構(gòu)構(gòu)成進(jìn)程組樹，控制組的子節(jié)點(diǎn)會(huì)繼承父節(jié)點(diǎn)。下面以memory子系統(tǒng)為例，

ls /sys/fs/cgroup/memory/ 

輸出：

cgroup.clone_children  memory.kmem.failcnt                 memory.kmem.tcp.usage_in_bytes   memory.memsw.usage_in_bytes      memory.swappiness 
cgroup.event_control   memory.kmem.limit_in_bytes          memory.kmem.usage_in_bytes       memory.move_charge_at_immigrate  memory.usage_in_bytes 
cgroup.procs           memory.kmem.max_usage_in_bytes      memory.limit_in_bytes            memory.numa_stat                 memory.use_hierarchy 
cgroup.sane_behavior   memory.kmem.slabinfo                memory.max_usage_in_bytes        memory.oom_control               notify_on_release 
docker                 memory.kmem.tcp.failcnt             memory.memsw.failcnt             memory.pressure_level            release_agent 
memory.failcnt         memory.kmem.tcp.limit_in_bytes      memory.memsw.limit_in_bytes      memory.soft_limit_in_bytes       tasks 
memory.force_empty     memory.kmem.tcp.max_usage_in_bytes  memory.memsw.max_usage_in_bytes  memory.stat                      user 

以上是根控制組的資源限制情況，我們以創(chuàng)建控制內(nèi)存為4MB的Docker容器為例：

docker run -m 4MB -d busybox ping localhost 

返回id為0532d4f4af67，自動(dòng)會(huì)創(chuàng)建以docker實(shí)例id為為名的控制組，位于/sys/fs/cgroup/memory/docker/0532d4f4af67...，我們查看該目錄下的memory.limit_in_bytes文件內(nèi)容為：

cat memory.limit_in_bytes 
4194304 

即***的可使用的內(nèi)存為4MB，正好是我們啟動(dòng)Docker所設(shè)定的。

由以上可知，容器實(shí)現(xiàn)了資源的隔離性以及控制性。容器的具體實(shí)現(xiàn)如LXC、LXD等。

Docker技術(shù)

Docker是PaaS提供商dotCloud開源的一個(gè)基于LXC的高級(jí)容器引擎，簡單說Docker提供了一個(gè)能夠方便管理容器的工具。使用Docker能夠：

• 快速構(gòu)建基于容器的分布式應(yīng)用
• 具有容器的所有優(yōu)點(diǎn)
• 提供原生的資源監(jiān)控
• …

Docker與虛擬機(jī)原理對(duì)比：

由于容器技術(shù)很早就有，Docker最核心的創(chuàng)新在于它的鏡像管理，因此有人說：

Docker = 容器 + Docker鏡像 

Docker鏡像的創(chuàng)新之處在于使用了類似層次的文件系統(tǒng)AUFS，簡單說就是一個(gè)鏡像是由多個(gè)鏡像層層疊加的，從一個(gè)base鏡像中通過加入一些軟件構(gòu)成一個(gè)新層的鏡像，依次構(gòu)成***的鏡像，如圖

docker的幾點(diǎn)疑問:

Image的分層，可以想象成photoshop中不同的layer。每一層中包含特定的文件，當(dāng)container運(yùn)行時(shí)，這些疊加在一起的層就構(gòu)成了container的運(yùn)行環(huán)境(包括相應(yīng)的文件，運(yùn)行庫等，不包括內(nèi)核)。Image通過依賴的關(guān)系，來確定整個(gè)鏡像內(nèi)到底包含那些文件。之后的版本的docker，會(huì)推出squash的功能，把不同的層壓縮成為一個(gè)，和Photoshop中合并層的感覺差不多。 作者：Honglin Feng 鏈接：https://www.zhihu.com/question/25394149/answer/30671258 來源：知乎 著作權(quán)歸作者所有。商業(yè)轉(zhuǎn)載請(qǐng)聯(lián)系作者獲得授權(quán)，非商業(yè)轉(zhuǎn)載請(qǐng)注明出處。

這樣的好處是：

• 節(jié)省存儲(chǔ)空間 - 多個(gè)鏡像共享base image存儲(chǔ)
• 節(jié)省網(wǎng)絡(luò)帶寬 - 拉取鏡像時(shí)，只需要拉取本地沒有的鏡像層，本地已經(jīng)存在的可以共享，避免多次傳輸拷貝
• 節(jié)省內(nèi)存空間 - 多個(gè)實(shí)例可共享base image, 多個(gè)實(shí)例的進(jìn)程***緩存內(nèi)容的幾率大大增加。如果基于某個(gè)鏡像啟動(dòng)一個(gè)虛擬機(jī)需要資源k，則啟動(dòng)n個(gè)同一個(gè)鏡像的虛擬機(jī)需要占用資源kn，但如果基于某個(gè)鏡像啟動(dòng)一個(gè)Docker容器需要資源k，無論啟動(dòng)多少個(gè)實(shí)例，資源都是k。
• 維護(hù)升級(jí)方便 - 相比于 copy-on-write 類型的FS，base-image也是可以掛載為可writeable的，可以通過更新base image而一次性更新其之上的container
• 允許在不更改base-image的同時(shí)修改其目錄中的文件 - 所有寫操作都發(fā)生在最上層的writeable層中，這樣可以大大增加base image能共享的文件內(nèi)容。

使用容器技術(shù)，帶來了很多優(yōu)點(diǎn)，但同時(shí)也存在一些問題：

• 隔離性相對(duì)虛擬機(jī)弱-由于和宿主機(jī)共享內(nèi)核，帶來很大的安全隱患，容易發(fā)生逃逸。
• 如果某些應(yīng)用需要特定的內(nèi)核特性，使用容器不得不更換宿主機(jī)內(nèi)核。
• …

Hyper

上文提到容器也存在問題，并且Docker的核心創(chuàng)新在于鏡像管理，即：

Docker = 容器 + Docker鏡像 

有人提出把容器替換成最初的hypervisor，即接下來介紹的Hyper，官方定義：

Hyper - a Hypervisor-based Containerization solution 

即

Hyper = Hypervisor + Docker鏡像 

Hyper是一個(gè)基于虛擬化技術(shù)(hypervisor)的Docker引擎。

雖然Hyper同樣通過VM來運(yùn)行Docker應(yīng)用，但HyperVM里并沒有GuestOS，相反的，一個(gè)HyperVM內(nèi)部只有一個(gè)極簡的HyperKernel，以及要運(yùn)行的Docker鏡像。這種Kernel+Image的”固態(tài)”組合使得HyperVM和Docker容器一樣，實(shí)現(xiàn)了Immutable Infrastructure的效果。借助VM天然的隔離性，Hyper能夠完全避免LXC共享內(nèi)核的安全隱患.

創(chuàng)建一個(gè)基于Hyper的ubuntu：

sudo hyper run -t ubuntu:latest bash 

創(chuàng)建時(shí)間小于1秒，確實(shí)達(dá)到啟動(dòng)容器的效率。 查看內(nèi)核版本：

root@ubuntu-latest-7939453236:/# uname -a  
Linux ubuntu-latest-7939453236 4.4.0-hyper+ #0 SMP Mon Jan 25 01:10:46 CST 2016 x86_64 x86_64 x86_64 GNU/Linux 

宿主機(jī)內(nèi)核版本：

$ uname -a  
Linux lenovo 3.13.0-77-generic #121-Ubuntu SMP Wed Jan 20 10:50:42 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux 

啟動(dòng)基于Docker的ubuntu并查看內(nèi)核版本:

$ docker run -t -i ubuntu:14.04 uname -a 
Linux 73a88ca16d94 3.13.0-77-generic #121-Ubuntu SMP Wed Jan 20 10:50:42 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux 

我們發(fā)現(xiàn)Docker和宿主機(jī)的內(nèi)核版本是一樣的，即3.13.0-77-generic,而Hyper內(nèi)核不一樣，版本為4.4.0-hyper。 以下為官方數(shù)據(jù)：

Hyper combines the best from both world: VM and Container.

Hyper確實(shí)是容器和虛擬機(jī)的一種很好的折衷技術(shù)，未來可能前景廣大，但需要進(jìn)一步觀察，我個(gè)人主要存在以下疑問：

• 使用極簡的內(nèi)核，會(huì)不會(huì)導(dǎo)致某些功能丟失?
• 是不是需要為每一個(gè)應(yīng)用維護(hù)一個(gè)微內(nèi)核?
• 有些應(yīng)用需要特定內(nèi)核，這些應(yīng)用實(shí)際多么?可以通過其他方式避免么?
• Hyper引擎能否提供和Docker引擎一樣的api，能否在生態(tài)圈中相互替代?
• 隔離性加強(qiáng)的同時(shí)也犧牲了部分性能，這如何權(quán)衡?

總結(jié)

本文首先介紹了操作系統(tǒng)，然后引出容器技術(shù)以及虛擬機(jī)技術(shù)，***介紹了Docker和Hyper技術(shù)。通過本文可以清楚地對(duì)三者有了感性認(rèn)識(shí)。 近年來容器技術(shù)以及微服務(wù)架構(gòu)非常火熱，CaaS有取代傳統(tǒng)IaaS的勢(shì)頭，未來云計(jì)算市場(chǎng)誰成為主流值得期待。

【本文是51CTO專欄作者“付廣平”的原創(chuàng)文章，如需轉(zhuǎn)載請(qǐng)通過51CTO獲得聯(lián)系】

戳這里，看該作者更多好文