NameSpace && CGroups
容器作为用户应用最终运行的承载体，其依赖的核心技术值得深 入研究。事实上，容器所依托的技术并非新技术，而是早已存在多年 的两种相对较成熟的技术：Namespace 和CGroups。科技界的技术创新 经常出现这种情形：几种成熟技术的组合往往会成就一个巨大创新。 容器技术就是通过组合Namespace 和CGroups 这两个耳熟能详的技术，对云计算进行根本性的变革。
在这场大变革中，Namespace 提供了不同类型资源的隔离，CGroups 则针对相应的资源进行了限制分配和统计。
Namespace
Linux 内核从2.4.19 版本开始引入Namespace 技术，译为 “命名空 间”，它提供了一种内核级别的系统资源的隔离方式。系统可以为进程分配不同的Namespace，并保证不同的 Namespace 资源独立分配、进程彼此隔离，即不同的Namespace 下的进程互不干扰。
Linux 内核支持6 种 Namespace。主机有其默认的 Namespace，行为与用户的 Namespace 完全一致，不同进程可以通过不同的 Namespace 进行隔离。当系统启动一个容器时，会为该容器创建相应的不同类型的 Namespace，为运行在容器内的进程提供相应的资源隔离。
Linux 支持的Namespace 类型、隔离资源及Kernel 版本如下表所示：
| NameSpace 类型 | 隔离资源 | Kernel 版本 |
|---|---|---|
| ipc | System V IPC 和 POSIX 消息队列 | 2.6.19 |
| net | 网络设备、网络协议栈、网络接口等 | 2.6.29 |
| pid | 进程 | 2.6.14 |
| mnt | 挂载点 | 2.4.19 |
| uts | 主机和域名 | 2.6.19 |
| user | 用户和用户组 | 3.8 |
CGroups
CGroups（Control Groups）是 Linux 下用于对一个或一组进程进行资源控制和监控的机制。利用 CGroups 可以对诸如CPU 使用时间、内 存、磁盘I/O 等进程所需的资源进行限制。Kubernetes 允许用户为Pod的容器申请资源，当容器在计算节点上运行起来时，可以通过 CGroups 来完成资源的分配和限制。在 CGroups 中，对资源的控制都是以 CGroup 为单位的。目前 CGroups 可以控制多种资源，不同资源的具体管理工作由相应的 CGroup 子系统（Subsystem）来实现。因此，针对不同类型的资源限制，只要将限制策略在不同的的子系统上进行关联即可。
CGroups 由谷歌的工程师引入2.6.24 版本的内核中，最初只对CPU 进行了资源限制，然而随着对其他资源控制需求的增多，它们的CGroup 子系统不断地被引入内核。在容器时代，特别是Kubernetes 中，为了提高对节点资源的利用率，一个节点上会运行尽可能多的容器，这就对资源隔离 的多样性和精确性提出了越来越高的要求，因此CGroups 也发挥着越来越重要的作用。
对于CGroups 的组织管理，用户可以通过文件操作来实现，对资源的控制可以细化到线程级别。CGroups 在不同的系统资源管理子系统中以层级树（Hierarchy）的方式来组织管理：每个CGroup 都可以包含其他的子CGroup，因此子 CGroup 能使用的资源，除了受本CGroup
配置的资源参数限制，还受到父 CGroup 设置的资源限制。
由于 CGroups 包含众多的子系统，而不同的子系统在开发和管理时并没有进行有效的协调和统一，所以造成不同的子系统之间不协调，层级树管理也变得愈加复杂。于是从3.10版本的内核开始，实现了 CGroups 的v2 版本。尽管 CGroups v2 是用来替代CGroups v1的，但由于目前实现的控制子系统有限，且目前的容器运行时都基于 CGroup v1 来实现，所以CGroup v2 只是在开发完善中，并没有被大规模使
用。
好吧，表示这篇有点尴尬哈。
这很正常的，哪里会都像前两篇那么满满当当嘛是吧。