Docker解決了云計算環(huán)境難于分發(fā)并且管理復雜，而用KVM、Xen等虛擬化又浪費系統(tǒng)資源的問題。Docker最初是基于lxc構建了容器引擎，為了提供跨平臺支持，后又專門開發(fā)了libcontainer來抽象容器引擎。但無論是libcontainer還是lxc，其底層所依賴的內核特性都是相同的。我們來看看docker都使用了技術來實現(xiàn)容器引擎的。

命名空間

Docker使用了pid、network、ipc、美m(xù)nt、uts等命名空間來隔離網(wǎng)絡、文件系統(tǒng)、進程等資源。注意，由于Linux并不是namespace了所有東西（如cgroups、/sys、SELinux、/dev/sd*、內核模塊等），僅靠這幾個namespace是無法實現(xiàn)像KVM那樣的完全資源隔離的。

• pid namespace：實現(xiàn)進程隔離，容器只能看到自己的進程，并且每個容器都有一個pid為1的父進程，kill掉該進程容器內的所有進程都會停止；
• net namespace：實現(xiàn)網(wǎng)絡隔離，每個容器都可以設置自己的interface、routers、iptables等；docker默認采用veth的方式將container中的虛擬網(wǎng)卡同host上的一個docker bridge: docker0連接在一起；
• ipc namespace：container中進程交互還是采用linux常見的進程間交互方法(interprocess communication - IPC), 包括常見的信號量、消息隊列和共享內存。然而同 VM 不同的是，container 的進程間交互實際上還是host上具有相同pid namespace中的進程間交互，因此需要在IPC資源申請時加入namespace信息 - 每個IPC資源有一個唯一的 32 位 ID；
• mnt namespace：類似chroot，將一個進程放到一個特定的目錄執(zhí)行。mnt namespace允許不同namespace的進程看到的文件結構不同，這樣每個 namespace 中的進程所看到的文件目錄就被隔離開了。同chroot不同，每個namespace中的container在/proc/mounts的信息只包含所在namespace的mount point；
• uts namspace：允許每個container擁有獨立的hostname和domain name, 使其在網(wǎng)絡上可以被視作一個獨立的節(jié)點而非Host上的一個進程；
• user namespace：每個container可以有不同的 user 和 group id, 也就是說可以在container內部用container內部的用戶執(zhí)行程序而非Host上的用戶。

對于容器所依賴的內核文件系統(tǒng)（這些都是non-namespaced），為了保證安全性，docker將其限制為只讀的：

. /sys . /proc/sys . /proc/sysrq-trigger . /proc/irq . /proc/bus  

cgroups機制

cgroups 實現(xiàn)了對資源的配額和度量。 cgroups 的使用非常簡單，提供類似文件的接口，在 /cgroup目錄下新建一個文件夾即可新建一個group，在此文件夾中新建task文件，并將pid寫入該文件，即可實現(xiàn)對該進程的資源控制。groups可以限制blkio、cpu、cpuacct、cpuset、devices、freezer、memory、net_cls、ns九大子系統(tǒng)的資源，以下是每個子系統(tǒng)的詳細說明：

• blkio 這個子系統(tǒng)設置限制每個塊設備的輸入輸出控制。例如:磁盤，光盤以及usb等等。
• cpu 這個子系統(tǒng)使用調度程序為cgroup任務提供cpu的訪問。
• cpuacct 產(chǎn)生cgroup任務的cpu資源報告。
• cpuset 如果是多核心的cpu，這個子系統(tǒng)會為cgroup任務分配單獨的cpu和內存。
• devices 允許或拒絕cgroup任務對設備的訪問。
• freezer 暫停和恢復cgroup任務。
• memory 設置每個cgroup的內存限制以及產(chǎn)生內存資源報告。
• net_cls 標記每個網(wǎng)絡包以供cgroup方便使用。
• ns 名稱空間子系統(tǒng)。

對于centos7來說，通過systemd-cgls來查看系統(tǒng)cgroups tree：

... ├─docker-b1f965f8e682e9d2ff9ed3039fca63c008810efd9c5e6d796344b0270d329a98.scope │ ├─18853 /usr/lib/systemd/systemd │ └─system.slice │ ├─keepalived.service │ │ ├─19307 /usr/sbin/keepalived -D -d -S 7 │ │ └─19309 /usr/sbin/keepalived -D -d -S 7 │ ├─haproxy.service │ │ ├─25195 /usr/sbin/haproxy-systemd-wrapper -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid │ │ ├─25210 /usr/sbin/haproxy -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid -Ds │ │ └─25211 /usr/sbin/haproxy -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid -Ds │ ├─rsyslog.service │ │ └─23648 /usr/sbin/rsyslogd -n │ └─systemd-journald.service │ └─18990 /usr/lib/systemd/systemd-journald ...  

特權模式下的容器：

└─system.slice ├─NetworkManager-dispatcher.service │ └─2580 /usr/libexec/nm-dispatcher.action ├─var-lib-docker-devicemapper-mnt-a80a5f851d00842414d5fb03866c19424df1f2afb47a04f41dd056b54c4df7ac.mount ├─docker-a80a5f851d00842414d5fb03866c19424df1f2afb47a04f41dd056b54c4df7ac.scope │ ├─2558 /usr/sbin/init │ └─system.slice │ ├─systemd-journald.service │ │ └─2605 /usr/lib/systemd/systemd-journald │ ├─dbus.socket │ ├─dbus.service │ ├─system-getty.slice │ ├─rc-local.service │ ├─systemd-user-sessions.service │ ├─dev-dm\x2d0.swap │ ├─etc-yum.repos.d.mount │ ├─etc-hosts.mount │ ├─etc-hostname.mount │ ├─etc-resolv.conf.mount │ └─-.mount  

cgroups配置方法：

(1) cpu相對權重：docker run -it --rm -c 512，如果未設置，默認為1024

# cat /sys/fs/cgroup/cpu/system.slice/docker-a80a5f851d00842414d5fb03866c19424df1f2afb47a04f41dd056b54c4df7ac.scope/cpu.shares 1024  

如果在容器開啟的時候沒有設置cpu權重，可以在容器啟動后修改，如

[root@fei ~]# systemctl set-property --runtime docker-a80a5f851d00842414d5fb03866c19424df1f2afb47a04f41dd056b54c4df7ac.scope CPUShares=128 [root@fei ~]# cat /sys/fs/cgroup/cpu/system.slice/docker-a80a5f851d00842414d5fb03866c19424df1f2afb47a04f41dd056b54c4df7ac.scope/cpu.shares 128  

(2) 設置cpu pin：docker run -it --rm --cpuset=0,1

# cat /sys/fs/cgroup/cpuset/system.slice/docker-b0848aa49a03b8541bb698c1544b6c411c584dce5e86831f84803228e93e61d4.scope/cpuset.cpus 
0-1 

(3) 內存限制: docker run -it --rm -m 128m，默認swap為mem的兩倍

[root@fei ~]# cat /sys/fs/cgroup/memory/system.slice/docker-c9fed54afc8986be888b231b984be9c1a2a533c739f7a5458a56882fb13b4b93.scope/memory.limit_in_bytes 134217728 [root@fei ~]# cat /sys/fs/cgroup/memory/system.slice/docker-c9fed54afc8986be888b231b984be9c1a2a533c739f7a5458a56882fb13b4b93.scope/memory.memsw.limit_in_bytes 268435456 

如果不設置-m 128m，則默認容器內存是不設限的

[root@fei ~]# cat /sys/fs/cgroup/memory/system.slice/docker-641cdebd22b55f2656a560cd250e661ab181dcf2f5c5b78dc306df7ce62231f2.scope/memory.limit_in_bytes 9223372036854775807  

(4) 磁盤IO限制，docker本身默認沒有做磁盤io的限制，不過我們可以通過直接操作cgroups來實現(xiàn)

# 磁盤寫 [root@fei ~]# cid=641cdebd22b5 [root@fei ~]# nsenter --target $(docker inspect -f '{{ .State.Pid }}' $cid) --mount --uts --ipc --net --pid mount | head -1 /dev/mapper/docker-253:1-138011042-641cdebd22b55f2656a560cd250e661ab181dcf2f5c5b78dc306df7ce62231f2 on / type ext4 (rw,relatime,discard,stripe=16,data=ordered) [root@fei ~]# systemctl set-property --runtime docker-641cdebd22b55f2656a560cd250e661ab181dcf2f5c5b78dc306df7ce62231f2.scope "BlockIOWriteBandwidth=/dev/mapper/docker-253:1-138011042-641cdebd22b55f2656a560cd250e661ab181dcf2f5c5b78dc306df7ce62231f2 1M" # 磁盤讀 [root@fei ~]# systemctl set-property --runtime docker-641cdebd22b55f2656a560cd250e661ab181dcf2f5c5b78dc306df7ce62231f2.scope "BlockIOReadBandwidth =/dev/mapper/docker-253:1-138011042-641cdebd22b55f2656a560cd250e661ab181dcf2f5c5b78dc306df7ce62231f2 1M"  

(5) 磁盤大小，docker容器默認都會分配10GB的空間，如果想改變這個值，需要修改docker服務啟動參數(shù)，并重啟docker服務：docker -d --storage-opt dm.basesize=5G。其他磁盤相關的配置可以參考https://github.com/docker/docker/tree/master/daemon/graphdriver/devmapper。

Capability機制

Linux把原來和超級用戶相關的高級權限劃分成為不同的單元，稱為Capability，這樣就可以獨立對特定的Capability進行使能或禁止。通常來講，不合理的禁止Capability，會導致應用崩潰。

Docker默認為容器刪除了以下capability：

CAP_SETPCAP Modify process capabilities CAP_SYS_MODULE Insert/Remove kernel modules CAP_SYS_RAWIO Modify Kernel Memory CAP_SYS_PACCT Configure process accounting CAP_SYS_NICE Modify Priority of processes CAP_SYS_RESOURCE Override Resource Limits CAP_SYS_TIME Modify the system clock CAP_SYS_TTY_CONFIG Configure tty devices CAP_AUDIT_WRITE Write the audit log CAP_AUDIT_CONTROL Configure Audit Subsystem CAP_MAC_OVERRIDE Ignore Kernel MAC Policy CAP_MAC_ADMIN Configure MAC Configuration CAP_SYSLOG Modify Kernel printk behavior CAP_NET_ADMIN Configure the network CAP_SYS_ADMIN Catch all  

如果確實需要這些capability，可以通過--cap-add or --cap-drop添加或刪除，如docker run --cap-add all --cap-drop sys-admin -ti rhel7 /bin/sh。

SELinux

SELinux是一個標簽系統(tǒng)，進程有標簽，每個文件、目錄、系統(tǒng)對象都有標簽。SELinux通過撰寫標簽進程和標簽對象之間訪問規(guī)則來進行安全保護。

Union FS

對于這種疊加的文件系統(tǒng)，有一個很好的實現(xiàn)是AUFS，在Ubuntu比較新的發(fā)行版里都是自帶的，這個可以做到以文件為粒度的copy-on-write，為海量的container的瞬間啟動，提供了技術支持，也會持續(xù)部署提供了幫助（注意，centos7系統(tǒng)是基于devicemapper來實現(xiàn)類似的功能的）。

AUFS支持為每一個成員目錄(類似Git Branch)設定readonly、readwrite 和 whiteout-able 權限, 同時 AUFS 里有一個類似分層的概念, 對 readonly 權限的 branch 可以邏輯上進行修改(增量地, 不影響 readonly 部分的)。通常 Union FS 有兩個用途, 一方面可以實現(xiàn)不借助 LVM、RAID 將多個disk掛到同一個目錄下, 另一個更常用的就是將一個 readonly 的 branch 和一個 writeable 的 branch 聯(lián)合在一起，Live CD正是基于此方法可以允許在 OS image 不變的基礎上允許用戶在其上進行一些寫操作。Docker 在 AUFS 上構建的 container image 也正是如此。
Iptables, netfilter

主要用來做ip數(shù)據(jù)包的過濾，比如可以做container之間無法通信，container可以無法訪問host的網(wǎng)絡，但是可以通過host的網(wǎng)卡訪問外網(wǎng)等這樣的網(wǎng)絡策略

setrlimit

可以限制container中打開的進程數(shù)，限制打開的文件個數(shù)等

原文出自：http://blog.csdn.net/feiskyer/article/details/41246657