Crossplane是否取代 Terraform？ – 第一部分：理论

探索 Crossplane 和 Terraform 在云原生运维中的对比。了解 API、云服务和控制平面在现代基础设施管理中的作用。

译自 Does Crossplane Replace Terraform? Part I: the Theory，作者 Ian Miell。

如果您还不了解，Crossplane 被宣传为：

基于 Kubernetes 基础构建的开源 CNCF 项目，用于编排任何内容。将策略、权限和其他防护措施封装在自定义 API 行后面，让您的客户能够自助服务，而无需成为基础设施专家。

另一种查看 Crossplane 的方式是将其视为一个工具，它使用商品、开源和受良好支持的控制平面（Kubernetes）来支持创建其他控制平面。

我们在 Container Solutions 已经使用它一段时间了，并且最近一直在讨论我们认为它在未来将变得更加重要：

就像 IBM 收购 Terraform 一样，Crossplane 似乎正在成为我们客户参与的默认选择。

这是出于一些原因，并且有一些警告。

—— Ian Miell (@ianmiell)

最近我一直在观看 Viktor Farcic 关于 Crossplane 的精彩 教程视频。如果您是工程师或感兴趣的架构师，那么这些入门教程非常适合了解该领域的最新动态。

在关注 Viktor 的作品时，我看到了另一个与 Crossplane 相关的视频，其中 Viktor 谈到了我们似乎经常被问到的一个主题：Crossplane 是否取代了 Terraform/Ansible/Chef/$Tool？

这是一个很难简短回答的问题（除了直接说“是”和“否”），因为理解答案需要您掌握 Crossplane 的新颖之处和不同之处，以及它没有的新颖之处和不同之处。从用户角度来看，它们似乎可以做完全相同的事情，这无济于事。

为了找到答案，我想重新表述 Viktor 在该视频中让我感到困惑的一些说法，希望这两部分内容合在一起能够帮助人们理解 Crossplane 在云原生领域中的定位。虽然 Viktor 和我同意 Crossplane 现在和未来所扮演的角色，但我们在定义和解释 Crossplane 的新颖之处以及行业如何走到这一步时确实存在一些分歧。

这篇文章遵循我们的“云原生族谱”的逻辑，该逻辑旨在解释 DevOps 工具的历史。它最近已更新，包括 Crossplane。

在我们开始争论之前，我们可能想问自己两个看似简单的问题：

• 什么是 API？
• 什么是云服务？

还有一个不简单的问题：

• 什么是控制平面？

确切地理解这些问题的答案是定义 Crossplane 的新颖之处和有用之处的关键。

如果您认为自己已经知道这些，或者对哲学不感兴趣，请跳到结尾。

让我们从 AWS 页面的定义开始：

API 是使用一组定义和协议使两个软件组件能够相互通信的机制。

如今，大多数人认为 API 是您可以使用 HTTP 和 JSON 等技术调用的服务集合。但 HTTP 和 JSON（或 YAML 或 XML 等）并不是必需的。在此上下文中，我喜欢向人们解释，古老的 mkdir 命令是一个 API。mkdir 符合以下方式：

• 通过使用来使两个软件组件进行通信 [shell 和 Linux API] 的
• 一组定义 [mkdir 的标准标志] 和
• 协议 [shell 标准输入/输出和退出代码]

几乎所有代码都是调用 API 的东西，直到硬件中发生的事情（根据定义，这不是软件组件）。从技术上讲，代码是“一直都是 API”。但如果它本质上描述了所有代码，那么这不是一个非常有用的定义。

一直都是 API：Linux API 调用 mkdir 以创建文件夹。

有人可能会争辩说 mkdir 不是 API，因为它是由人类使用的，而不是用于“两个软件组件进行通信”。然而，您可以通过 telnet 连接到服务器并手动调用其 API（我过去在调试时经常通过 HTTP 这样做）。此外，mkdir 可以（并且也设计为）在脚本中使用

人们真正希望和期望从 API 中获得的是稳定性。通常，API 在堆栈中的位置越低，它就需要越稳定。自 1978 年问世以来，英特尔 x86 API 几乎没有发生重大更改，甚至延续了 1970 年 Datapoint 2022 终端的特性（例如 8086 的“小端”设计）。同样，Linux 内核 API 自 20 年前（2003 年）发布 版本 2.6 以来也几乎没有发生变化（主要是删除）。

相比之下，Linux CLI 的稳定性要差很多。这是 shell 脚本声名狼藉的主要原因之一。众所周知，很难编写出可以在各种不同机器上运行的 shell 脚本。谁知道我的 shell 脚本中的 ifconfig 命令是否会在你的目标 shell 环境中运行？即使它已安装并在 $PATH 中，而不是具有相同名称的其他命令，它是否具有相同的可用标志？这些标志是否会始终如一地执行相同操作？针对这些挑战防御性地编写代码可能是人们避免编写 shell 脚本的主要原因，此外，你还可以轻松编写出可怕的损坏代码。

这就是 Ansible 等工具诞生的原因。它们抽象了不同配置命令实现的混乱性，并将幂等性概念引入配置管理。与其运行可能成功或失败的 mkdir 命令，在 Ansible 中，你只需声明该文件夹存在。此代码将在你定义的所有主机上创建一个文件夹。

- hosts: all
  tasks:
    - name: Create a folder
      file:
        path: /path/to/your/folder
        state: directory

如果文件夹不存在，Ansible 将通过 ssh 进入其中并创建该文件夹，运行 mkdir 或任何需要运行的内容以使 Linux API 提供等效结果。

Viktor 说 Ansible、Chef 等专注于“除了 API 之外的任何内容”，而我不同意这一点。他们确实专注于 API，但不是基于 http（或“现代”）的 API；他们将各种命令行 API 简化为幂等且（大部分）声明性的形式。就像 mkdir 在 Linux API 前面创建了一个新 API 一样，Ansible 创建了一种使用（或创建你自己的）API 的方法，简化了其他 API 的复杂性。

Terraform：一个开放插件和云优先模型

Terraform 不仅简化了其他 API 的复杂性，还添加了一个丰富且开放的插件框架和一个“云优先”模型（与 Ansible 的“ssh 环境优先”模型相反）。从理论上讲，Ansible 完全可以完成 Terraform 所做的事情，但 Ansible 并不是为基础设施供应而设计的，而 Terraform 则是（正如 Viktor 指出的那样）。

这就引出了第二个问题：如果 Terraform 是“云优先”...

什么是云服务？

许多人认为云服务是大三家超大规模供应商销售的产品。事实上，云服务是三者的结合：

• 远程网络连接
• API
• 将责任委托给第三方

就是这样。这就是云服务的全部内容。

我们已经确定 API（而不是仅仅“运行软件”）是两个软件组件通信的稳定方式。云只是将此放在网络上。最后——也是至关重要的——它将交付结果的责任下放给第三方。

因此，如果我向我的 Linux 桌面（你知道，就在我桌面上）请求更多内存，但它无法提供给我，因为它已经用完，那么解决这个问题是我的责任，因此它不是云服务。

例如，托管服务不是云服务，因为该界面不是网络上的 API。如果我想要一台新服务器，我会给他们发送电子邮件。如果他们添加了 API，他们就变成了云服务。

此表格可能有助于澄清：

项目	远程网络连接	API	代理职责
算盘	否	否	否
Linux 服务器	是	否	否
在桌面 Linux 上使用 mkdir CLI 命令	否	是	否
外包本地服务器	否	否	是
自管理 API 服务	是	是	否
桌面上的 Windows 操作系统	否	是	是
托管服务器	是	否	是
AWS EKS	是	是	是
GitHub	是	是	是

• 算盘是一种简单的计算工具，不使用网络连接，具有界面（移动珠子），但没有 API，如果算盘坏了，那就是你的问题。
• Linux 服务器具有远程网络连接，但没有用于管理的 API。（SSH 和 CLI 可以被视为 API，但肯定不稳定）。
• mkdir 有一个 API（见上文），但从 mkdir 的角度来看，磁盘空间是你的问题。
• 如果你聘请一家公司为你提供自建服务器，那么如果它发生故障（可能），那就是他们的问题，但你通常没有与外包商的 API。
• 如果你构建自己的 API 并自己管理它，那么如果它返回错误，你无法拿起电话来修复它。
• 如果 Windows API 发生故障（并且你支付了支持费用），那么你可以致电 Microsoft 支持，但 Windows API 不需要网络连接即可调用。
• 托管服务器由你提供，没有 API，但如果它没有获得托管支持的电源/带宽/其他任何内容，你可以让他们修复它，并且可以通过网络连接到它。

其中一些可能在细节上存在争议，但可以肯定的是，在上述表格中，只有 EKS 和 GitHub 符合“云服务”的全部三个标准，因此可以被归类为“云服务”。

另一个鲜为人知的概念也必须理解，即“控制平面”。该短语源自网络路由，它将路由器架构划分为三个“平面”：数据平面、控制平面和管理平面。

在网络中，数据平面是处理数据请求的软件部分。相比之下，控制平面是维护路由表并定义如何处理传入数据包的软件部分，而管理平面处理网络堆栈的监控和配置。

你可以将控制平面视为通过路由器的数据的状态管理，而不是系统的常规管理和配置（管理平面）。

这个概念已被其他技术采用，但我还没有找到在网络之外使用控制平面时对其进行正式定义。我认为它可以被视为“管理有用的工作将如何由事物完成”，而不是实际完成工作的事物。如果你认为这不是一个严格的定义，那么我不会反对。

对于 Kubernetes，控制平面是 etcd 数据库和确保你的工作负载被适当地放置和运行的核心控制器。

所有云服务都需要一个控制平面。它们需要一些东西来协调向客户端提供服务。这是因为它们具有远程 API 和责任委派。

好的，现在我们知道以下内容是什么：

• API
• 云服务
• 控制平面

我们可以更清楚地解释 Crossplane 和 Terraform（及其他）之间的关系。

Crossplane 和 Terraform 都处理资源的创建，并且都旨在帮助管理云服务。从这个意义上说，Crossplane 可以替换 Terraform。然而...

...而 Terraform 是“一次性”（你运行它一次，然后就完成了），Crossplane 是持续的。

它的工作部分是配置资源，但这并不是它的唯一工作。它的设计和主要目的是为你提供一个框架，以确保资源保持在“已知状态”，最终从其自己的 Kubernetes 控制平面的配置（或 Git，如果此配置与 Git 存储库同步）中获取其真实来源。

如果你愿意，你可以使用 Terraform 提供程序 在 Crossplane 中运行你的 Terraform 代码。但需要注意的一件事是，你不能仅仅获取现有的 Terraform 代码或其他 shell 脚本，然后在 Crossplane 的控制平面“内”运行它，就像你以前所做的那样。需要做一些工作来集成代码以在 Crossplane 的控制下运行。从这个意义上说，Crossplane 确实取代了 Terraform，将代码纳入其自己的提供程序中。

在某种程度上，Crossplane 与 Chef 和 Puppet 非常接近。这两个工具都有“控制平面”（Chef 和 Puppet 服务器），以确保目标处于一致的状态。然而，Chef 和 Puppet（以及 Ansible）被设计为配置单个计算环境（物理服务器、虚拟机等），而不是将不同的 API 和资源编排和组合成另一个类似云服务的 API。

理论上是这样。实践中呢？我们使用 Crossplane 的经验以及它在现场的实际表现将在第二部分中概述...