技术文章

Kubernetes 正迅速成为企业级容器编排的首选开源技术。它不仅允许 IT 部门自动大规模部署容器，还可以确保这些容器以容错方式可靠运行。

Kubernetes，也称为缩写 k8s，由 Google 创建并于 2015 年向公众推出。它于 2018 年作为完全开源项目移交给云原生计算基金会 （CNCF）。对 Kubernetes 专业知识的需求很大，以至于 CNCF 现在为 Kubernetes 管理员提供认证。最终，Kubernetes 将影响软件开发生命周期中几乎所有参与的人——开发人员、运维人员和测试从业人员。就是这么酷。

但如果你不熟悉，你可能想知道为什么 Kubernetes 如此重要。因此，让我们来看看细节。

是什么让 Kubernetes 很酷？

Kubernetes 解决了分布式计算中的一个基本问题：如何让在功能和资源需求方面不断变化的大规模容器化应用程序在互联网上可靠运行。Kubernetes 通过使用预定义状态的概念在物理机或虚拟机集群上创建、运行和维护容器驱动的应用程序来解决这个问题。

部署工程师创建应用程序（或服务）状态并将其提交给 Kubernetes。然后，Kubernetes 会永久创建、部署和维护应用程序，或者直到应用程序脱机。

让我们看一个例子。

想象一下，我们有一个云服务，它有一个功能，可以在提交给它的任何照片周围放置一个红色边框。（请参阅图 1。

图 1：修改照片的简单云服务

此外，如果用户以后需要，该服务将保存其工作的副本。这项服务旨在支持每分钟 10,000 个请求，这是一个相当繁重的需求——多个计算实例可以处理。因此，我们需要有许多计算实例，每个实例都运行一个照片处理器的副本。（通常，在存在冗余计算的情况下，负载均衡器用于将请求路由到多个实例中的可用实例。

应用程序设计人员将光处理器逻辑放入 Docker 映像中，并将容器映像存储在公共存储库（如 Docker Hub）中。最终，该映像将作为独立容器部署在虚拟机上。

现在是时候进行传统部署了。创建容器映像后，部署工程师需要创建一个虚拟机群集，在每台计算机上部署一个容器，然后协调所有网络和负载均衡。即使使用自动化，也有大量的工作可能既耗时又容易出错。

让我们采用另一种使用 Kubernetes 的方法。

工程师使用 Kubernetes，而不是让部署工程师完成创建容器、将它们部署到虚拟机以及执行向公共使用者提供服务所需的网络配置等耗时的任务。她在云上或数据中心预配 Kubernetes 集群，也可以使用现有的 Kubernetes 集群。确定群集后，工程师会创建一组清单（即 YAML 文件），用于描述应用程序的各个方面。这些描述包括在任何给定时间需要运行的容器数、将保留增强照片副本的存储资源的位置，以及定义如何访问对照片处理服务的请求的路由配置。

清单集中包含一个清单，用于定义将托管光处理器容器的 Pod 的结构。

这些清单定义应用程序的状态。部署工程师将清单提交给 Kubernetes，Kubernetes 在集群中查找有能力托管所需数量的 Pod 的节点（也称为虚拟机）。

然后，Kubernetes 使用从映像存储库（例如 Docker Hub）下载的容器映像创建包含其容器的 Pod。Kubernetes 将根据部署清单创建所需的 Pod 数量。然后，它将 Pod 注入到已识别的节点中。Kubernetes 使用服务清单中的信息来创建 Pod 在其后面运行的 Kubernetes 服务。最后，Kubernetes 会根据服务清单中提供的描述，向公众公开服务。（请参阅图 2。一旦服务向公众公开，应用程序就可以运行。

图 2：基本的 Kubernetes 部署在多个 Pod 中运行应用程序逻辑，这些 Pod 托管在 Kubernetes 服务后面运行的容器化代码

现在是真正酷的部分。部署应用程序后，Kubernetes 保证在发生任何内部故障时保持应用程序的状态。如果节点脱机，Kubernetes 会将 Pod 从损坏的节点移动到另一个正常运行的节点。如果 Pod 自行发生故障，则将对其进行补充。如果由于某种原因整个集群爆发，则只需将清单重新应用于新集群，应用程序将恢复到其原始状态。此外，Kubernetes 可以使用跨集群的滚动更新来修改 Pod 中的任何容器。如果更新不顺利，Kubernetes 允许回滚。

正如你所看到的，Kubernetes 提供了开箱即用的高度自动化。所需要的只是定义应用程序的状态，然后让 Kubernetes 完成剩下的工作。

然而，仅仅因为驱动 Kubernetes 的整体想法很简单，使用这项技术并不容易。Kubernetes 确实需要时间来掌握。创建清单需要了解 Kubernetes 的大量细节。网络和接入配置有很多“陷阱”。还有一些重大的安全问题需要解决。公司软件开发生命周期中的某些开发流程也可能需要修改，以充分利用 Kubernetes，包括性能测试的方式。

尽管如此，一旦 IT 部门在 Kubernetes 上启动并运行，该技术就会提供高度的灵活性和弹性，并且节省了大量劳动力。但是，同样，你需要知道你在做什么。

Kubernetes 对性能测试有什么影响？

测试从业者在进行性能测试的方式上必须做出的最大改变可能是适应在 Kubernetes 下运行的应用程序的分布式和短暂性。请记住，Kubernetes 保证状态，但在大多数情况下，实现该状态的地点和时间由 Kubernetes 自行决定。除非另有配置，否则应用程序 Pod 的位置可以在 Kubernetes 集群中随时更改。（Kubernetes 确实有一种称为 pod affinity 的机制，可以使特定的 pod 可以分配给特定的节点，但这不是开箱即用的默认设置。

虽然测量集群外部的性能（例如，根据公共 URL 测量请求和响应时间）仍然是一项非常简单的任务，但了解集群内部发生的情况要复杂得多。为了详细了解内部性能，测试人员需要依靠系统监视器、日志和分布式跟踪工具来收集数据。在测试时跨集群中运行的节点和容器聚合运行时数据是确定性能行为的常用技术。

因此，性能测试人员需要有一个具有基本监控工具（如 Heapster、Prometheus、Grafana、InfluxDB 和 CAdvisor）的操作设施。这些工具可以密切关注集群并报告正在进行的操作行为以及危险情况。能够使用这些工具及其提供的信息对于测试从业者来说至关重要。否则，他们就是盲目飞行。事实上，随着越来越多的机器对机器活动发生在互联网上，而不是在人与计算机之间完成工作，整个集群的机器监控将成为确定被测系统性能的主要方式。

随着 Kubernetes 越来越多地集成到更广泛的公司中，性能测试将从简单地执行 URL 转变为针对临时运行的机器集群调用各种活动，然后分析集群外部和内部的许多不同类型的结果。这是性能测试方法的根本转变。

把它们放在一起

鉴于 Kubernetes 的广泛采用，我们可以预期 Kubernetes 将在未来很长一段时间内继续对整个 IT 领域产生影响。测试从业者也无法幸免于它的影响。事实上，有一个很好的案例是，随着 Kubernetes 继续通过 IT 激增，测试从业者将需要重新审视他们测试在该技术下运行的应用程序的方法。

使用 Kubernetes 需要采用不同的分布式计算方法。了解 Kubernetes 的基础知识对于当今从事该技术工作的任何人来说都很重要，包括测试人员。对于许多 IT 部门来说，能够采用与 Kubernetes 兼容的性能测试实践并继续满足组织的需求将是一个挑战。但是，考虑到 Kubernetes 为公司的技术基础设施带来的功耗和成本节约，这是一个值得应对的挑战。