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 年就發布了,其設計和實現都已經十分成熟。