七叶笔记 » golang编程 » 你们对Kubernetes基础架构进行自动化测试了吗？

你们对Kubernetes基础架构进行自动化测试了吗？

分类: golang编程 | 浏览: 360

软件测试

软件开发中的自动化测试是保障软件质量不可或缺一部分。随着容器化技术的不断发展，Kubernetes已经是事实上的标准。那么，通过自动化的方式验证像Kubernetes这样的基础架构的有效性，也越来越重要。这篇文章就介绍如何利用和扩展现有工具来测试Kubernetes的集群。

为什么要测试？

为什么要利用自动化集群测试的原因有很多。Kubernetes是一个非常复杂的系统，由多个独立的组件组成。他们在一种配置中能够正常运行并不意味着他们将在每种配置中都能完美的运行。

通过使用诸如kubeadm或kops之类的安装程序，或设置集群的其他方法，有多种启动Kubernetes集群的方法。对于每种方式，都有许多配置选项，使两个配置看起来不一样。在用户使用集群之前对其进行测试，以确保我们的设置能够按预期执行，从而为用户提供了一个可用的、有价值的平台。但是，集群设置只是第一步，这是因为Kubernetes的更新频繁的发布。这个时候，测试就有其作用了，可用验证更新之后基本的集群功能仍然可用。

不过，Kubernetes不仅仅是一个平台，它还是一个通过插件和附加组件进行扩展的框架。因此，没有一个Kubernetes集群是以一种同样的方式运行。Kubernetes自己的测试不包括插件，因此测试范围仅取决于插件开发人员的测试。为了确保我们的插件不会相互干扰或影响到Kubernetes，我们还应该在设置中对其进行测试。对于您自己编写的插件来说尤其如此。

一致性测试

Kubernetes一致性测试是测试Kubernetes核心功能的端到端 测试用例 的子集。用开发人员小组的话就是，“目前的测试仅是测试可用， API 的必须的功能”，通过这些测试的集群就是合格的，并且可以通过CNCF k8s合格工作组的认证。

目前，能够测试的功能 包括创建API对象，在节点上启动容器和挂载基本卷以及对kubectl进行测试 。不包括可选功能，例如基于角色的访问控制，NetworkPolicy和PodSecurityPolicy。插件和附加组件也大多不受一致性测试的限制，例如，对DNS进行测试，但某些测试仅隐含地要求使用Weave或Calico等插件进行联网。将来，也可能会通过一致性测试配置文件对插件进行测试，但目前需要分别对其进行测试。

但是，他们对基本集群功能的验证使一致性测试成为测试集群的理想起点。要执行这些测试，我们可以使用诸如kubetest或sonobuoy之类的工具。

kubetest

kubetest是Kubernetes管道中使用的CLI工具，用于运行端到端的测试。由于一致性测试是端到端测试的子集，因此可以使用kubetest通过过滤要运行的测试来在集群上运行它们。 

 # 安装最新版本的kubetest
go get -u k8s.io/test-infra/kubetest
#测试需要匹配集群版本
K8S_VERSION=$(kubectl version -o json | jq -r '.serverVersion.gitVersion')
# 设置该变量为y
export KUBERNETES_CONFORMANCE_TEST=y
# 显示设置配置
export KUBECONFIG=”$HOME/.kube/config”
# 运行该测试，skeleton是目前的集群
kubetest --provider=skeleton --test --test_args=”--ginkgo.focus=\[Conformance\]” --extract ${K8S_VERSION}

当下载并提取了我们集群版本所需的Kubernetes二进制文件之后，将会执行所有标记为[Conformance]的测试。还可以使用并行测试来缩短测试运行的时间。 

 kubetest --provider=skeleton --test --ginkgo.parallel --test_args=”--ginkgo.focus=\[Conformance\] --ginkgo.skip=\[Serial\]” --extract ${K8S_VERSION}
kubetest --provider=skeleton --test --test_args=”--ginkgo.focus=\[Serial\].*\[Conformance\]” --extract ${K8S_VERSION}

您还可以只运行一次kubetest extract，然后从Kubernetes目录中执行测试以加快后续执行速度。为了进行调试，您还可以告诉kubetest不要删除测试失败的名称空间： 

 kubetest --provider=skeleton --test --test_args=”--ginkgo.focus=\[Conformance\] --delete-namespace-on-failure=false” --extract ${K8S_VERSION}

尽管kubetest具有高度可定制性，但它不一定是面向最终用户的，其标志很少被记录且经常引起混淆。为了简单地运行一致性测试，Heptio发布了Sonobuoy，从而简化了此过程。

Sonobuoy

Sonobuoy是一种诊断工具，可以运行Kubernetes一致性测试。它由一个CLI组成，该CLI启动一个pod来管理集群中的测试运行，并让您随后检索结果。它是一个简单的即用型解决方案，是用于运行一致性测试的标准工具。

我们还可以选择使用kubetest和Sonobuoy来运行端到端测试套件的其他测试，以测试我们的某些插件。例如，如果我们要在集群中使用网络策略，则可能应该测试它们是否被强制执行。可以使用Sonobuoy进行如下基本测试： 

 # 执行sonobuoy, 覆盖掉默认的skip和focus参数
sonobuoy run --e2e-focus="\[Feature:NetworkPolicy\]" --e2e-skip=""

这些测试创建了受其限制的基本网络策略和Pod，并验证了它们是否在集群中得到了强制执行（请注意，它们并未验证集群中存在的策略是否按预期工作，因此可以使用netassert或illuminatio之类的工具使用）。对于其他功能也存在类似的测试。

编写自己的端到端测试

你也可以写自己的端到端测试用于集群的设置。这在运行本地开发的附件时特别有用，因为单元测试几乎无法模仿正在运行的Kubernetes集群的行为。要在Golang中开发测试，可以使用Kubernetes本身的E2E框架。

如果您使用其他编程语言，则仍然可以使用kubernetes客户端库，但是您必须自己编写一些样板代码，例如，用于设置和拆除测试名称空间。像pytest之类的单元测试框架对于将测试用例以及运行测试和收集结果分开仍然很有用。

无论您是刚刚开始Kubernetes之旅，还是已经在生产环境中运行集群好多年，都认为您应该立即开始测试这些集群。运行Sonobuoy在管道中进行一致性测试，开始对您使用的功能进行一些E2E测试，并为导致集群故障太多次的组件开发自己的测试。这将使操作更加轻松，并让您高枕无忧。

翻译：

相关文章