容器化技术

2.1 容器化概述

2.1.1 容器化发展

早期，大家都认为硬件抽象层基于 hypervisor 的虚拟化方式可以最大程度上提供虚拟化管理的灵活性。各种不同操作系统的虚拟机都能通过 hypervisor 来衍生、运行、销毁。然而，随着时间推移，发现 hypervisor 这种方式麻烦越来越多。因为对于 hypervisor 环境来说，每个虚拟机都需要运行一个完整的操作系统以及其中安装好的大量应用程序。但实际生产开发环境里，我们更关注的是自己部署的应用程序，如果每次部署发布都得搞一个完整操作系统和附带的依赖环境，就显得很繁琐。

基于上述情况，人们就在想，有没有其他什么方式能让人更加的关注应用程序本身，底层多余的操作系统和环境我可以共享和复用？换句话来说，那就是部署一个服务运行好后，再想移植到另外一个地方，可以不用再安装一套操作系统和依赖环境。这就像集装箱运载一样，我把货物一辆兰博基尼跑车(Application)，打包放到一容器集装箱里，它通过货轮可以轻而易举的从上海码头(CentOS 7)运送到纽约码头(Ubuntu 14 )。而且运输期间，我的兰博基尼(Application)没有受到任何的损坏(文件没有丢失)，在另外一个码头卸货后，依然可以完美启动。

Linux Container 容器技术的诞生就解决了 IT 世界里“集装箱运输”的问题。Linux Container(简称 LXC)它是一种内核轻量级的操作系统层虚拟化技术。Linux Container 主要由 Namespace 和 Cgroup 两大机制来保证实现。那么 Namespace 和 Cgroup 是什么呢？刚才我们上面提到了集装箱，集装箱的作用当然是可以对货物进行打包隔离了，不让 A 公司的货跟 B 公司的货混在一起，不然卸货就分不清楚了。那么 Namespace 也是一样的作用，做隔离。光有隔离还没用，我们还需要对货物进行资源的管理。同样的，航运码头也有这样的管理机制：货物用什么样规格大小的集装箱，货物用多少个集装箱，货物哪些优先运走，遇到极端天气怎么暂停运输服务怎么改航道等等… 通用的，与此对应的 Cgroup 就负责资源管理控制作用，比如进程组使用 CPU/MEM 的限制，进程组的优先级控制，进程组的挂起和恢复等等。

2.1.2 什么是容器化

容器是操作系统虚拟化的一种实现途径，负责为应用程序的运行提供环境。容器的目的是为进程集合提供一个独立的运行环境，容器包含应用和其所有的依赖包(类/库)，不同容器之间共享宿主机的硬件资源及操作系统。通过使用容器，开发者可以便利地打包应用程序的代码、配置和依赖关系，从而实现应用程序快速、可靠、一致性部署。

容器的本质是一个视图被隔离，资源受限的进程。容器与虚拟机的相同之处在于都是帮助用户创造了隔离环境，但虚拟机与容器的隔离级别不同。虚拟机在操作系统层面实现隔离，而容器在进程级进行资源隔离；同时容器的大小相比虚拟机更小，这也赋予了其更为轻量、灵活的特征。

2.1.3 容器的特点

• 极其轻量：只打包了必要的 Bin/Lib
• 秒级部署：根据镜像的不同，容器的部署大概在毫秒与秒之间
• 易于移植：一次构建，随处部署
• 弹性伸缩：Kubernetes 等容器管理平台有着非常强大的弹性管理能力

2.1.4 容器底层技术

容器 = Cgroup(资源控制) + Namespace(访问隔离) + rootfs(文件系统隔离) + 容器引擎(用户态工具)。Cgroups 与 Namespace 是容器技术所应用到的两个 Linux 内核的关键特性，Namespace 的主要使用是实现进程的隔离，而 Crgourps 则负责限制分配给进程的硬件资源，由 Namespace + Cgroups 构成的隔离环境也被称为容器运行时；rootfs 作为 Linux 根文件管理系统，主要负责为容器进程提供隔离后执行环境的文件系统，也就是所谓的容器镜像。

容器引擎负责准备运行容器所需要的资源，对容器生命周期进行管理。容器负责与内核 Namespace 和 CGroup 等功能直接交互，并提供相应 API 使得外部能够与之进行集成。容器引擎的功能是对容器生命周期进行管理，包括镜像管理(Image service)、运行管理(runtime service)、容器网络(CNI)等；而上层的容器编排管理系统则会通过 CRI 接口对容器引擎进行调用。目前行业中较为活跃的容器引擎主要包括 Docker、rkt、Pouch、Containerd 和 Cri-o 等。

2.1.5 容器标准化

1. 容器运行时标准(runtime spec)

• creating：使用 create 命令创建容器，这个过程称为创建中
• created：容器创建出来，但是还没有运行，表示镜像和配置没有错误，容器能够运行在当前平台
• running：容器的运行状态，里面的进程处于 up 状态，正在执行用户设定的任务
• stopped：容器运行完成，或者运行出错，或者 stop 命令之后，容器处于暂停状态。这个状态，容器还有很多信息保存在平台中，并没有完全被删除

2. 容器镜像标准(image spec)

• 文件系统：以 layer 保存的文件系统，每个 layer 保存了和上层之间变化的部分，layer 应该保存哪些文件，怎么表示增加、修改和删除的文件等;
• config 文件：保存了文件系统的层级信息，以及容器运行时需要的一些信息，指定了镜像在某个特定平台和系统的配置。
• manifest 文件：镜像的 config 文件索引，有哪些 layer，额外的 annotation 信息，manifest 文件中保存了很多和当前平台有关的信息;
• index 文件：可选的文件，指向不同平台的 manifest 文件，这个文件能保证一个镜像可以跨平台使用，每个平台拥有不同的 manifest 文件，使用 index 作为索引。

2.1.6 容器的上层建筑

容器编排是从容器向容器云跨越的关键。在实际应用的过程中，通常会由大量容器构建成容器集群，以支撑复杂的应用程序体系结构，此时便需要相应的系统对容器集群进行统一的编排、管理、调度。以 Kubernetes 为代表的容器编排管理系统在容器引擎的基础上，为容器化的应用提供部署运行、资源调度、服务发现和动态伸缩等一系列完整功能，提高了大规模容器集群管理的便捷性。从一个开发者和单一的容器镜像，到无数开发者和庞大的容器集群，容器技术实现了从容器到容器云的飞跃。

2.3 虚拟化与容器化对比

2.3.1 优劣

1. 容器的优势在于敏捷和高性能

Hypervisor 架构下，在虚拟服务器上运行单个应用程序意味着需要运行完整操作系统及依赖环境，这为主机增加了大量的系统资源消耗。而容器相比之下占用空间更小，其在底层资源和上层应用之前具有更少的抽象层级，且多个应用程序可通过容器技术共享操作系统内核，进一步提高了资源利用率；同时容器在应用迁移、快速拓展以及持续集成和持续部署实施等方面也更为灵活便捷。

2. 虚拟机的优势在于更强的隔离性和运维的简单性

基于 Hypervisor 的虚拟机可以实现系统层面的资源隔离，虚拟机之间完全独立，安全性高，可用于备份、容灾；而容器实际上仅实现了应用层面的隔离，安全和稳定性相对较低。尤其是在多租户的环节下，由于不同容器共享主机的内核，如果某个容器应用需要配置内核参数，则会导致“牵一发而动全身”。此外，虚拟化技术经过多年应用，已经是企业运维人员较为熟悉的一种技术，同时双层架构也具备运维上更加简单的优势。

2.3.2 区别

虚拟机(virtual machine)是在操作系统中模拟硬件设备，然后运行另一个操作系统，比如在 Windows 系统里面运行 Ubuntu 系统，这样就可以运行任意的 Ubuntu 应用了。而容器仅仅是封装函数库，并没有模拟完整的操作系统。由于“客居”于操作系统，容器只能运行与底层宿主机相同或者相似的操作系统。

2.4 容器化技术

2.4.1 Docker

1. Docker 概述

Docker 是一个开源的应用容器引擎，基于 Go 语言发开，并遵从 Apache 2.0 协议开源。Docker 可以让开发者打包他们的应用以及依赖包到一个轻量级、可移植的容器中，然后发布到任何流行的 Linux 机器上，也可以实现虚拟化。容器是完全使用沙箱机制，相互之间不会有任何接口，更重要的是容器性能开销极低。

Docker 公司在 DockerCon 2017 大会上宣布，决定将软件产品 Docker 和开源项目 Docker 区分开来。Moby Project 项目将作为开源项目的新名称，它包含了一系列公共开源组件，用于组装专门的容器系统。Moby 将由开源社区的开发者共同维护。而 Docker 公司会基于 Moby 构建 Docker CE(社区版) 和 Docker EE(企业版) 等软件产品。

2. Docker 架构

• Client： 客户端；操作 Docker 服务器的客户端(命令行或者界面)
• Docker_Host：Docker 主机；安装 Docker 服务的主机
• Docker_Daemon：后台进程；运行在 Docker 服务器的后台进程
• Containers：容器；在 Docker 服务器中的容器(一个容器一般是一个应用实例，容器间互相隔离)
• Images：镜像；Image 是只读模板，其中包含创建 Docker 容器的说明。容器是由 Image 运行而来。
• Registries：仓库；存储 Docker Image 的地方。

2.4.2 Kubernetes

1. Kubernetes 概述

Kubernetes 是一个轻便的和可扩展的开源平台，用于管理容器化应用和服务。通过 Kubernetes 能够进行应用的自动化部署和扩缩容。在 Kubernetes 中，会将组成应用的容 器组合成一个逻辑单元以更易管理和发现。Kubernetes 积累了作为 Google 生产环境运行 工作负载 15 年的经验，并吸收了来自于社区的最佳想法和实践。在Docker技术的基础上，为容器化的应用提供部署运行、资源调度、服务发现和动态伸缩等一系列完整功能，提高了大规模容器集群管理的便捷性。

2. Kubernetes 架构

• Master 节点

:::tips
K8S 中 Master 是集群控制节点，负责整个集群的管理和控制

:::

- kube-apiserver：提供了 HTTP Rest 接口的关键服务进程，是 K8S 里所有资源的增删改查等操作的唯一入口，也是集群控制的入口进程
- etcd：兼具一致性和高可用性的键值数据库，可以作为保存 K8S 所有集群数据的后台数据库
- kube-scheduler：负责资源调度的进程，通过 API Server 的 Watch 接口监听新建 Pod 副本信息，并通过调度算法为该 Pod 选择一个最合适的 Node
- kube-controller-manager：K8S 里所有资源对象的自动化控制中心，集群内各种资源 Controller 的核心管理者，针对每一种资源都有相应的 Controller，保证其下管理的每个 Controller 所对应的资源始终处于期望状态
- cloud-controller-manager：云控制器管理器使得你可以将你的集群连接到云提供商的 API 之上， 同时可以将云平台交互组件与本地集群中组件分离

• Node 节点

:::tips
Node 是 K8S 集群中的工作负载节点，每个 Node 都会被 Master 分配一些工作负载，当某个 Node 宕机时，其上的工作负载会被 Master 自动转移到其他节点上

:::

- kubelet：负责 Pod 对应的容器的创建、启停等，同时与 Master 密切协作，实现集群管理的基本功能
- kube-proxy：实现 Kubernetes Service 的通信与负载均衡机制的重要组件
- Container Runtime：容器运行时负责创建容器运行环境。支持 containerd、CRI-O、Docker Engine、Mirantis Container Runtime 四种容器运行时。

:::color1
V1.24 之后的 Kubernetes 不再集成 Docker Engine 的一个 dockershim 组件。

:::

• Pod 容器集

Pod 是 K8S 中最小的调度单元，里面包含一组容器，其中一个为 Pause 容器，也称为“根容器”。直接部署一个容器可能会更加容易，每个容器都有不同的配置和功能，K8S 需要对这些容器进行管理，那么为了避免在容器这个实体上增加更多的属性，就产生了 Pod 这个概念。并且，Pod 中的多个业务容器共享 Pause 容器的 IP、端口，共享 Pause 容器挂接的 Volume，这样既简化了密切关联的业务容器的通信问题，也很好的解决了它们之间的文件共享问题。