Kubernetes:可观测能力平台的挑战

Kubernetes 是容器调度事实上的标准，因为它解决了许多问题，例如跨机器分配工作负载，实现容错，并在出现问题时重新安排工作负载。虽然加快开发流程和降低复杂性确实让 Kubernetes 操作人员更轻松，但是其固有的抽象和自动化特点，可能会导致难以发现、排障和防范新型错误。 通常情况下，Kubernetes 监测是使用单独的仪表板（如 Kubernetes 仪表板 或 Grafana App for Kubernetes)进行管理的，显示集群的状态，并在出现异常时发出警报。安装在 Kubernetes 节点上的监测代理会监测 Kubernetes 环境，并提供有关节点状态的宝贵信息。然而，有一些相关的组件和流程，例如，虚拟化基础设施和存储系统（见下图），可能会导致您的 Kubernetes 基础设施出现问题。

Kubernetes 仪表板作为综合监测解决方案的组成部分

本文介绍了在设计 Kubernetes 监测解决方案时要考虑的关键构建块。

作为平台运营商，您希望快速识别问题并吸取教训，以避免未来出现类似的故障。作为应用开发人员，您希望检测您的代码以了解您的服务如何相互通信以及哪里的瓶颈导致性能下降。幸运的是，监测解决方案可用于分析和显示此类数据，提供成熟的处理建议，并根据这些建议采取自动化措施（例如，警报或补救）。

Kubernetes 体验

使用托管环境时，例如 Google Kubernetes Engine (GKE), Amazon Elastic Kubernetes (EKS), 或 Azure Kubernetes Service，启动新集群很容易。应用第一个声明后（可能是从 how-to tutorial复制和粘贴)，Web 服务器在几分钟内启动并运行。 但是，在扩展生产配置时，随着专业知识的增长，您可能会发现：

• 您的应用并不像您想象的那样波澜不惊。
• 在 Kubernetes 中配置存储比在主机上使用文件系统更复杂。
• 在容器映像中存储配置或机密可能还有欠缺。

您克服了所有这些障碍，一段时间后，您的应用就会运行平稳。在采用阶段，对操作条件进行了一些假设，并且应用部署与这些假设一致。尽管 Kubernetes 具有内置的错误/故障检测和恢复机制，但仍可能会出现意外异常，导致数据丢失、不稳定以及对用户体验的负面影响。此外，如果您的资源限制设置为高（或根本不设置），Kubernetes 中嵌入的自动扩展机制可能会对成本产生负面影响。 为了保护自己免受这种情况的影响，您希望对应用进行检测以提供成熟的监测建议。这使您能够在出现影响最终用户体验的异常和性能问题时采取措施（自动或手动）。

可观测能力对 Kubernetes 意味着什么？

在设计和运行现代化的可扩展和分布式应用时，Kubernetes 似乎是适合您需求的解决方案。尽管如此，作为一个容器调度平台，Kubernetes 并不知道您应用的内部状态。这就是为什么开发人员和网站可靠性工程师依靠远程监测数据（即指标、跟踪和日志）来更好地了解其代码在运行时的行为。

• 指标是一段时间的数值表示。它们可以帮助您了解系统的行为如何随时间变化（例如，与上一版本相比，新版本中的请求需要多长时间？）。

• 跟踪表示分布式系统上因果相关的分布式事件，例如，显示请求如何从用户流向数据库。

• 日志易于生成，并以纯文本、结构化（JSON、XML）或二进制格式提供数据。日志也可用于表示事件数据。

• 除了可观测能力的三大支柱（即日志、指标和跟踪）之外，更复杂的方法可以添加拓扑信息、真实用户体验数据和其他元信息。

监测使可观测能力数据有意义

为了理解可观测能力提供的远程监测数据的流程，需要一种用于存储、基线化和分析的解决方案。此类分析必须提供可操作的答案，包括异常根本原因检测和基于收集数据的自动补救措施。提供各种具有独特功能、警报方法和集成的监测产品。其中一些监测产品遵循声明式方法，必须准确指定要监测的主机和服务。其他的产品几乎都是自配置式 — 他们自动检测要监测的实体，或者在部署监测代理时，被监测的实体自己注册。

监测 Kubernetes 的分层方法

“Kubernetes 的好坏取决于它在其上运行的 IaaS 层。与 Linux 一样，Kubernetes 也进入了发行版时代。”—(Kelsey Hightower 的 Twitter 发文, 2020) 尽管 Kubernetes 系统可能自身已经完美运行，您的监测工具没有报告任何问题，但您可能会遇到 Kubernetes 以外可能会带来风险的错误。 例如： 您的 Kubernetes 部署使用在动态配置的虚拟机映像文件中运行的虚拟机（最佳实践与否）。您尚未检测到虚拟化主机（或其共享存储）磁盘空间不足。现在，当机器映像尝试向上扩展时，您的虚拟机管理程序会停止虚拟机，从而使您的节点之一不可用。 在这个例子中，Kubernetes 监测自身或安装在 Kubernetes 节点上的 OS 代理都没有发现问题。由于此类跨领域异常的例子很多，因此应考虑采用更全面的方法进行 Kubernetes 监测。这样的解决方案可以分解为更细、更集中的领域，如下图所示。

Kubernetes 监测解决方案的层次

让我们逐一看一下这些层。

云提供商/基础设施层

根据您使用的部署模型，问题可能出现在您的云提供商的基础设施或您的内部部署环境中。在公共云环境中运行时，您希望确保不会耗尽资源，同时确保不会使用超过 Kubernetes 集群开始扩展时所需的资源。因此，跟踪在云提供商上配置的配额，同时监测您消耗的资源使用情况和成本将帮助您降低成本，同时不会耗尽资源。此外，云基础设施的变化也可能导致问题。因此，审计日志可以导出或直接导入到监测系统中。 在本地运行 Kubernetes 环境时，有必要监测可能影响它的所有基础设施组件。例如网络（交换机、路由器）、存储系统（尤其是在使用精简配置时)和虚拟化基础设施。网络的一些典型指标是吞吐量、网络接口上的错误率，甚至是安全设备上丢弃/阻止的数据包。日志文件分析可帮助您在问题发生之前主动发现问题（例如，过度配置）。

操作系统/实例层

如果您不在托管服务上运行 Kubernetes 集群，则您有责任使操作系统保持最新并得到维护。这样做时，检查 Kubernetes 服务（例如 kubelet、api-server、调度程序、控制器管理器）和容器运行时（例如 containerd或Docker)。此外，应该预先安排检查安全更新/补丁是否可用并在下一个更新周期自动安装它们。即使在这一层，日志条目也能帮助您查明系统是否有问题，并且是审核系统的有用来源。

云平台层

通过对监测解决方案的较低层进行设计，您可以确保 Kubernetes 环境的基础设施稳定和可观测性。Kubernetes 中发生的许多问题都是由于清单中的错误配置或集群中的应用数量增长而没有扩展基础设施而出现的。

正如许多指南中所述，您可以检查集群中的所有节点是否均可调度（例如 kubectl get nodes）。对 pod、部署和任何其他 Kubernetes 对象类型也可以这样做。特别是，当您不断在集群上加入新服务时，您可能会发现某些 Pod 处于“挂起”状态。这表明调度程序无法正常工作。使用 kubectl describe

提示：对于其他所有集群系统，请记住，节点可能会有意（例如更新后）或意外发生故障。在这种情况下，您希望能够在剩余节点上安排您的工作负载，因此如果您在监测基础设施上配置阈值，您应该计划这样的储备。

在某些情况下，您可能会配置部署并发现无法创建 pod（例如通过使用不存在的服务帐户）。出现问题的一个迹象是部署的所需和可用 Pod 的不同值(kubectl get deployment)。

最后，在配置低内存请求时，可能会出现 pod 多次重启的情况，这可能是因为它们的内存不足。这可以通过调整容器请求和限制来解决。

应用层

即使您的基础设施运行完美并且 Kubernetes 没有显示任何错误，您仍然可能会在应用层遇到问题。

例子：
您正在运行一个多层应用（Web 服务器、数据库），并配置了一个 HTTP 健康检查，它在应用服务器上简单地打印出“OK”，并且在数据库上运行一个简单的数据库查询。两个健康检查都运行得很好，似乎没有问题。当客户尝试在 Web 界面上运行特定操作时，会显示一个空白页，并且该页面会无限加载。

上例中的应用问题不会强制系统崩溃，使用简单的检查机制也无法检测到。但是，如第一部分中所述，您可以通过插装应用发现此类异常。例如，跟踪可以显示请求被传递到应用服务器，数据库被查询，但没有产生响应。一段时间后，可能会发生额外的请求在应用上排队（或其他一些客户尝试做同样的事情）并且连接池填满（可能是一个指标）。一段时间后，可能会出现 HTTP Server 本身无法再获取请求的情况，此后，健康检查将失败。

采用模拟监测技术模拟客户行为，因此可以从客户的角度验证可用性。在前面描述的例子中，可以设置一个模拟这种行为的检查，它会报告一个错误，因为没有（及时）完成请求。

真实用户监测 (RUM) 可让您深入了解用户使用应用的行为和体验。RUM 可以帮助您识别错误，但也可以发现可用性问题，例如许多客户在订购过程的特定点离开您的站点。

业务层

如果客户无法使用或不喜欢它，那么最好的新功能也不会成功。因此，将应用中的更改或新功能映射到与业务相关的指标（如收入或转化率）可以帮助量化软件开发工作的结果。例如，与以前的版本相比，应用的更新版本可以使用标签和指标（例如每小时的订单）。如果您发现这些指标受到负面影响，回滚到上一个成功的版本是一个很好的补救选择。

潜在的解决方案

有许多产品可以为您的 Kubernetes 监测之旅提供支持。如果您更喜欢使用开源产品，这里有很多CNCF (云原生计算基金会) 项目，例如Prometheus，用于存储和抓取监测数据。此外，OpenTelemetry有助于检测软件，而Jaeger用于呈现跟踪数据。其他项目，如Zabbix和Icinga可以帮助您监测您的服务和基础设施。Grafana是一种可呈现几乎所有监测工具所收集数据的工具。

虽然许多开源工具专门用于很好地实现其应用场景，但商业解决方案通常涵盖更广泛的基础设施、应用和真实用户监测应用场景。例如，Dynatrace涵盖了本文中所描述的所有功能，并且开箱即用，只需最少的设置工作。如果您想了解有关 Dynatrace 面向 Kubernetes 监测功能的更多信息，看看这四篇博文：

• 通过对 Kubernetes pod 的运营洞察力扩展应用和基础设施的可观测能力
• 第 2 天的操作：监测 Kubernetes 基础设施
• 只需 60 秒自己在 Google Kubernetes Engine 上升级可观测能力
• 使用 Dynatrace 将 AWS EKS 监测作为自助服务

结束语

在为 Kubernetes 设计监测解决方案时，除了 Kubernetes 本身之外，还有很多事情需要考虑。通过将您的监测分解成更小的部分，团队能够专注于并维护他们的职责范围。例如，应用部署可以从内部部署切换到公共云基础设施部署，而不会影响应用本身的监测。

由于 Kubernetes 是一个高度动态的调度平台，应用实例可以在短时间内创生、消亡，因此处理这种行为的监测解决方案可以确保更流畅的监测体验。

有很多方法和工具可以为您的监测之旅提供支持。Dynatrace 等商业可观测能力平台使您只需很少的设置工作即可全面监测 Kubernetes 基础设施。