主机频道
摘要：In 和 Out 二进制文件继续支持与 In 相同的供应商程序。 但是，二进制文件应该可用且完全独立，因为这可以简化发布和执行。 测试存档中分发的二进制文件可以测试已安装的存储驱动程序，而无需重建测试套件。
作者：Patrick Ohly（英特尔）
曾经属于 Kubernetes 一部分的组件现在越来越多地在 Kubernetes 之外开发。 例如，曾经编译为 Kubernetes 二进制文件，然后移动到主机上的独立 Flexvolume 二进制文件的存储驱动程序现在作为部署在 Kubernetes Pod 集群中的容器存储接口 (CSI) 驱动程序提供。
这对于使用此类组件的开发人员来说是一个挑战。 如何在此类外部组件上对 Kubernetes 集群执行端到端 (E2E) 测试？用于测试 Kubernetes 的 E2E 框架本身提供了所有必要的功能。 然而，尝试在 Kubernetes 之外使用它是很困难的，只能通过仔细选择多个依赖项的正确版本来实现。 Kubernetes 1.13 让端到端测试变得更加容易。
这篇博文总结了 Kubernetes 1.13 中的变化。 对于 CSI 驱动程序开发人员，介绍如何使存储测试可用于测试第三方 CSI 驱动程序。 这些用法是基于两个 Intel CSI 驱动程序进行演示的。
开放基础设施管理器 (OIM)
PMEM-CSI
这些驱动程序的测试包括： 这是大多数增强功能的主要动机。
E2E概述
E2E测试由几个阶段组成：
测试套件实施。 这是这篇博文的主要焦点。 Kubernetes E2E框架是用Go编写的。 依靠 Ginkgo 来管理测试和断言（声明）这取决于Gomega。 这些工具支持“行为驱动的开发”，其中预期行为在“规范”中描述。 在这篇博文中，“测试”用于指代单独的 Ginkgo.It 规范。 测试使用 client-go 与 Kubernetes 集群交互。
启动测试集群。 像 kubetest 这样的工具可以提供帮助。
针对您的集群运行 E2E 测试套件。 Ginkgo 测试套件可以使用 ginkgo 工具运行，或者对于常规 Go 测试，使用 go test 运行。 如果不指定任何参数，Kubernetes E2E测试套件会根据环境变量（如KUBECONFIG）连接到默认集群，就像kubectl一样。 Kubetest 还知道如何运行 Kubernetes E2E 套件。
Kubernetes 1.13 中的 E2E 框架增强
以下增强功能均遵循相同的基本模式。 这些增强功能使 E2E 框架在 Kubernetes 之外更有用、更容易使用，而无需改变 Kubernetes 的行为。 原始 Kubernetes e2e.test 二进制文件。
拆分提供商支持
E2E 框架难以与 Kubernetes <= 1.12 一起使用的主要原因是它们依赖于使用大量软件包的特定于提供商的 SDK。我在做什么。 它不再只是编译那么简单。
其中许多包仅用于特定测试。 例如，要测试预配置卷的安装，您必须首先通过非 Kubernetes API 直接与特定存储后端通信，并以与管理员相同的方式配置此类卷。
目前正在尝试从核心 Kubernetes 中删除特定于云供应商的测试。 PR#68483 中采取的方法可以被视为朝着这一目标迈出的一步。 所有特定于云供应商的代码都将移动到 test/e2e/framework，而不是立即删除代码并破坏依赖于它的所有测试。 /providers 下的软件包。 E2E框架通过每个供应商包实现的接口来访问它。
E2E 测试套件的作者决定将哪些包导入到测试套件中。 接下来，使用 --provider 命令行标志启用供应商支持。 1.13 和 1.14 的 Kubernetes e2e.test 二进制文件继续支持与 1.12 相同的供应商程序。 也可以不包含包。 这意味着只有通用配置上的程序可用：
“骨骼”：通过 Kubernetes API 访问集群，没有其他内容
“本地”：后面跟“骨架”就差不多了相同，但除此之外，kubernetes/kubernetes/cluster 中的脚本可以在运行测试套件后通过 ssh 检索日志
外部文件
测试在执行过程中可能需要读取其他文件，例如 .yaml 清单。 但是，Kubernetes e2e.test 二进制文件必须可用且完全独立，以简化发布和执行。 Kubernetes 构建系统中的解决方案是使用 go-bindata 将 test/e2e/testing-manifests 中的所有文件链接到二进制文件中。 E2E 框架对 go-bindata 的输出有很强的依赖性，但对 bindata 的支持现在是可选的。 当您通过 testfiles 包访问文件时，将从另一个源检索它们。
--repo-相对于使用root参数指定的目录
零个或多个绑定数据块
测试参数
b>
e2e.test 二进制文件接受控制测试执行的附加参数。 2016年，曾尝试用Viper配置文件替换所有E2E命令行参数。 但努力已经停滞，导致开发人员没有关于如何处理特定于测试的参数的明确指导。
v1.12 中的方法是将所有标志添加到中央 test/e2e/framework/test_context.go 中，但这不适用于独立于框架开发的测试。 从 PR#69105 开始，建议使用常见用法。路径标志包在其自己的源代码中定义参数。 标签名称必须是分层的，用点分隔不同的级别，例如 my.test.parameter，并且必须是唯一的。 标志包强制唯一性，这会在第二次注册标志时引起混乱。 新的配置包简化了多个选项的定义并将它们存储在单个结构中。
综上所述，参数的处理如下。
测试包中的初始代码定义了测试和参数。 实际的参数值尚不可用，因此您无法在测试定义中使用它们。
测试套件的初始代码解析参数和配置文件（可选）。
测试运行和参数值可用。
但是，最近有人指出，最好并且可以仅通过配置文件设置测试设置，而不是将它们公开为命令行标志。 有一个未解决的错误和一个悬而未决的 PR。
Viper 支持已得到改进。 与供应商支持一样，它是完全可选的。 通过导入 viperconfig 包将其带入 e2e.test 二进制文件，并在解析正常命令行标志后调用。 这是通过以下方式实现的：当标志出现在 Viper 配置文件中时，所有可通过命令行标志设置的变量也会被设置。 例如，Kubernetes v1.13 e2e.test 二进制文件接受 --viper-config=/tmp/my-config.yaml，这会将 my.test.parameter 更改为具有以下内容的值: 将被设置。 my:test:parameter:value
在旧的 Kubernetes 版本中，该选项只能从当前目录加载文件，需要省略后缀，实际上可以这样配置，参数只有几个。 请注意，Viper 仍然有一个限制。 这意味着它不会通过将配置文件条目与已知标志进行匹配来检测拼写错误，并且不会警告未知的配置文件条目。 更好的 Kubernetes 配置文件解析器仍在开发中。
从 .yaml 创建项目清单
在 Kubernetes 1.12 中，尽管支持从 .yaml 文件加载单个项目，但创建该项目必须使用手写代码来完成。 该框架允许您加载包含多个项目的 .yaml 文件，修补这些项目（例如，设置为当前测试创建的命名空间），并提供创建新项目的方法。 当前用于从也用于 kubectl 部署的完全相同的 .yaml 文件重新部署每个测试的 CSI 驱动程序。 这些测试是完全独立的，如果 CSI 驱动程序支持以不同名称运行，则可以并行运行。
但是，重新部署驱动程序会减慢测试执行速度，并且不会覆盖驱动程序上的并发操作。 更现实的测试场景是在测试集群启动时部署驱动程序一次，然后针对该部署运行所有测试。 一旦更清楚如何扩展测试集群启动以包括 CSI 驱动程序等其他实体的安装，我们计划最终将 Kubernetes E2E 测试转移到此模型。
Kubernetes 1.14 中引入的增强功能存储测试重用
能够使用 Kubernetes 外部的框架构建自定义测试套件。 但是没有测试的测试套件仍然是没有用的。 一些现有的测试，尤其是与存储相关的测试，可以应用于树外部的组件。 感谢 Masaki Kimura 的工作，定义了 Kubernetes 1.13 中的存储测试，以便可以针对不同的驱动程序多次实例化它们。
但历史有重演的趋势。 与供应商程序类似，定义这些测试的包也获取所有树内存储后端的驱动程序定义，从而获得超出所需的其他包。 这在 Kubernetes 1.14 中已修复。
跳过不支持的测试
某些存储测试取决于集群功能（例如在启用 XFS 的主机上运行）或驱动程序（例如块卷支持）。 在测试执行期间会检查这些条件，如果不满足，则跳过测试。 好处是该日志解释了测试未运行的原因。
开始测试很慢，特别是如果您必须先部署 CSI 驱动程序，但其他方面也不算太慢。 对快速集群的测量创建测试创建命名空间需要 5 秒，并会产生大量嘈杂的测试输出。 这可以通过跳过不受支持的测试的定义来解决，但是很难报告为什么该测试甚至不是测试套件的一部分。 这种方法已被弃用，取而代之的是重新组织保存的测试套件，以便在继续更昂贵的测试配置步骤之前首先检查条件。
更具可读性的测试定义
相同的 PR 使用测试用例及其在函数中的局部变量重写了测试，使其更接近传统的 Ginkgo 测试。
测试外部驱动程序
构建自定义 E2E 测试套件仍然是一项艰巨的任务。 Kubernetes 1.14 测试存档中分发的 e2e.test 二进制文件允许您测试已安装的存储驱动程序，而无需重建测试套件。 请参阅此自述文件以获取详细说明。
E2E 测试套件方法测试套件初始化
第一步是设置定义测试套件的必要样板代码。 在 Kubernetes E2E 中，这是在 e2e.go 和 e2e_test.go 文件中完成的。 您还可以运行 e2e_test.go 文件。 Kubernetes 导入所有各种供应商程序、树内测试、Viper 配置支持，并将数据文件绑定到 e2e_test.go 中。 e2e.go 控制实际执行，包括一些集群准备和指标收集。
一个更简单的起点是 PMEM-CSI 的 e2e_[test].go 文件。 没有供应商程序，没有 Viper，没有绑定数据，仅导入存储测试。
与 PMEM-CSI 类似，OIM 删除了所有附加功能，但将自定义集群启动直接集成到测试套件中，使其更加复杂。 这在这种情况下非常有用，因为需要一些额外的组件。 它在主机端执行。 通过直接在 E2E 二进制文件中运行 dlv，可以促进使用 dlv 进行交互式调试。
两个 CSI 驱动程序都遵循 Kubernetes 示例，并使用 test/e2e 目录作为测试套件。然而，也可以使用其他目录和文件名。
添加端到端存储测试
测试由导入测试套件的包定义。 E2E测试的唯一独特之处在于它使用framework.NewDefaultFramework来实例化Framework.Framework指针（通常称为f）。 该变量在每次测试的 BeforeEach 中重新初始化，并在 AfterEach 中释放。 它有一个运行时（仅运行时）f.ClientSet 和 f.Namespace，您可以在测试中使用它们。
PMEM-CSI 存储测试引导至 Kubernetes 存储测试套件，并为必须安装在测试集群上的 PMEM-CSI 驱动程序设置配置测试实例。 存储测试套件更改存储类别以在不同的文件系统类型上运行测试。 由于此要求，存储类是从 .yaml 文件创建的。
描述该框架可用的所有不同实用方法超出了本博客文章的范围。 阅读现有测试和框架的源代码是一个很好的入门方法。
贡献代码
即使删除了许多不必要的依赖项，贡献 Kubernetes 代码仍然不是一件容易的事。 k8s.io/kubernetes 无意包含在其他项目中，并且其依赖项也没有以 dep 等工具可以理解的方式定义。 还应包含其他 k8s.io 包，但不遵循语义版本控制或缺少版本标记（k8s.io/kube-openapi、k8s.io/utils）。
PMEM-CSI 使用 dep。 它的 Gopkg.toml 文件是一个很好的起点。 这会启用修剪（默认情况下在 dep 中未启用）并将给定项目锁定到与正在使用的 Kubernetes 版本兼容的版本。 如果 dep 没有选择兼容版本，检查 Kubernetes 的 Godeps.json 可以帮助确定哪个版本是正确的版本。
编译并运行测试套件
go test ./test/e2e -args -help 是测试测试套件编译的最快方法。
编译完成并设置集群后，所有测试都将使用 go test -timeout=0 -v ./test/e2e -ginkgo.v 命令运行。 要并行运行测试，请使用 ginkgo -p ./test/e2e 命令。
如何参与
Kubernetes E2E框架由测试SIG的testing-commons子项目拥有。 请参阅此页面以获取联系信息。
有各种任务，包括但不限于：
将 test/e2e/framework 移至临时存储库并重新组织它以使其更加模块化 (#74352)。
通过将更多代码移至 test/e2e/framework 来简化 e2e.go (#74353)。
从 Kubernetes E2E 测试套件中删除特定于供应商的代码 (#70194)。
致谢
感谢本文的审阅者：
Olev Kartau (https://github.com/okartau)
Mary Camp (https://github.com/MCamp859)
KubeCon + CloudNativeCon + 开源峰会会议日期：
会议日程公告日期：2019年4月10日
会议活动日期：2019年6月24-26日
KubeCon + CloudNativeCon +开源峰会赞助计划
KubeCon + CloudNativeCon + 开源总计IT多元化奖学金现已接受申请
KubeCon + CloudNativeCon与开源峰会即将在中国首次整合
KubeCon + CloudNativeCon + Open Source峰会购票窗口，立即购票！
CNCF 邀请您加入我们的最终用户社区
评论前必须登录！
注册