深入探究 Kubernetes Schema 验证

为什么要运行架构验证？

如何确保 Kubernetes 集群的稳定性？如何确保清单的语法有效？确保没有任何无效的数据类型？是否缺少任何必填字段？

通常，我们只是在最糟糕的时候才意识到这些错误配置——当尝试部署新的清单时。

专用工具和“左移”方法可以在将 Kubernetes 模式应用于集群之前对其进行验证。在本文中，我将讨论如何避免配置错误以及哪些工具最适合使用。

TL;DR

运行模式验证测试很重要，越早越好。

如果所有机器（本地开发者环境、CI 等）都可以访问您的 Kubernetes 集群，请kubectl --dry-run在每次代码更改时以服务器模式运行。如果无法做到这一点，并且您希望离线执行架构验证测试，请将 kubeconform 与策略执行工具结合使用，以获得最佳的验证覆盖率。

可用工具

验证 Kubernetes 清单的状态看似轻而易举，因为 Kubernetes CLI (kubectl) 能够在资源应用到集群之前对其进行验证。您可以在指定或命令时使用dry-run标志 ( ) 来验证架构，这将在不将 Kubernetes 资源应用到集群的情况下执行验证。--dry-run=client/serverkubectl createkubectl apply

但我可以向您保证，这实际上更加复杂。需要运行 Kubernetes 集群才能获取待验证资源集的架构。因此，在将清单验证纳入 CI 流程时，您还必须管理连接和凭据以执行验证。当在多个环境（生产环境、开发环境等）中处理多个微服务时，这变得更加具有挑战性。

Kubeval和kubeconform是命令行工具，旨在验证 Kubernetes 清单，而无需运行 Kubernetes 环境。由于 kubeconform 的灵感源自 kubeval，因此它们的操作方式类似——验证依据预先生成的 JSON 模式执行，这些模式是根据每个特定 Kubernetes 版本的 OpenAPI 规范 ( swagger.json ) 创建的。要运行模式验证测试，只需将工具可执行文件指向单个清单、目录或模式即可。

比较

• 库贝瓦尔
• kubeconform
• kubectl 在“客户端”模式下进行试运行
• kubectl 在“服务器”模式下进行试运行

现在我们已经介绍了可用于 Kubernetes 模式验证的工具，让我们比较一下一些核心功能（错误配置覆盖、速度测试、不同版本支持、CRD 支持和文档）。

错误配置覆盖范围¹

我戴上 QA 帽子并生成了一些（基本的） Kubernetes 清单文件，其中包含一些故意的错误配置，然后针对所有四个工具²运行它：

结论：在“服务器”模式下运行 kubectl dry-run 可以捕获所有错误配置，而 kubeval/kubeconform 则漏掉了其中两个。有趣的是，在“客户端”模式下运行 kubectl dry-run 几乎毫无用处，因为它漏掉了一些明显的错误配置，而且还需要连接到正在运行的 Kubernetes 环境。

基准速度测试

我使用hyperfine对每个工具⁴的执行时间进行了基准测试。首先，我针对(1)所有配置错误的文件（总共 7 个文件）运行了它；然后我针对(2) 100 个 Kubernetes 文件（所有文件都包含相同的配置）运行了它。

(1)针对具有不同 Kubernetes 模式错误配置的 7 个文件运行工具的结果：

(2)对 100 个具有有效 Kubernetes 模式的文件运行工具的结果：

结论：我们可以看到，虽然kubeconform（#1）、kubeval（#2）和kubectl --dry-run=client（#3）在两个测试中都提供了快速的结果，但kubectl --dry-run=server（#4）的运行速度较慢，特别是当它需要评估 100 个文件时——在我看来，60 秒生成结果仍然是一个很好的结果。

Kubernetes 版本支持

kubeval 和 kubeconform 都接受 Kubernetes 模式版本作为标志。虽然这两个工具类似（如上所述，kubeconfrom 基于 kubeval），但它们之间的一个主要区别在于，每个工具都依赖于一组预先生成的 JSON 模式：

• Kubeval - instrumenta/kubernetes-json-schema （最后提交：2020 年 4 月 29 日 133f848）
• Kubeconform - yannh/kubernetes-json-schema （最后提交：a660f03，2021 年 5 月 15 日）

截至今天（2021 年 5 月），kubeval 仅支持最高 1.18.1 版本的 Kubernetes Schema，而 kubeconform 支持目前最新的 Kubernetes Schema——1.21.0。使用 kubectl 则稍微复杂一些。我不知道 kubectl 的哪个版本引入了 dry-run 功能，但我在 Kubernetes 1.16.0 版本上尝试了一下，仍然有效，所以我知道它在 Kubernetes 1.16.0-1.18.0 版本中可用。

如果您要迁移到新的 Kubernetes 版本，多样化的 Kubernetes Schema 支持尤为重要。您可以使用 kubeval 和 kubeconform 设置版本，并开始评估哪些配置需要更改才能支持集群升级。

结论：kubeconform 拥有所有可用的不同 Kubernetes 版本的所有模式 - 并且不需要 minikube 设置（就像 kubectl 那样） - 这使得它在与其他替代方案进行比较时成为更优秀的工具。

其他需要考虑的事项

自定义资源定义 (CRD) 支持
kubectl dry-run 和 kubeconform 均支持资源类型CRD，而 kubeval 则不支持。根据 kubeval 文档，您可以向 kubeval 传递一个标志以忽略缺失的 schema，这样在测试一堆只有部分资源类型为 CRD 的清单时就不会失败。

文档
Kubeval 比 kubeconform 更受欢迎，因此其社区和文档也更丰富。Kubeconform 没有官方文档，但它有一个写得很好的README文件，很好地解释了它的功能。有趣的是，尽管 Kubernetes 原生工具（例如 kubectl）通常都有详尽的文档，但要找到理解该标志的实际工作原理及其局限性所需的必要信息却非常困难dry-run。

结论：虽然它不如 kubeval 那么出名，但我认为 CRD 支持和足够好的文档使 kubeconform 成为赢家。

比较摘要

现在您已经了解了每种工具的优缺点，下面是如何在 Kubernetes 生产规模开发流程中最好地利用它们的一些最佳实践。

使用这些工具验证 Kubernetes 模式的策略

• ⬅️ 左移：如果可能的话，最好的设置是能够kubectl --dry-run=server在每次代码更改时运行，但你可能无法做到这一点，因为你无法让组织中的每个开发人员或 CI 机器都连接到你的集群。因此，次优方案是运行 kubeconform。
• 🚔 由于 kubeconform 并未涵盖所有常见的错误配置，因此建议在每次代码更改时使用策略执行工具运行它，以填补覆盖范围的空白。
• 💸 购买 vs. 自行构建：如果您喜欢工程开销，那么 kubeconform + conftest是获得良好覆盖率的绝佳工具组合。或者，有些工具可以提供开箱即用的体验，帮助您节省时间和资源，例如Datree ⁵（其架构验证由 kubeconform 提供支持）。
• 🚀 在 CD 步骤中，与集群建立连接应该不是问题，因此您应该始终kubectl --dry-run=server在部署新的代码更改之前运行。
• 👯 另一种在服务器模式下使用 kubectl dry-run 且无需连接到 Kubernetes 环境的方法是运行 minikube + kubectl --dry-run=server。这种方法的缺点是，它还需要像 prod 一样设置 minikube 集群（相同的卷、命名空间等），否则在尝试验证 Kubernetes 清单时会遇到错误。

感激

感谢Yann Hamon创建了 kubeconform——太棒了！
没有您，这篇文章就不可能完成。感谢您的所有指导。

1. 针对 Kubernetes 版本 1.18.0 执行的所有模式验证测试 ↩

2. 由于 kubeconform 基于 kubeval，因此它们提供相同的结果，并针对配置错误的文件运行它们。kubectl 是一种工具，但每种模式（客户端或服务器）都会产生不同的结果，如表中所示 ↩

3. 服务器模式没有将文件标记为有效（退出代码 1），但错误消息是错误的：Kind=pod doesn't support dry-run ↩

4. 所有基准测试均在我的 MacBook Pro 上进行，配备 2.3 GHz 四核 Intel Core i7 处理器 ↩

5. 免责声明 - 此处自我推销 :)  ↩