容器编排工具详解

容器又是什么？我们为什么需要它们？

容器编排到底是什么？

流行的容器编排工具

哪一个适合我？

过去几年里，我们编写、发布和维护软件的方式发生了翻天覆地的变化。我们使用底层基础设施来运行软件的方式也显著成熟，我们见证了从裸机到虚拟机、容器再到微型虚拟机的转变。

微服务的兴起无疑为容器成为企业打包和交付应用程序的主要方式铺平了道路。在这一演变过程中，我们看到 Docker 几乎成为了容器的代名词，而Kubernetes则逐渐成为编排这些容器的黄金标准。这种转变的主要优势包括故障隔离、资源利用率和工作负载扩展，所有这些都对业务产生直接影响。

在本文中，我们将深入探讨容器编排的概念和原理。我们还将介绍一些领先的工具，并进行对比分析，以帮助您选择合适的工具。

我们将讨论以下主题：

• 容器又是什么？我们为什么需要它们？
• 容器编排到底是什么？
• 流行的容器编排工具
  • Kubernetes——黄金标准
  • Docker Swarm
  • 公共云提供商的专有产品
• 哪一个适合我？

容器又是什么？我们为什么需要它们？

过去，我们在裸机（bare metal，也就是本地物理服务器）上运行应用程序。这种做法耗时耗力，成本高昂，而且容易出错，扩展速度也极其缓慢。虚拟机的出现解决了这些痛点——它在物理服务器上添加了一个抽象层，使我们能够在同一台物理服务器上完全隔离地运行多个操作系统，从而提高安全性、资源利用率和可扩展性，并显著降低成本。

太棒了！但如果我们已经解决了虚拟机的上述痛点，那我们为什么还要讨论容器呢？容器更进了一步。你可以把它们想象成微型虚拟机，它们不是打包一个完整的操作系统，而是尝试利用底层主机操作系统进行大多数操作。基于容器的虚拟化可以保证更高的应用程序密度和服务器资源的最大化利用。

虚拟机和容器之间的一个重要区别是，虚拟机虚拟化的是底层硬件，而容器虚拟化的是底层操作系统。两者都有各自的用例。有趣的是，许多容器部署使用虚拟机作为其主机操作系统，而不是直接在裸机上运行。

无论您构建的是整体架构还是基于微服务的架构，如果弹性和快速扩展能力对您来说很重要，那么对于大多数类型的工作负载，在打包应用程序时，容器化是您的最佳选择。

容器编排到底是什么？

虽然容器本身非常有用，但在不同环境中跨多台主机部署、管理和扩展容器却颇具挑战性。容器编排是简化这一过程的另一个绝妙词。让我们进一步剖析它。

容器编排的核心在于管理容器的生命周期。无论您运行的是单体应用还是一堆微服务，容器编排工具都能帮助您简化容器生命周期管理。然而，其真正的实用性在复杂动态的环境中才能真正体现出来。该领域的工具可以帮助团队控制和自动化许多任务，包括：

• 从遇到的故障中恢复，确保您的应用程序具有自我修复、健壮和弹性。
• 根据预定义的配置分配所需资源来提供和调度容器。
• 通过添加或删除容器来扩展服务，通常基于一些指标。
• 监控容器和主机的健康状况。
• 向外界公开服务。
• 无缝地在多个容器之间平衡流量负载。

从用户的角度来看，大多数容器编排工具都遵循类似的机制。它们允许您通过配置文件（通常是 YAML 或 JSON）配置应用程序，这些配置文件会告诉编排工具诸如从哪里获取容器镜像、如何进行网络管理、如何处理存储卷以及将日志推送到哪里等信息。在大多数情况下，软件团队倾向于根据其环境（开发、预发布或生产）对这些配置文件进行版本控制，以确保可审计和可重现。

这些配置文件通过界面（通常是 CLI）传递给工具。然后，该工具会根据配置中定义的约束来安排部署，并选择最佳主机来放置容器。容器启动并运行后，除了查询健康检查外，该工具还会通过将期望状态与实际状态进行匹配来持续监控应用。如果出现任何问题和/或导致故障，它会尝试自动从故障中恢复。能够在从桌面到裸机服务器再到基于云的虚拟机等各种环境中运行这些编排工具，是其一大卖点。

流行的容器编排工具

2013年Docker诞生后，容器技术迅速普及。此后，许多工具应运而生，旨在简化容器管理。虽然这些工具已经存在多年，但许多人认为2017年才是容器工具走向成熟的一年。截至目前，市面上已有多种开源和专有的容器管理解决方案。

在开源领域，Kubernetes、Docker Swarm、Mesos 上的 Apache Marathon 以及 Hashicorp Nomad 都是一些值得关注的参与者。虽然专有领域主要由领先的云提供商主导，但一些值得关注的例子包括亚马逊网络服务 (AWS) 弹性容器服务、谷歌云平台 (GCP) 计算引擎和 Cloud Run、微软 Azure 容器实例以及容器 Web 应用。

让我们放大一些最受欢迎的，将它们相互比较，并尝试更好地了解它们之间的区别。

Kubernetes——黄金标准

与 Docker 成为容器化事实上的标杆类似，业界也发现 Kubernetes 统治着容器编排领域。因此，大多数主流云提供商也开始提供托管 Kubernetes 服务。

它是一款开源软件，已成为在私有云、公有云和混合云环境中编排容器化工作负载的黄金标准。它最初由谷歌工程师开发，他们将多年大规模运行生产工作负载的经验提炼到 Kubernetes 中。它于 2014 年开源，并一直由 CNCF（云原生计算基金会）维护。它通常缩写为 k8s，这是一个数字缩写（以字母“k”开头，以“s”结尾，中间有 8 个其他字符）。

管理大规模容器通常颇具挑战性。为什么呢？因为在笔记本电脑上运行单个 Docker 容器看似微不足道，但以自动化方式在多台主机上运行大量容器并确保零停机时间却并非易事。

让我们以一个类似 Netflix 的视频点播平台为例，该平台由 100 多个微服务组成，在 100 多个大小不一的虚拟机上运行着 5000 多个容器。不同的团队负责不同的微服务。他们遵循持续集成和持续交付 (CI/CD) 驱动的工作流程，每天多次推送到生产环境。生产环境工作负载的期望是始终可用，根据需求变化自动扩展和缩减，并从遇到的故障中恢复。

在这种情况下，容器编排工具的实用性就显得尤为突出。像 Kubernetes 这样的工具，允许你将底层的虚拟机或物理机集群抽象成一个统一的资源块。通常，它们会公开一个 API，你可以使用该 API 指定要为特定应用部署多少个容器，以及它们在负载增加的情况下应该如何运行。这些工具的 API 优先特性，允许你自动化 CI 流水线内的部署流程，使团队能够快速迭代。能够以精简的方式管理这种复杂性，是 Kubernetes 等工具如此受欢迎的主要原因之一。

底层架构和对象

要理解 Kubernetes 的世界观，我们首先需要熟悉集群架构。Kubernetes 集群是一组物理机或虚拟机，分为两个高级组件——控制平面和工作节点。

• 控制平面- 它充当整个集群的大脑，负责接受用户指令、检查所有服务器的健康状态、确定最佳工作负载调度方式以及协调组件之间的通信。其组成部分包括kube-apiserver、etcd、kube-scheduler、kube-controller-manager和cloud-controller-manager等组件。

• 工作节点- 这些机器负责接受来自控制平面的指令并运行容器化工作负载。每台机器都运行 kubelet、kube-proxy 和容器运行时。

现在我们已经对 Kubernetes 架构有了一些了解，接下来的里程碑是理解 Kubernetes 对象模型。Kubernetes 有一些抽象概念，它们构成了任何容器化工作负载的构建块。

我们将介绍 Kubernetes 中您更可能与之交互的几种不同类型的对象：

• Pod - 它是 Kubernetes 层次结构中最小的可部署计算单元。它可以包含一个或多个紧密耦合的容器，共享环境、卷和 IP 空间。通常，不鼓励用户直接管理 Pod。Kubernetes 提供了更高级的对象（deployment、statefulset 和 daemonset）来封装这种管理。
• Deployment - 旨在简化副本 Pod 生命周期管理的高级对象。用户在 Deployment 对象中描述期望状态，部署控制器会根据期望状态更改实际状态。通常，这是用户最常交互的对象。它最适合无状态应用程序。
• 有状态集- 您可以将其视为一种专门的部署，最适合关系数据库等有状态应用程序。它们提供有序性和唯一性保证。
• Daemon Set - 当你希望 Pod 在每个节点（或其子集）上运行时，可以将其视为一种专门的部署方式。它最适合用于集群支持服务，例如日志聚合、安全等。
• 机密和配置映射- 这些对象允许用户分别存储敏感信息和配置。它们可以暴露给某些应用程序，从而实现更简化的配置和机密管理。
• 服务- 此对象将一组 Pod 组合在一起，并使它们能够在集群内通过 DNS 访问。服务类型包括NodePort、ClusterIP和LoadBalancer。
• Ingress - Ingress 对象允许使用 IP 地址或 URL 从外部访问集群中的服务。此外，它还可以提供 SSL 终止和负载均衡
• 命名空间- 此对象用于对集群内的资源进行逻辑分组

注意：为了简单起见，我们故意跳过了其他对象，例如复制控制器、副本集、作业、Cron 作业等。

您可以在此处找到我们关于 Kubernetes 的专门博客文章，其中介绍了示例、功能、生态系统和常见问题。

Docker Swarm——轻量级替代方案

首先，我们来区分一下 Docker 和Docker Swarm。Docker是一个与 rkt 相当的容器运行时。而 Docker Swarm 是一个嵌入在 Docker 引擎中的集群管理和编排工具，与 Kubernetes 等类似工具相当。与 Kubernetes 相比，Docker Swarm 的可扩展性和复杂性略低，最适合那些希望更轻松地部署容器的人。从更高的层面来看，你会发现这两个工具在架构上有很多相似之处。

这里需要注意的是，Mirantis在2019 年底收购 Docker Enterprise 后，宣布未来的主要编排工具将是 Kubernetes。他们将至少支持 Swarm 两年，并致力于简化向 Kubernetes 的过渡。

这是否意味着 Docker Swarm 已经死了，我们甚至不应该再谈论它了？并非如此！到目前为止，这意味着我们将不会再看到许多 Docker Swarm 即服务选项。然而，对于更简单的用例，由于其轻量级和简单的特性，它仍然是一个可行的选择。

底层架构

要理解 Docker Swarm 的世界观，我们首先需要熟悉它的集群架构。Swarm 本身是一组物理机或虚拟机，分为两个高级组件：管理节点和工作节点。

• 管理节点- 类似于 Kubernetes 控制平面，负责接收来自用户的服务定义，并向工作节点发送有关如何运行该服务的指令。此外，它还执行必要的编排和管理功能，以使集群的实际状态与期望状态同步。管理节点会选举一位领导者来执行编排任务。
• 工作节点- 类似于 Kubernetes 的工作节点，它接收并执行从管理节点调度的任务。每个工作节点上运行一个代理，并向管理节点报告分配的任务，以便管理节点能够维护每个工作节点的预期状态。

现在我们对它的架构有了一些了解，让我们深入了解 Docker Swarm 的对象级构造。

• 任务- 任务包含一个 Docker 容器以及容器内运行的命令，它是集群内调度的原子单元。当我们声明服务的期望状态时，​​编排器会通过调度任务来实现该期望状态。如果任务失败，编排器会移除该任务及其容器，然后根据服务指定的期望状态创建一个新任务来替换它。
• 服务- 服务是指在节点上执行的任务。创建服务时，用户需要指定要使用的镜像以及在运行的容器内执行的命令。服务有两种类型：复制服务 (replicated services) 和全局服务 (global services)。与 Kubernetes 部署类似，在复制服务模型中，管理器会在节点之间启动指定数量的副本任务。与 Kubernetes 守护进程集 (daemon set) 类似，对于全局服务，Swarm 会在每个可用节点上为该服务运行一个任务。
• 负载均衡器- Swarm 管理器使用入口负载均衡将服务暴露给外部世界。外部组件（例如云负载均衡器）可以通过其端口访问指定服务，而 Swarm 则使用内部负载均衡在集群内的服务之间分配请求。

公共云提供商的专有产品 - 让我们来处理管理开销

就像在开源领域一样，云编排工具拥有相当激烈的竞争，主要由亚马逊网络服务(AWS)、谷歌云平台(GCP) 和微软 Azure等公共云提供商主导。

这些云提供商也提供 Kubernetes 的托管版本。这意味着提供商负责管理和维护集群的控制平面。这减少了维护和管理的开销。出于本节的目的，我们将忽略这一点，仅关注专有产品。

• AWS 弹性容器服务- AWS ECS是 AWS 提供的完全托管的容器编排服务，它与Route53、Secret Manager、IAM、CloudWatch等其他 AWS 服务深度集成。它提供了两种运行工作负载的方式 - 一种是在EC2 虚拟机上，第二种是较新的Fargate，它为 ECS 带来了无服务器功能。尽管这是 AWS 对如何大规模管理容器的自主创新，但它与 Kubernetes 和 Docker Swarm 有很多相似之处。从用户如何将其应用程序的配置定义为任务定义，然后将这些定义作为 JSON 文档提供给 AWS 控制台或 CLI 界面可以看出这一点。根据配置和您选择的模式（EC2 或 Fargate），ECS 会将组成服务的任务适当地调度到集群上，并不断监控它们以维持所需的状态。
• GCP Cloud Run - Cloud Run 是一个完全托管的无服务器容器编排平台。它通过采用无服务器容器模型，抽象出所有基础设施管理。这意味着您的应用程序可以缩减到零，并且在没有流量时您无需支付任何费用；另一方面，它可以几乎瞬间扩展到数百万个请求。这本质上非常接近 AWS Fargate 的产品。作为 Cloud Run 的消费者，您只需为您的 Docker 容器提供平台，它会处理剩下的事情。这非常方便，因为所有的复杂性都已自动化或抽象出来。在底层，它运行 Knative，这是一个基于 Kubernetes 的平台，用于部署和管理现代无服务器工作负载。这展示了 Kubernetes 真正的超能力——它的可扩展性，如果充分利用，它可以作为构建更适合开发人员的平台的基石。
• Azure 容器实例-容器实例是 Microsoft Azure 以无服务器方式按需运行容器的解决方案。它与 AWS Fargate 和 GCP Cloud Run 相当。由于这种无服务器模型让您无需担心底层基础设施，只需专注于应用程序逻辑，因此可以减少大量管理开销。从用户的角度来看，您只需要一个 Docker 容器并指定必要的配置，平台会为您处理其余工作，包括配置资源、扩展和缩减容器、必要的网络配置以及健康监控等等。

哪一个适合我？

容器编排工具没有万能的解决方案。选择合适的工具很大程度上取决于具体用例。

• 按使用付费，最低管理开销- 如果您想运行具有简单需求的容器化应用程序，并且不想处理任何管理开销，那么最好的选择是使用无服务器容器产品之一，例如 AWS Fargate、Google Cloud Run 或 Azure 容器实例。
• 细粒度控制、灵活性和少量管理- 如果您的需求需要细粒度控制、定制和灵活性，那么AWS EKS、GCP GKE或Azure AKS形式的 Kubernetes 托管版本可能更适合您的用例，因为它们减少了配置和运行 Kubernetes 集群的开销，同时确保了顺畅的云间集成。
• 细粒度控制、在给定约束内的灵活性——如果您的用例具有严格的数据驻留和主权约束，并且您需要在本地或私有云设置中运行容器化工作负载，那么自管理的 Kubernetes 可能是所有容器编排工具中的先驱。