docker_practice/security/kernel_ns.md

16 lines
1.4 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters!

This file contains ambiguous Unicode characters that may be confused with others in your current locale. If your use case is intentional and legitimate, you can safely ignore this warning. Use the Escape button to highlight these characters.

## 內核名字空間
Docker 容器和 LXC 容器很相似,所提供的安全特性也差不多。當用 `docker run` 啟動一個容器時,在後臺 Docker 為容器建立了一個獨立的名字空間和控制組集合。
名字空間提供了最基礎也是最直接的隔離,在容器中執行的程式不會被執行在主機上的程式和其它容器發現和作用。
每個容器都有自己獨有的網路棧,意味著它們不能訪問其他容器的 sockets 或接口。不過,如果主機系統上做了相應的設置,容器可以像跟主機交互一樣的和其他容器交互。當指定公共端口或使用 links 來連接 2 個容器時,容器就可以相互通信了(可以根據設定來限制通信的策略)。
從網路架構的角度來看,所有的容器透過本地主機的網橋接口相互通信,就像物理機器透過物理交換機通信一樣。
那麽,內核中實做名字空間和私有網路的代碼是否足夠成熟?
內核名字空間從 2.6.15 版本2008 年 7 月發布)之後被引入,數年間,這些機制的可靠性在諸多大型生產系統中被實踐驗證。
實際上,名字空間的想法和設計提出的時間要更早,最初是為了在內核中引入一種機制來實做 [OpenVZ](http://en.wikipedia.org/wiki/OpenVZ) 的特性。
而 OpenVZ 項目早在 2005 年就發布了,其設計和實做都已經十分成熟。