将 "名字空间" 改为 "命名空间"

Namespace 术语一般的翻译是"命名空间"，参见 <https://zh.wikipedia.org/zh-cn/%E5%91%BD%E5%90%8D%E7%A9%BA%E9%97%B4>

Signed-off-by: Tao Wang <twang2218@gmail.com>

security/README.md

@@ -1,6 +1,6 @@
 # 安全
 评估 Docker 的安全性时，主要考虑三个方面:
 
-* 由内核的名字空间和控制组机制提供的容器内在安全
+* 由内核的命名空间和控制组机制提供的容器内在安全
 * Docker 程序（特别是服务端）本身的抗攻击性
 * 内核安全性的加强机制对容器安全性的影响

security/daemon_sec.md

@@ -9,7 +9,7 @@
 
 用户仍可以利用 HTTP 提供 REST API 访问。建议使用安全机制，确保只有可信的网络或 VPN，或证书保护机制（例如受保护的 stunnel 和 ssl 认证）下的访问可以进行。此外，还可以使用 HTTPS 和证书来加强保护。
 
-最近改进的 Linux 名字空间机制将可以实现使用非 root 用户来运行全功能的容器。这将从根本上解决了容器和主机之间共享文件系统而引起的安全问题。
+最近改进的 Linux 命名空间机制将可以实现使用非 root 用户来运行全功能的容器。这将从根本上解决了容器和主机之间共享文件系统而引起的安全问题。
 
 终极目标是改进 2 个重要的安全特性：
 * 将容器的 root 用户映射到本地主机上的非 root 用户，减轻容器和主机之间因权限提升而引起的安全问题；

security/kernel_ns.md

@@ -1,15 +1,15 @@
-## 内核名字空间
-Docker 容器和 LXC 容器很相似，所提供的安全特性也差不多。当用 `docker run` 启动一个容器时，在后台 Docker 为容器创建了一个独立的名字空间和控制组集合。
+## 内核命名空间
+Docker 容器和 LXC 容器很相似，所提供的安全特性也差不多。当用 `docker run` 启动一个容器时，在后台 Docker 为容器创建了一个独立的命名空间和控制组集合。
 
-名字空间提供了最基础也是最直接的隔离，在容器中运行的进程不会被运行在主机上的进程和其它容器发现和作用。
+命名空间提供了最基础也是最直接的隔离，在容器中运行的进程不会被运行在主机上的进程和其它容器发现和作用。
 
 每个容器都有自己独有的网络栈，意味着它们不能访问其他容器的 sockets 或接口。不过，如果主机系统上做了相应的设置，容器可以像跟主机交互一样的和其他容器交互。当指定公共端口或使用 links 来连接 2 个容器时，容器就可以相互通信了（可以根据配置来限制通信的策略）。
 
 从网络架构的角度来看，所有的容器通过本地主机的网桥接口相互通信，就像物理机器通过物理交换机通信一样。
 
-那么，内核中实现名字空间和私有网络的代码是否足够成熟？
+那么，内核中实现命名空间和私有网络的代码是否足够成熟？
 
-内核名字空间从 2.6.15 版本（2008 年 7 月发布）之后被引入，数年间，这些机制的可靠性在诸多大型生产系统中被实践验证。
+内核命名空间从 2.6.15 版本（2008 年 7 月发布）之后被引入，数年间，这些机制的可靠性在诸多大型生产系统中被实践验证。
 
-实际上，名字空间的想法和设计提出的时间要更早，最初是为了在内核中引入一种机制来实现 [OpenVZ](http://en.wikipedia.org/wiki/OpenVZ) 的特性。
+实际上，命名空间的想法和设计提出的时间要更早，最初是为了在内核中引入一种机制来实现 [OpenVZ](http://en.wikipedia.org/wiki/OpenVZ) 的特性。
 而 OpenVZ 项目早在 2005 年就发布了，其设计和实现都已经十分成熟。