写点什么

容器编排器生态:Swarm、Kubernetes、Nomad 并非仅有产品,但是最有生命力三个

  • 2022-11-18
    北京
  • 本文字数:5968 字

    阅读完需:约 20 分钟

容器编排器生态:Swarm、Kubernetes、Nomad 并非仅有产品,但是最有生命力三个

尽管复杂,Kubernetes 仍然是目前最流行的编排器,但 HashiCorp 在 Nomad 上的成功也表明,Kubernetes 的替代方案还有发展空间。

 

有些用户仍然热衷于 Docker Swarm 的简单性,但它的未来存在不确定性,其他替代方案看上去已经基本被放弃了。现在的生态似乎主要围绕着 Swarm、Kubernetes 和 Nomad 这三个玩家,但容器编排仍然是一个相对不那么成熟的领域。十年前,这种技术几乎还不存在,现在仍在快速发展。容器编排领域可能还会出现许多令人兴奋的新想法和新发展。

 

本文最初发布于 LWN.net。

 

Docker及其他容器引擎可以从许多方面简化服务端应用程序的部署,但许多应用程序不只包含一个容器。随着部署的应用程序和服务增加,管理一组容器的难度越来越大,一类名为容器编排器的工具由此发展了起来,截至目前最著名的是Kubernetes,容器编排的历史以它为界也分成了前后两段。

 

在享受容器带来的便利的同时,我们也要做好一些权衡取舍。如果一个人严格遵守 Docker“每个服务都应有自己的容器”的理念,那么最终他将运行海量的容器。即使是一个访问数据库的简单 Web 界面也可能需要为数据库服务器和应用程序运行单独的容器,它可能还包括一个单独的 Web 服务器容器用于提供静态文件服务、一个单独的代理服务器容器用于终止 SSL/TLS 连接、一个键/值存储容器充当缓存,或者一个辅助应用程序容器用于处理后台作业及计划任务。

 

一位管理员如果负责了数个这样的系统,很快就会发现需要一个工具来简化自己的工作,这就是容器编排器的用途所在了。

 

容器编排器是一个工具,它可以将一组容器当成一个单元来管理。编排器让你可以将多台服务器合并成一个集群,并自动在集群节点之间分配容器工作负载,而不是单独在一台服务器操作。


Docker Compose 和 Swarm

 

Docker Compose 称不上是一个不完全的编排器,但这是 Docker 第一次尝试创建一个工具来简化多容器应用程序的管理。Compose 读取一个 YAML 文件,通常命名为 docker-compose.yml,并使用 Docker API 创建文件中声明的资源;Compose 还会为所有资源添加标签,以便在创建完成后把它们当成一个组来管理。实际上,它是 Docker 命令行接口(CLI,可操作容器组)的一个替代方案。Compose 文件可以定义三类资源:

 

  • 服务(services):声明要启动的容器,其中每一条都相当于一个 docker run 命令。

  • 网络(networks):声明可以附加到容器(Compose 文件中定义的)的网络,其中每一条相当于一个 docker network create 命令。

  • 卷(volumes): 定义可以附加到容器的命名卷。在 Docker 术语中,卷是可以挂在到容器的持久存储。命名卷由 Docker daemon 管理。其中每一条相当于一个 docker volume create 命令。

 

网络和卷可以直接连接到 Docker 所在主机的网络和文件系统,也可以通过插件提供。网络插件可以帮我们实现像将容器连接到 VPN 这样的事情;卷插件可以帮我们将卷存储在一台 NFS 服务器或一个对象存储服务上。

 

在管理多容器应用程序方面,Compose 提供了一种方便许多的方式,但在最初的版本中,它只能工作在单台主机上,创建的所有容器也运行在相同的机器上。为了让它能够覆盖多台主机,Docker 在 2016 年推出了 Swarm mode。实际上,这是 Docker 第二个带有“Swarm”字样的产品——2014 年的一款产品实现了一种完全不同的、跨多台主机运行容器的方式,但 Docker 已经不再维护,它被 SwarmKit 所取代,后者是 Docker Swarm 当前版本的基础。

 

Swarm mode 包含在 Docker 中,无需安装其他软件。创建集群很简单,只需在初始节点上运行 docker swarm init,然后在每个要添加的节点上运行 docker swarm join。Swarm 集群包含两种类型的节点。管理节点提供了一个 API,用于启动集群中的容器,并使用基于Raft一致性算法的协议互相通信,在所有管理节点间同步集群状态。工作节点完成运行容器的具体工作。这些集群可以到多大我们并不是很确定,Docker 的文档说一个集群的管理节点不应超过 7 个,但并没有说明工作节点的数量限制。跨节点桥接容器网络功能是自带的,但跨节点共享存储不是,需要借助第三方卷插件来提供跨节点的共享持久存储。

 

服务使用 Compose 文件部署到 Swarm 上。Swarm 扩展了 Compose 模式,为每个服务添加了一个 deploy 键,用于指定该服务应该运行多少实例以及应该在哪些节点上运行。遗憾的是,这导致了 Compose 和 Swarm 的分化,进而导致了一些混乱,因为对于像 CPU 和内存配额这样的选项,它们提供了不同的指定方式。

 

在这段时期内,为了避免歧义,用于 Swarm 的文件被称作“栈文件”,而不是 Compose 文件;所幸,在 Swarm 和 Compose 的当前版本中,这些差异似乎已经被抹平。如果引用的栈文件和 Compose 文件截然不同,那多半是从网上搜来的。现在,Compose 格式已经有了一个开放的规范,并且它自己的 GitHub 社区也提供了参考实现。

 

Swarm 的未来还存在一定的不确定性。它曾是 Docker Cloud 服务的基础,但该服务2018年突然关闭了;它也曾被认为是 Docker 企业版的关键特性,但那个产品自此卖给了另外一家公司,它现在的名称为 Mirantis Kubernetes Engine。与此同时,Compose 的最新版本已经具备向亚马逊和微软托管服务部署容器的能力。一直没有弃用声明,但记忆中也没有任何其他类型的公告。在 Docker 的网站上搜索“Swarm”这个词,也只能够搜到过去一些曾提及它的信息。

 

Kubernetes

 

Kubernetes (有时候称为 k8s)项目的灵感来自谷歌内部的一个工具Borg。Kubernetes 可以在多达数千个节点的集群上管理资源并协调工作负载的运行;它在容器编排领域的统治地位就像谷歌在搜索领域的地位一样。2014 年,谷歌希望与 Docker 合作开发 Kubernetes,但 Docker 决定走自己的路,继续开发 Swarm。然而,Kubernetes 在云原生计算基金会(CNCF)的主持下发展壮大。截至 2017 年,Kubernetes 已经变得如此流行,以至于 Docker 也宣布将其集成到自己的产品中。

 

除了受欢迎之外,Kubernetes 主要以其复杂性而闻名。手动配置一个新集群是一项非常复杂的任务,除了 Kubernetes 之外,管理员还需要选择并配置多个第三方组件。和 Linux 内核需要结合额外的软件形成完整的操作系统一样,Kubernetes 只是一个编排器,它需要结合其他的软件才能组成一个完整的集群。它需要一个容器引擎来运行容器;它还需要网络插件以及持久卷插件。

 

Kubernetes发行版的存在填补了这一空白。和 Linux 发行版一样,Kubernetes 发行版也将 Kubernetes 与安装程序以及精心挑选的第三方组件捆绑在一起。不同发行版的存在是为了满足不同的细分市场;似乎每个具有一定规模的公司都有自己的发行版和/或托管服务,以迎合企业的需求。minikube 项目让开发人员可以轻松地在本地搭建一个试验环境。和 Linux 发行版不同,Kubernetes 发行版经过了 CNCF 的一致性认证;为了得到认证,每个发行版都必须实现基本的功能,这样它们才能使用“Certified Kubernetes”标识。

 

一个 Kubernetes 集群包含多个软件组件。集群中的每个节点都运行着一个名为 kubelet 的代理,用于维护集群的成员关系并从它接收工作。它还运行着一个容器引擎和 kube-proxy,后者负责与在其他节点上运行的容器进行网络通信。

 

维护集群状态的组件以及决定资源分配的组件合称为控制平面——这包括一个名为etcd的分布式键值存储,一个给集群节点分配工作的调度器,一个或多个响应集群状态变化的控制器进程,负责触发所需的操作,使集群的状态符合预期。用户和集群节点通过 Kubernetes API Server 与控制平面交互。要实现修改,用户会通过 API Server 设定期望的集群状态,而 kubelet 会向控制器进程报告每个集群节点的实际状态。

 

Kubernetes 在一个名为 pod 的抽象中运行容器,其中可以包含一个或多个容器,不过,并不建议在一个 pod 中运行多个服务的容器。相反,一个 pod 通常只有一个提供服务的主容器,可能会有一个或多个“边”容器负责从运行服务的主容器中收集指标或日志。一个 pod 中的所有容器都将调度到同一台机器上,共享同一个网络命名空间——在同一 pod 中运行的容器可以通过 loopback 接口相互通信。每个 pod 在集群中都有自己独一无二的 IP 地址。运行在不同 pod 中的容器可以使用它们的集群 IP 地址相互通信。

 

Pod 指定一组要运行的容器,但 pod 的定义并没有说明在哪里运行这些容器,或者是运行多长时间——没有这些信息,Kubernetes 就会在集群上的随便什么地方启动容器,但不会在它们退出时重启,而且,如果控制平面判断其他工作负载需要它们占用的资源,Kubernetes 可能会终止它们。为此,pod 很少单独使用;取而代之,pod 的定义通常是封装在用于定义持久服务的 Deployment 对象中。和 Compose 及 Swarm 一样,由 Kubernetes 管理的对象是在 YAML 中声明的;对于 Kubernetes,YAML 声明是通过 kubectl 工具提交到集群的。

 

除了 pod 和 Deployment 之外,Kubernetes 还可以管理许多其他类型的对象,如负载均衡器和授权策略。它支持的 API 清单还在不断增长,根据 Kubernetes 的版本以及集群运行的哪个发行版会有所不同。自定义资源可以用于向集群添加 API,用于管理额外的对象类型。例如,KubeVirt添加的 API 使 Kubernetes 可以运行虚拟机。可以通过kubectl api-versions命令查看特定集群支持的完整 API 清单。

 

和 Compose 不同,这些对象中的每一种都是在单独的 YAML 文档中声明的,虽然多个 YAML 文档可以内联到一个文件中,并用“---”隔开(参加Kubernetes文档)。一个复杂的应用程序可能包含许多对象,它们的定义分散在多个文件中;在维护这样一个应用程序时,保持所有这些定义彼此同步会非常繁琐。为了简化这项工作,有些 Kubernetes 管理员转而采用像Jsonnet这样的模板工具。

 

Helm让模板工具更上一层楼。和 Kubernetes 类似,Helm 也是在 CNCF 的主持下开发的;它号称是“Kubernetes 包管理器”。Helm 从一套名为 chart 的模板和变量声明生成 Kubernetes 的 YAML 配置。它使用的模板语言不同于 Ansible 使用的Jinja模板,但看上去非常相似;熟悉Ansible Roles的人看到 Helm Charts 也会感觉很熟悉。

 

Helm Charts 集可以发布到Helm存储库Artifact Hub提供了一个很大的公共 Helm 存储库目录。管理员可以将这些存储库添加到他们的 Helm 配置中,使用已经编制好的 Heml chart 将流行应用的预打包版本部署到集群上。Helm 的最新版本还支持向容器注册中心推送或从注册中心拉取 chart,为管理员提供了一个选型,让他们可以将 chart 和容器镜像存储在一起。

 

Kubernetes 的增长势头还没有任何减缓的趋势。按照设计,它可以管理任何类型的资源;这种灵活性(已为 KubeVirt 虚拟机控制器所证明)使得,即使容器化工作负载最终不再流行,Kubernetes 仍然有继续存在的价值。开发有序进行,新的主版本定期发布。版本支持周期为 1 年;似乎没有长期支持版本。集群可以升级,但有人喜欢新建一个集群,并将服务迁移过去。

 

Nomad

 

Nomad是 HashiCorp 推出的一个编排器,号称是一个比 Kubernetes 更简单的替代方案。和 Docker 及 Kubernetes 类似,Nomad 是一个开源项目。它包含一个名为 nomad 的二进制文件,可以用于启动一个名为代理的守护进程。它还提供了一个 CLI,用于和代理通信。根据配置方式不同,代理进程可以在两种模式下运行。在服务器模式下运行的代理可以接受作业,并为它们分配集群资源。在客户端模式下运行的代理会接收作业,运行它们,并将作业状态报告给服务器。代理还可以在开发模式下运行,同时承担客户端和服务器的角色,成为一个用于测试目的的单节点集群。

 

创建 Nomad 集群相当简单。在 Nomad 最基本的操作模式中,必须启动初始服务器代理,然后使用 nomad server join 命令向集群添加额外的节点。HashiCorp 还提供了 Consul,这是一个通用的服务网格和发现工具。虽然 Nomad 可以单独使用,但最好是和 Consul 搭配使用。Nomad 代理可以使用 Consul 自动发现并加入一个集群,它还可以执行健康检查,提供 DNS 记录,并为集群上运行的服务提供 HTTPS 代理。

 

Nomad 支持复杂的集群拓扑。每个集群被划分成一个或多个“数据中心”。和 Swarm 类似,同一数据中心中的服务器代理使用一种基于 Raft 的协议相互通信;这种协议有严格的延迟要求,但多个数据中心可以用 gossip 协议连接起来,从而使信息可以在集群中传播,而又不需要每个服务器与其他服务器保持直接连接。从用户的角度来看,以这种方式连接起来的数据中心就和一个集群一样。这种架构让 Nomad 在扩展到大量集群时颇有优势。按照官方说法,Kubernetes 最多支持 5000 个节点和 3 万个容器,而 Nomad 的文档中提到了一个有 1 万多节点的集群示例和一个有 20 万容器的集群示例。

 

和 Kubernetes 类似,Nomad 并没有包含一个容器引擎或运行时,它使用任务驱动器来运行作业。它包含使用 Docker 和 Podman 来运行容器的任务驱动器;社区提供了面向其他容器引擎的驱动器。Nomad 的野心也不限于容器,这点也和 Kubernetes 类似。它还提供了面向其他工作负载类型的任务驱动器,包括在主机上运行命令的 fork/exec 驱动器,运行虚拟机的 QEMU 驱动器,启动 Java 应用程序的 Java 驱动器。社区支持的任务驱动器可以将 Nomad 连接到其他类型的工作负载。

 

与 Docker 或 Kubernetes 不同,Nomad 不使用 YAML,而是使用HashiCorp配置语言(HCL)。HCL 最初是为 HashiCorp 的另一个项目创建的,用于配置名为Terraform的云资源。虽然在其他地方的应用有限,但 HashiCorp 的整个产品线都在使用 HCL。用 HCL 编写的文档很容易转换成 JSON,但它的目标是提供一种比 JSON 更便捷、比 YAML 更不容易出错的语法。

 

HashiCorp 提供的相当于 Helm 的产品是 Nomad Pack。和 Helm 类似,Nomad Pack 会处理一个满是模板和变量声明的目录,生成作业配置。Nomad 还有一个预打包应用程序的社区注册中心,但其选择空间比 Helm 的 Artifact Hub 要小很多

 

Nomad 不像 Kubernetes 那么受欢迎。和 Swarm 一样,它的开发似乎主要是由其创建者推动的;尽管有许多大公司部署了 HashiCorp,但 HashiCorp 仍然是 Nomad 相关社区的中心。目前看来,该项目似乎不太可能获得足够的发展势头,进而从母公司独立出来。对用户来说,与 Docker 在 Swarm 上做的工作相比,HashiCorp 对 Nomad 的开发和推广或许更有保证。

小结

 

Swarm、Kubernetes 和 Nomad 并不是仅有的容器编排器,但它们是其中最有生命力的三个。Apache Mesos也可以用来运行容器,但它在 2021 年就几乎被封存了;DC/OS基于 Mesos,但很像 Docker 企业版,支持其开发的公司现在也专注于 Kubernetes。其他大多数容器编排项目,如 OpenShift 和 Rancher,实际上只是增强(和认证)的 Kubernetes 发行版,即使它们的名字中没有 Kubernetes。

 

尽管 Kubernetes 非常复杂,它仍然是目前最流行的编排器,但 HashiCorp 在 Nomad 上的成功表明,替代方案也还有它的发展空间。有些用户仍然热衷于 Docker Swarm 的简单性,但它的未来存在不确定性。至此,其他替代方案看上去已经基本被放弃了。现在的生态似乎主要围绕着这三个玩家,但容器编排仍然是一个相对不那么成熟的领域。十年前,这种技术几乎还不存在,而它现在仍在快速发展。容器编排领域可能还会出现许多令人兴奋的新想法和新发展。

 

原文链接:

The container orchestrator landscape

2022-11-18 07:002503

评论

发布
暂无评论
发现更多内容

Android Camera开发系列:设置对焦模式模式

小驰笔记

Camera; Android;

Ansible 命令行工具

耳东@Erdong

4月日更

阿里开发7年大牛:只需一篇文章吃透Android多线程技术,好文推荐

欢喜学安卓

android 程序员 面试 移动开发

泉州有了一个水务大脑,用AI守护“绿水青山”

百度大脑

AI

对话亚马逊云科技 WWSO 团队四位大咖,给你讲讲他们的职场故事~

亚马逊云科技 (Amazon Web Services)

连续三年入围 Gartner 容器竞争格局,阿里云容器服务新布局首次公开

阿里巴巴中间件

websocket简析

六维

websocket 4月日更

中国脑科学的十年行旅

脑极体

自从有了他,再也没有担心过环境部署~

MY

部署与维护

免费开源增强版 Elasticsearch 分支 OpenSearch 项目上线!现邀您加入开源社区!

亚马逊云科技 (Amazon Web Services)

不要给自己留后路

小天同学

人生 个人感悟 成功 4月日更

Oracle LogMiner 数据迁移实战

yintianwen

Java 数据库 后端 数据迁移 LogMiner

算法题目解析:从一道题目看动态规划

程序员架构进阶

算法 动态规划 28天写作 4月日更

NumPy之:数据类型

程序那些事

Python 数据分析 Numpy 程序那些事

聪明人的训练(二十三)

Changing Lin

4月日更

王霸雄图荣华敝屣,谈笑间尽归尘土|基于Python3双队列数据结构搭建股票/外汇交易匹配撮合系统

刘悦的技术博客

数据结构 算法 Python3 匹配 股票系统

Flutter Slidable 列表侧滑菜单 列表侧滑删除

早起的年轻人

flutter

10 亿数据量只需要 100MB 内存,Redis 的位存储为什么这么牛?

Java小咖秀

redis 原理 位运算 bit 高级特性

【论文分享】Presto: SQL on Everything(一)

小舰

4月日更

Python OOP-1

若尘

面向对象 oop 面向对象编程 Python编程

一个码砖的码农,在InfoQ写一年博客,出书了?

小傅哥

Java 设计模式 小傅哥 架构设计 码农出书

LeetCode题解:641. 设计循环双端队列,使用数组,JavaScript,详细注释

Lee Chen

算法 大前端 LeetCode

重读《重构2》- 搬移函数

顿晓

重构 4月日更

你不一定全知道的四种Python装饰器实现详解

老猿Python

Python 编程语言 装饰器 程序开发

流程引擎介绍

上海派拉基础研发

流程

悟透前端:JavaScript ES6模块的导入导出

devpoint

ES6 export export default

什么情况下要招人?

石云升

团队建设 28天写作 职场经验 管理经验 4月日更

网络协议学习笔记Day1

穿过生命散发芬芳

网络协议 4月日更

架构训练营——作业 2

架构实战营

rrxjava原理,手持4个大厂offer的我,吊打面试官系列!

欢喜学安卓

android 程序员 面试 移动开发

Ask Me Anything #1 我是新晋CNCF TOC张磊,你有什么想问我的?

阿里巴巴云原生

容器 开发者 运维 云原生 k8s

容器编排器生态:Swarm、Kubernetes、Nomad 并非仅有产品,但是最有生命力三个_语言 & 开发_Jordan Webb_InfoQ精选文章