建站
咨詢
售后
建站咨詢
新聞中心
操作系統(tǒng)我們知道:
創(chuàng)新互聯(lián)公司 - 雅安服務(wù)器托管，四川服務(wù)器租用，成都服務(wù)器租用，四川網(wǎng)通托管,綿陽服務(wù)器托管，德陽服務(wù)器托管，遂寧服務(wù)器托管，綿陽服務(wù)器托管，四川云主機(jī)，成都云主機(jī)，西南云主機(jī)，雅安服務(wù)器托管，西南服務(wù)器托管，四川/成都大帶寬，服務(wù)器機(jī)柜，四川老牌ＩＤＣ服務(wù)商
- 完整的操作系統(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)核中的)。同一個內(nèi)核加上不同的apps，就構(gòu)成了不同的操作系統(tǒng)發(fā)行版，比如ubuntu、rethat、android(當(dāng)然內(nèi)核通常針對不同的發(fā)行版會有修改)等等。因此我們可以認(rèn)為，不同的操作系統(tǒng)發(fā)行版本其實就是由應(yīng)用apps構(gòu)成的環(huán)境的差別(比如默認(rèn)安裝的軟件以及鏈接庫、軟件包管理、圖形界面應(yīng)用等等)。我們把所有這些apps環(huán)境打成一個包，就可以稱之為鏡像。問題來了，假如我們同時有多個apps環(huán)境，能否在同一個內(nèi)核上運行呢?因為操作系統(tǒng)只負(fù)責(zé)提供服務(wù)，而并不管為誰服務(wù)，因此同一個內(nèi)核之上可以同時運行多個apps環(huán)境。比如假設(shè)我們現(xiàn)在有ubuntu和fedora的apps環(huán)境，即兩個發(fā)行版鏡像，分別位于/home/int32bit/ubuntu和/home/int32bit/fedora，我們最簡單的方式，采用chroot工具即可快速切換到指定的應(yīng)用環(huán)境中，相當(dāng)于同時有多個apps環(huán)境在運行。
容器技術(shù)
我們以上通過chroot方式，好像就已經(jīng)實現(xiàn)了容器的功能，但其實容器并沒有那么簡單，工作其實還差得遠(yuǎn)。首先要作為云資源管理還必須滿足：
1.資源隔離
因為云計算本質(zhì)就是集中資源再分配(社會主義)，再分配過程就是資源的邏輯劃分，提供資源抽象的實現(xiàn)方式比如我們熟悉的虛擬機(jī)等，我們把資源抽象一次劃分稱為單元。單元必須滿足隔離性，包括用戶隔離(或者說權(quán)限隔離)進(jìn)程隔離、網(wǎng)絡(luò)隔離、文件系統(tǒng)隔離等，即單元內(nèi)部只能感知其內(nèi)部的資源，而不能感知單元以外的資源(包括宿主資源以及其他單元的資源)。
2.資源控制
即為單元分配資源量，能控制單元的資源***使用量。單元不能使用超過分配的資源量。當(dāng)然還包括其他很多條件，本文主要基于這兩個基本條件進(jìn)行研究。 顯然滿足以上兩個條件，虛擬機(jī)是一種實現(xiàn)方式，這是因為：
- 隔離毋容置疑，因為不同的虛擬機(jī)運行在不同的內(nèi)核，虛擬機(jī)內(nèi)部是一個獨立的隔離環(huán)境
- hypervisor能夠?qū)μ摂M機(jī)分配指定的資源
基于虛擬機(jī)快速構(gòu)建應(yīng)用環(huán)境比如vagrant等。但是虛擬機(jī)也帶來很多問題，比如：
- 鏡像臃腫龐大，不僅包括apps，還必須包括一個龐大的內(nèi)核
- 創(chuàng)建和啟動時間開銷大，不利于快速構(gòu)建重組
- 額外資源開銷大，部署密度小
- 性能損耗
- …
有沒有其他實現(xiàn)方式能符合以上兩個條件呢?容器技術(shù)便是另一種實現(xiàn)方式。表面上和我們使用chroot方式相似，即所有的容器實例內(nèi)部的應(yīng)用是直接運行在宿主機(jī)中，所有實例共享宿主機(jī)的內(nèi)核，而虛擬機(jī)實例內(nèi)部的進(jìn)程是運行在GuestOS中。由以上原理可知，容器相對于虛擬機(jī)有以上好處：
- 鏡像體積更小，只包括應(yīng)用以及所依賴的環(huán)境，沒有內(nèi)核。
- 創(chuàng)建和啟動快，不需要啟動GuestOS，應(yīng)用啟動開銷基本就是應(yīng)用本身啟動的時間開銷。
- 無GuestOS，無hypervisor，無額外資源開銷，資源控制粒度更小，部署密度大。
- 使用的是真實物理資源，因此不存在性能損耗。
- 輕量級
- …
但如何實現(xiàn)資源隔離和控制呢?
1. 隔離性
主要通過內(nèi)核提供namespace技術(shù)實現(xiàn)隔離性，以下參考酷殼:
Linux Namespace是Linux提供的一種內(nèi)核級別環(huán)境隔離的方法。不知道你是否還記得很早以前的Unix有一個叫chroot的系統(tǒng)調(diào)用(通過修改根目錄把用戶jail到一個特定目錄下)，chroot提供了一種簡單的隔離模式：chroot內(nèi)部的文件系統(tǒng)無法訪問外部的內(nèi)容。Linux Namespace在此基礎(chǔ)上，提供了對UTS、IPC、mount、PID、network、User等的隔離機(jī)制。
Linux Namespace 有如下種類，官方文檔在這里《Namespace in Operation》
由上表可知，通過Namespaces技術(shù)可以實現(xiàn)隔離性，比如網(wǎng)絡(luò)隔離，我們可以通過sudo ip netns ls查看網(wǎng)絡(luò)命名空間，通過ip netns add NAME增加網(wǎng)絡(luò)命名等。
2.資源控制
內(nèi)核實現(xiàn)了對進(jìn)程組的資源控制，即Linux Control Group，簡稱cgoup，它能為系統(tǒng)中運行進(jìn)程組根據(jù)用戶自定義組分配資源。簡單來說，可以實現(xiàn)把多個進(jìn)程合成一個組，然后對這個組的資源進(jìn)行控制，比如CPU使用時間，內(nèi)存大小、網(wǎng)絡(luò)帶寬、磁盤讀寫等，linux把cgroup抽象成一個虛擬文件系統(tǒng)，可以掛載到指定的目錄下，ubuntu14.04默認(rèn)自動掛載在/sys/fs/cgroup下，用戶也可以手動掛載，比如掛載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é)點會繼承父節(jié)點。下面以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，自動會創(chuàng)建以docker實例id為為名的控制組，位于/sys/fs/cgroup/memory/docker/0532d4f4af67...，我們查看該目錄下的memory.limit_in_bytes文件內(nèi)容為：
- cat memory.limit_in_bytes
- 4194304
即***的可使用的內(nèi)存為4MB，正好是我們啟動Docker所設(shè)定的。
由以上可知，容器實現(xiàn)了資源的隔離性以及控制性。容器的具體實現(xiàn)如LXC、LXD等。
Docker技術(shù)
Docker是PaaS提供商dotCloud開源的一個基于LXC的高級容器引擎，簡單說Docker提供了一個能夠方便管理容器的工具。使用Docker能夠：
- 快速構(gòu)建基于容器的分布式應(yīng)用
- 具有容器的所有優(yōu)點
- 提供原生的資源監(jiān)控
- …
Docker與虛擬機(jī)原理對比：
由于容器技術(shù)很早就有，Docker最核心的創(chuàng)新在于它的鏡像管理，因此有人說：
- Docker = 容器 + Docker鏡像
Docker鏡像的創(chuàng)新之處在于使用了類似層次的文件系統(tǒng)AUFS，簡單說就是一個鏡像是由多個鏡像層層疊加的，從一個base鏡像中通過加入一些軟件構(gòu)成一個新層的鏡像，依次構(gòu)成***的鏡像，如圖
docker的幾點疑問:
Image的分層，可以想象成photoshop中不同的layer。每一層中包含特定的文件，當(dāng)container運行時，這些疊加在一起的層就構(gòu)成了container的運行環(huán)境(包括相應(yīng)的文件，運行庫等，不包括內(nèi)核)。Image通過依賴的關(guān)系，來確定整個鏡像內(nèi)到底包含那些文件。之后的版本的docker，會推出squash的功能，把不同的層壓縮成為一個，和Photoshop中合并層的感覺差不多。 作者：Honglin Feng 鏈接：https://www.zhihu.com/question/25394149/answer/30671258 來源：知乎 著作權(quán)歸作者所有。商業(yè)轉(zhuǎn)載請聯(lián)系作者獲得授權(quán)，非商業(yè)轉(zhuǎn)載請注明出處。
這樣的好處是：
- 節(jié)省存儲空間 - 多個鏡像共享base image存儲
- 節(jié)省網(wǎng)絡(luò)帶寬 - 拉取鏡像時，只需要拉取本地沒有的鏡像層，本地已經(jīng)存在的可以共享，避免多次傳輸拷貝
- 節(jié)省內(nèi)存空間 - 多個實例可共享base image, 多個實例的進(jìn)程***緩存內(nèi)容的幾率大大增加。如果基于某個鏡像啟動一個虛擬機(jī)需要資源k，則啟動n個同一個鏡像的虛擬機(jī)需要占用資源kn，但如果基于某個鏡像啟動一個Docker容器需要資源k，無論啟動多少個實例，資源都是k。
- 維護(hù)升級方便 - 相比于 copy-on-write 類型的FS，base-image也是可以掛載為可writeable的，可以通過更新base image而一次性更新其之上的container
- 允許在不更改base-image的同時修改其目錄中的文件 - 所有寫操作都發(fā)生在最上層的writeable層中，這樣可以大大增加base image能共享的文件內(nèi)容。
使用容器技術(shù)，帶來了很多優(yōu)點，但同時也存在一些問題：
- 隔離性相對虛擬機(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是一個基于虛擬化技術(shù)(hypervisor)的Docker引擎。
雖然Hyper同樣通過VM來運行Docker應(yīng)用，但HyperVM里并沒有GuestOS，相反的，一個HyperVM內(nèi)部只有一個極簡的HyperKernel，以及要運行的Docker鏡像。這種Kernel+Image的”固態(tài)”組合使得HyperVM和Docker容器一樣，實現(xiàn)了Immutable Infrastructure的效果。借助VM天然的隔離性，Hyper能夠完全避免LXC共享內(nèi)核的安全隱患.
創(chuàng)建一個基于Hyper的ubuntu：
- sudo hyper run -t ubuntu:latest bash
創(chuàng)建時間小于1秒，確實達(dá)到啟動容器的效率。 查看內(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
啟動基于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確實是容器和虛擬機(jī)的一種很好的折衷技術(shù)，未來可能前景廣大，但需要進(jìn)一步觀察，我個人主要存在以下疑問：
- 使用極簡的內(nèi)核，會不會導(dǎo)致某些功能丟失?
- 是不是需要為每一個應(yīng)用維護(hù)一個微內(nèi)核?
- 有些應(yīng)用需要特定內(nèi)核，這些應(yīng)用實際多么?可以通過其他方式避免么?
- Hyper引擎能否提供和Docker引擎一樣的api，能否在生態(tài)圈中相互替代?
- 隔離性加強(qiáng)的同時也犧牲了部分性能，這如何權(quán)衡?
總結(jié)
本文首先介紹了操作系統(tǒng)，然后引出容器技術(shù)以及虛擬機(jī)技術(shù)，***介紹了Docker和Hyper技術(shù)。通過本文可以清楚地對三者有了感性認(rèn)識。 近年來容器技術(shù)以及微服務(wù)架構(gòu)非?；馃?，CaaS有取代傳統(tǒng)IaaS的勢頭，未來云計算市場誰成為主流值得期待。
【本文是專欄作者“付廣平”的原創(chuàng)文章，如需轉(zhuǎn)載請通過獲得聯(lián)系】
本文名稱：虛擬機(jī)、Docker和Hyper技術(shù)比較
URL地址：http://m.5511xx.com/article/dpgohhh.html
