容器虚拟化
- 13 分钟
使用 Zen 和 Hyper-V 等虚拟机监控程序的虚拟化会将物理服务器分区为多个虚拟服务器，并隔离在各虚拟服务器中运行的工作负载。 但是 VM 并非没有缺点：
资源要求：VM 需要大量 RAM。 如果 Windows 服务器承载 10 个 Windows VM，则 Windows 将会加载到内存中 11 次 - 服务器本身一个副本，每个虚拟机一个副本。 VM 无法共享操作系统的单个内存中实例，因为虚拟化的目标是创建与物理服务器具有相同作用的虚拟服务器。 与两台物理服务器一样，两个 VM 也不能共享一个操作系统。 无论操作系统是 Windows、Linux 还是其他操作系统（例如 macOS），都是如此。
可移植性：VM 映像往往很大（通常为数十或数百 GB），部分原因是它们也存储了操作系统的完整副本。 这会限制它们的可移植性。 即使连接比较缓慢，也可以轻松将 1 MB 的映像从一台计算机移动到另一台计算机。 相比之下，使用典型的网络连接很难移动 200 GB 的 VM 映像。 它可能需要借助诸如 U 盘或硬盘之类的物理介质进行移动，但如果在云计算方案中你无权访问数据中心的物理服务器，这就会带来逻辑方面的挑战。
启动时间：启动 VM 与启动物理计算机类似。 必须启动和初始化虚拟化硬件、必须加载和初始化操作系统、必须加载设备驱动程序并将其连接到虚拟化硬件等等。因此，创建虚拟机后，启动虚拟机可能需要一分钟或更长时间。 虽然几分钟的启动时间与采购、安装和配置物理服务器所需的时间相比微乎其微，但在动态创建 VM 以满足不断增长的需求或不断创建和销毁 VM 以满足不断变化的工作负载时，这是一个重要的限制。
这些只是容器在云计算以及本地数据中心和个人计算机中得到广泛采用的部分原因。 在本课程中，我们将讨论容器的涵义、其工作原理以及所提供的优势。 我们还将介绍世界上最受欢迎的容器化平台 Docker，以及将其集成到常用的云平台中的一些方法。
什么是容器？
容器彻底改变了 IT 和软件的开发。 它们允许将软件和文件打包成独立的包（称为“容器映像”），这些包可在不同计算机（真实计算机或虚拟机）上运行，并且以一致且可预测的方式执行此操作。 以下描述引自 Docker 网站：
容器是一个标准的软件单元，它将代码及其所有依赖项打包，从而使应用程序能够快速、可靠地从一个计算环境运行到另一个计算环境。 Docker 容器映像是轻型、独立的可执行软件包，其中包括运行应用程序所需的一切内容：代码、运行时、系统工具、系统库和设置。
虚拟机监控程序虚拟化硬件，而容器虚拟化操作系统。 图 7 说明了 VM 和容器1之间的主要区别。 在左侧，服务器承载了一个操作系统副本和一个 Docker 运行时副本。 它还在六个容器中承载了六个应用程序，每个容器都使用主机的操作系统。 在右侧，同一服务器承载了三个 VM，每个 VM 都加载了自己的操作系统副本。 由于容器的资源需求较小，因此给定的服务器通常可以承载比 VM 多几倍的容器。
图 7：容器与虚拟机。
容器与虚拟机相似，因为它们都提供了可以在其中运行软件的可预测且隔离的环境。 但是，因为容器比 VM 小，所以它们需要的 RAM 更少，并且更容易在计算机之间移动。 此外，它们还可以更快地启动（通常只需一两秒钟），因为它们既不必虚拟化硬件，也不必加载和初始化操作系统。 即使容器本身完全不同（包含不同的软件且创建自不同的容器映像），在同一台计算机上运行的多个容器也共享相同的操作系统内核。
容器和虚拟机并不互斥。 实际上，它们经常一起使用。 如果 Windows 用户运行在 Linux 容器中打包的软件，则可在 VM 中运行 Linux，并在 VM 中承载 Docker 和容器化软件。 在云中，容器与其他云工作负载一样承载在 VM 中。
容器并不能替代虚拟机，它们两者也不应被视为功能相等。 与虚拟机不同，容器不允许在同一计算机上并行运行多个操作系统。 例如，如果主机运行 Linux，则该计算机上的所有容器也必须使用 Linux。 （Windows 用户经常在 Windows 上运行 Linux 容器，但这是可行的，因为 Docker 在 Windows 计算机上运行 Linux VM 并在 VM 中托管容器。）此外，由于容器不会对硬件进行虚拟化，因此不适用于执行涉及直接硬件交互的系统级任务的应用程序。 一种简单的思路是，虚拟机监控程序对整个计算机（包括其硬件）进行虚拟化，而容器对软件进行虚拟化并使用主机的操作系统作为操作系统平台。
Docker
Docker 无疑是最常用的容器平台。 该平台不仅是免费的，而且还是开放源代码的，并且可以在所有主要的 Linux 分发版以及 Windows Server 2016 上运行。 2015 年，Docker 向开放容器计划 (OCI) 捐赠了容器映像规范和运行时代码，以帮助规范和发展容器生态系统。 2017 年，Docker 向 Cloud Native Computing Foundation (CNCF) 捐赠了行业标准的容器运行时。 该运行时的创建重点在于简单性、可靠性和可移植性。
图 8 显示了一种可在 Docker 容器中运行应用程序的系统体系结构。 图中首先展示 Docker 客户端工具，该工具用于创建、运行和管理容器和容器映像。 （容器映像构成运行的容器的蓝图，而 VM 映像定义加载到运行的 VM 中的内容。）存在各种 Docker 客户端，包括 Docker 自己的命令行接口（可在所有常用的操作系统上运行）和 Kitematic（具有图形用户界面并可在 Windows 和 macOS 上运行）。 Docker 于 2015 年收购了 Kitematic，并使其成为 Docker Toolbox 的一部分，可供免费使用。
图 8：Docker 体系结构。
容器映像构建完毕之后将被上传到容器注册表中的存储库。 容器注册表的目的是存储容器映像，使其可供公开或私下使用。 Docker 提供了自己的基于云的容器注册表（称为“Docker Hub”），可为用户提供无限的免费公用存储库和一个免费的专用存储库。 它还允许（甚至鼓励）其他人创建自己的注册表，并提供开放源代码 Docker 注册表来帮助他们的工作。 这就是 Amazon、Microsoft 和 Google 等主要云服务提供商能够在其云平台中提供 Docker 兼容的注册表的原因之一。
通过使用 Docker 客户端向 Docker 守护程序发出命令并指定应从哪个映像创建容器来启动容器。 （守护程序是在主机的后台运行的程序。）然后，守护程序会创建一个容器并将该映像加载到其中。 运行后，可以通过从 Docker 客户端发出命令来启动和停止容器。 Docker 客户端和 Docker 守护程序不必位于同一计算机上。 在典型方案中，客户端在一台计算机上运行，而守护程序在远程服务器上运行，并且客户端使用安全外壳 (SSH) 协议将命令传输到守护程序。
云计算中的容器服务
虽然用户可以通过创建 VM 并在其中安装 Docker 运行时来对容器自由地采用 IaaS 方法，但云服务提供商考虑到容器的重要性，提供了 PaaS 服务来支持在云中运行容器化应用程序。 Azure 提供了 Azure 容器实例和 Azure 容器注册表，前者可提供可靠、可缩放且易于使用的环境来承载容器化的应用程序，后者允许在 Azure 而非 Docker Hub 或其他外部注册表中承载容器映像，并快速将其加载到 Azure 容器实例中。 Amazon 提供了 AWS 弹性容器注册表 (ECR) 和 AWS 弹性容器服务 (ECS)，而 Google 在 Compute Engine 上提供了容器注册表和容器。
图 9 说明了 Amazon 的 ECR 和 ECS 如何协同工作以提供基于云的 Docker 堆栈来承载容器和容器映像2。 容器映像构建完毕之后将被上传到 ECR，ECR 是类似于 Docker Hub 的与 Docker 兼容的容器注册表。 （在 AWS 中运行的容器映像不必存储在 ECR 中，但将其存储在其中具有多种优势，包括使用 AWS 标识进行的精细访问控制、自动加密、对容器映像版本控制的支持以及更快的加载速度，尤其是在同一数据中心存储和运行容器映像的情况下。）该图显示，映像加载到 ECS 或其他云服务托管的容器中。
图 9：AWS 中的容器。
Azure 容器注册表和 Azure 容器实例的工作方式几乎相同，但前者使用 Microsoft Entra 而非 AWS 标识来控制对容器映像的访问。 AWS 和 Azure 中的容器支持的一个区别在于，AWS 结合使用开放源代码软件和专有技术，而 Azure 的容器堆栈 100% 由开放源代码生成。 因此，任何适用于 Docker 的工具也适用于 Azure。 此外，Azure Cloud Shell 和 Azure CLI 还提供了用于构建和管理 Docker 容器映像的命令。 这些命令并不能完全消除对 Docker 客户端的需求，但它们确实涵盖了最常见的用例，并且针对 Azure 进行了优化。
最近，云服务提供商已开始为所选的 PaaS 服务添加容器支持。 例如，Azure 提供了用于容器的 Azure Web 应用，它本质上是 Azure 应用服务，具有从容器映像加载软件的附加功能。 Amazon 采取了类似的步骤，将 Docker 容器与 Elastic Beanstalk 集成。
容器业务流程
Docker 提供了用于构建和运行容器的基础结构，但是需要更高级别的监督来协调容器的操作，并以与缩放 VM 相同的方式来缩放容器化的工作负载。 尽管存在各种各样的容器业务流程工具，但该行业在很大程度上还是选择了源自 Google 的开放源代码项目的 Kubernetes 作为业务流程协调程序。 如今，主要的云服务提供商提供了 Kubernetes 的托管实现，从而可以更轻松地在其平台上运行容器和使用 Kubernetes 管理容器。 图 9 中的“EKS”代表 Elastic Kubernetes 服务。 Azure 提供了称为“Azure Kubernetes 服务 (AKS)”的补充服务，而 Google Cloud Platform 提供了 Kubernetes 引擎。
引用
- Docker （2019）。 什么是容器？https://www.docker.com/resources/what-container
Amazon (2019). Amazon ECS 的工作原理。 https://aws.amazon.com/ecs/。