为每个人提供Kubernetes端到端测试

摘要：和中的二进制文件仍然支持与中相同的供应商程序。但是二进制文件应该是可用的并且完全独立，因为这简化了发布和运行它。将在测试档案中分发的二进制文件将能够测试已安装的存储驱动程序，而无需重建测试套件。

作者：Patrick Ohly（英特尔）

越来越多过去是Kubernetes组件的一部分，现在搬到在Kubernetes之外开发。例如，存储驱动程序曾经被编译成Kubernetes二进制文件，然后被转移到主机上的独立Flexvolume二进制文件中，现在作为容器存储接口（Container Storage Interface，CSI）驱动程序提供，这些驱动程序部署在Kubernetes集群内部的pod中。

这对于处理此类组件的开发者来说是一个挑战：如何在这样的外部组件上对Kubernetes集群进行端到端（E2E）测试？用于测试Kubernetes本身的E2E框架具有所有必要的功能。但是，尝试在Kubernetes之外使用它很困难，只有通过仔细选择大量依赖项的正确版本才能实现。在Kubernetes 1.13中，E2E测试变得更加简单。

这篇博客文章总结了Kubernetes 1.13的变化。对于CSI驱动程序开发者，它将涵盖使存储测试可用于测试第三方CSI驱动程序。如何使用它们将基于两个Intel CSI驱动程序显示：

开放式基础架构经理（Open Infrastructure Manager，OIM）

PMEM-CSI

测试这些驱动程序是大多数这些增强功能的主要动机。

E2E测试包括几个阶段：

实现测试套件。这是本篇博文的主要焦点。Kubernetes E2E框架是用Go编写的。它依赖于Ginkgo来管理测试，而断言（assertion）则依赖于Gomega。这些工具支持“行为驱动开发”，它描述了“规范”中的预期行为。在这篇博客文章中，“test”用于引用个别Ginkgo.It规范。测试使用client-go与Kubernetes集群进行交互。

启动测试集群。像kubetest这样的工具可以帮忙。

针对该群集运行E2E测试套件。Ginkgo测试套件可以使用ginkgo工具运行，也可以使用go test进行正常的Go测试。没有任何参数，Kubernetes E2E测试套件将基于环境变量（如KUBECONFIG）连接到默认集群，与kubectl完全相同。 Kubetest还知道如何运行Kubernetes E2E套件。

所有以下增强都遵循相同的基本模式：它们使E2E框架在Kubernetes之外更有用和更容易使用，而不会改变原始Kubernetes e2e.test二进制文件的行为。

使用Kubernetes <= 1.12的E2E框架很困难的主要原因是依赖于特定于提供者的SDK，这些SDK使用了大量的软件包。只是编译它已经不简单。

许多这些软件包仅在某些测试中需要。例如，测试预配置卷的安装必须首先通过一些非Kubernetes API，直接与特定存储后端通信，以管理员相同的方式配置这样的卷。

现在有尝试从核心Kubernetes中删除特定于云供应商的测试。在PR#68483中采用的方法可以看作是朝着这个目标迈出的一步：不是立即剥离代码并打破所有依赖它的测试，所有特定于云供应商的代码都被移动到test/e2e/framework/providers下的可选包中。然后，E2E框架通过每个供应商包多带带实现的接口访问它。

E2E测试套件的作者决定将哪些软件包导入测试套件。然后通过--provider命令行标志激活供应商支持。1.13和1.14中的Kubernetes e2e.test二进制文件仍然支持与1.12中相同的供应商程序。也可以不包含任何包，这意味着只有通用供应上程序可用：

“skeleton”：通过Kubernetes API访问集群，没有别的

“local”：跟“skeleton”差不多，但是另外kubernetes/kubernetes/cluster中的脚本可以在运行测试套件后通过ssh检索日志

测试可能必须在运行时读取其他文件，例如.yaml清单。但是Kubernetes e2e.test二进制文件应该是可用的并且完全独立，因为这简化了发布和运行它。Kubernetes构建系统中的解决方案是使用go-bindata将test/e2e/testing-manifests下的所有文件链接到二进制文件中。E2E框架过去对go-bindata的输出有很强的依赖性，现在bindata支持是可选的。通过testfiles包访问文件时，将从不同的源检索文件：

相对于使用--repo-root参数指定的目录

零个或多个bindata块

e2e.test二进制文件采用控制测试执行的附加参数。2016年，开始尝试用Viper配置文件替换所有E2E命令行参数。但是这种努力停滞不前，这使得开发者没有明确指导他们应该如何处理特定于测试的参数。

v1.12中的方法是将所有标志添加到中央test/e2e/framework/test_context.go，这对于独立于框架开发的测试不行。自PR#69105以来，建议使用普通标志包在其自己的源代码中定义其参数。标记名称必须是分层的，点分隔不同的级别，例如my.test.parameter，并且必须是唯一的。标志包强制执行唯一性，第二次注册标志时会发生混乱。新的配置包简化了多个选项的定义，这些选项存储在单个结构中。

总而言之，这就是现在如何处理参数：

测试包中的init代码定义了测试和参数。实际参数值尚不可用，因此测试定义不能使用它们。

测试套件的init代码解析参数和配置文件（可选）。

测试运行并可以使用参数值。

但是，最近有人指出，比较可取且有可能不将测试设置公开为命令行标志，只能通过配置文件设置它们。关于这个有一个开放的bug和一个待定的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的更好的配置文件解析器仍在开发中。

在Kubernetes 1.12中，有一些支持从.yaml文件加载单个项目，但是然后创建该项目必须通过手写代码完成。现在，框架提供新方法加载具有多个项目的.yaml文件、修补这些项目（例如，设置为当前测试创建的命名空间）以及创建它们。这目前用于为每个测试重新部署CSI驱动程序，这些驱动程序来自完全相同的.yaml文件，这些文件也用于通过kubectl进行部署。如果CSI驱动程序支持以不同的名称运行，则测试完全独立并且可以并行运行。

但是，重新部署驱动程序会降低测试执行速度，并且不会涵盖针对驱动程序的并发操作。更现实的测试场景是在启动测试集群时部署驱动程序一次，然后针对该部署运行所有测试。最终，Kubernetes E2E测试将转移到该模型，一旦更清楚如何扩展测试集群的启动，包括安装CSI驱动程序等其他实体。

能够使用Kubernetes之外的框架可以构建自定义测试套件。但是没有测试的测试套件仍然没用。一些现有的测试，特别是用于存储的测试，可以应用于树外组件。感谢Masaki Kimura所做的工作，Kubernetes 1.13中的存储测试被定义为可以针对不同的驱动程序多次实例化它们。

但历史有重复的习惯。与供应商程序一样，定义这些测试的程序包也提取了所有树内存储后端的驱动程序定义，这反过来又拉取了比所需更多的附加程序包。这在Kubernetes 1.14进行了修复。

某些存储测试依赖于群集的功能（如在支持XFS的主机上运行）或驱动程序（如支持块卷）。在测试运行时检查这些条件，导致在不满意时跳过测试。好的是这记录解释了为什么测试没有运行。

开始测试很慢，特别是当它必须首先部署CSI驱动程序时，在其他情况下也差不多。在快速集群上测量为测试创建命名空间的时间为5秒，并且会产生大量噪声测试输出。本来可以解决这个问题，通过跳过不支持的测试的定义，然后报告为什么测试甚至不是测试套件的一部分变得棘手。这种方法已不被考虑，而是采用重新组织存储测试套件的方式，以便在进行更昂贵的测试设置步骤之前首先检查条件。

同样的PR还将测试重写，接近传统的Ginkgo测试，测试用例及其局部变量在一个函数中。

构建自定义E2E测试套件仍然是相当多的工作。将在Kubernetes 1.14测试档案中分发的e2e.test二进制文件将能够测试已安装的存储驱动程序，而无需重建测试套件。有关详细说明，请参阅本自述文件。

第一步是设置定义测试套件的必要样板代码。在Kubernetes E2E中，这是在e2e.go和e2e_test.go文件中完成的。它也可以在e2e_test.go文件中完成。Kubernetes在e2e_test.go中导入所有各种供应商程序、树内测试、Viper配置支持和bindata文件。e2e.go控制实际执行，包括一些集群准备和指标收集。

一个更简单的起点是来自PMEM-CSI的e2e_[test].go文件。它不使用任何供应商程序，没有Viper，没有bindata，只导入存储测试。

与PMEM-CSI一样，OIM会丢弃所有额外功能，但有点复杂，因为它将自定义集群启动直接集成到测试套件中，在这种情况下非常有用，因为一些额外的组件必须在主机端运行。通过直接在E2E二进制文件中运行它们，使用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移动到staging仓库并重组它以使其更加模块化（#74352）。

通过将更多代码移入test/e2e/framework（#74353）来简化e2e.go。

从Kubernetes E2E测试套件中删除特定于供应商程序的代码（#70194）。

特别感谢本文的审阅者：

Olev Kartau（https://github.com/okartau）

Mary Camp（https://github.com/MCamp859）

KubeCon + CloudNativeCon + Open Source Summit大会日期：

会议日程通告日期：2019 年 4 月 10 日

会议活动举办日期：2019 年 6 月 24 至 26 日

KubeCon + CloudNativeCon + Open Source Summit赞助方案
KubeCon + CloudNativeCon + Open Source Summit多元化奖学金现正接受申请
KubeCon + CloudNativeCon和Open Source Summit即将首次合体落地中国
KubeCon + CloudNativeCon + Open Source Summit购票窗口，立即购票！
CNCF邀请你加入最终用户社区