使用Microsoft的Retina监控Kubernetes网络

开源 Retina 使用 eBPF 为 Kubernetes 中的容器网络带来可观测性。

译自 Using Microsoft’s Retina to monitor Kubernetes networks,作者 Simon Bisson。

Kubernetes 在 Microsoft 中的角色

Kubernetes 在 Microsoft 扮演着重要的角色。容器管理系统是该公司众多云服务的基础部分,从 Microsoft 365 和 Xbox 到 Azure,再到使用 Microsoft 的 Kubernetes 托管其自身服务的合作伙伴 OpenAI。

因此,Microsoft 发明了许多其 自有的 Kubernetes 管理工具。其中包括用于部署 AI 推理工作负载的 Kaito 和用于大规模管理 Kubernetes 集群的 Fleet。Microsoft 的所有各种工具都位于其两项托管 Kubernetes 服务(Azure Kubernetes 服务和 Azure 容器服务)之下,让你能够部署和编排基于容器的应用程序,而无需构建必要的管理框架。所有这些都是免费提供的,包括 API、门户和命令行界面。

在过去,这将是全部。Microsoft 会使用这些功能来让自己区别于其竞争对手及其 Kubernetes 云。但 Microsoft 已经将 开源模型 铭记于心,其 Kubernetes 计划的许多领导者都来自开源背景。Microsoft 并未将 Kubernetes 工具据为己有,而是将它们作为开源项目发布,任何人都可以使用它们,任何人都可以贡献新代码。

引入 Retina 可观测性平台

成为 开源项目 的最新 Azure 工具之一的是 Retina,这是一种网络可观测性工具,旨在帮助你了解所有集群中的网络流量,无论它们如何配置或使用什么操作系统。它也不依赖于 Azure 功能。你可以在任何 Kubernetes 实例中运行 Retina,无论是在本地还是在 AWS、Azure 或 GCP 中。

Retina 的核心,与 Falco 安全工具 非常相似,是 扩展 Berkeley 数据包过滤器 (eBPF)。这些过滤器让你可以在主机操作系统的内核中运行代码,在应用程序容器之外,因此你可以使用 eBPF 探针而不会显著影响你正在运行的代码。无需向容器添加代理或向代码添加监控库,一个 eBPF 探针可以监控在主机上运行的所有节点,无论它是云虚拟机还是本地物理硬件。

在内核中运行 Retina 探针简化了网络监控。你无需知道主机服务器上安装了哪些网卡,或者 Kubernetes 安装如何使用服务网格。相反,你可以了解主机操作系统的网络堆栈如何处理数据包。你可以跟踪数据包类型、延迟和数据包丢失,利用低级别的 TCP/IP 功能,这些功能在较高层可能无法访问。

通过专注于使云原生网络可观测,Retina 被设计为可以融入任何监控工具集和任何 Kubernetes 安装。它同时支持 Linux 和 Windows,这应该有助于你监控和调试混合了 Linux 和 Windows 服务的混合应用程序。由于 eBPF 探针是代码,你可以将它们视为可自定义的插件,让 Retina 能够随着新的 Kubernetes 功能而演进,并支持你监控需求所需的指标。

数据以节点级别传递到熟悉的 Prometheus 日志记录服务。收集的数据包括 DNS、第 4 层操作和数据包捕获。由于数据已标记,因此你可以在 Kubernetes 环境中构建操作映射,帮助跟踪问题,例如阻止微服务,因为 Retina 会记录 Kubernetes 实例中及周围的流模式。

开始使用 Retina

首先 克隆 Retina GitHub 存储库,然后使用捆绑的 Helm Chart 进行安装。你可能还需要配置 Prometheus,以确保 Retina 正在记录数据。如果你想 使用 Retina CLI,则需要在 Linux 托管的 Kubernetes 上运行。CLI 在 kubectl 中运行,因此可以轻松与其他 Kubernetes CLI 工具一起使用。或者,你可以使用 YAML 自定义资源定义来配置和运行网络捕获。

在 Linux 上,eBPF 网络捕获插件是开源 Inspektor Gadget 工具的一个版本。它最初由 Kinvolk 团队开发,现在是 Azure 的一部分,仍然专注于容器工程。Inspektor Gadget 是一个 Kubernetes eBPF 工具库,适用于任何规模的 Kubernetes 应用程序,从单个节点到大型集群。Retina 使用 Inspektor Gadget 跟踪小工具来观察网络系统事件。

观测容器网络

Retina 网站 提供了使用该工具的详细说明。Retina 提供三种不同的操作模式:按节点级别划分的基本指标,支持按源和目标 Pod 聚合的更详细的“远程上下文”指标以及允许您选择要监视哪些 Pod 的“本地上下文”选项。

需要注意的是,您默认情况下看不到所有内容,因为这可能会让人不知所措。相反,不同的指标由不同的插件启用。例如,如果您想跟踪 DNS 调用,请首先启用 DNS 插件。所有指标都包括集群和实例元数据,因此您可以使用标签进行筛选和报告,以识别特定的目标节点和 Pod。本地和远程上下文选项添加了跟踪源和目标的标签。

配置 Retina 还需要 设置 Prometheus 目标 以获取数据,以及适当的 Grafana 仪表板。Microsoft 在 Retina 存储库中为 GitHub 上的这两者提供了示例配置。默认情况下会显示集群和 DNS 数据。将数据放在 Prometheus 中允许您使用其他工具处理 Retina 数据,例如将数据馈送到策略引擎以触发警报或自动执行特定操作。

在安装了 Retina 并配置了 Prometheus 和 Grafana 之后,您现在可以超越默认设置,通过 YAML 配置 Retina 代理和插件。其他指标配置通过 Kubernetes 自定义资源定义进行。

测量 Kubernetes 网络操作

Retina 并不是真正用于在数据包级别进行持续监视的工具,因为它会在繁忙的集群中生成大量数据,当然除非您使用基于策略的工具来识别正常操作的异常情况。在实践中,最好使用 Retina 来 识别根本原因 正在运行的集群出现的问题。也许节点无法相互通信,或者您怀疑错误可能是由于特定服务交互中的延迟造成的。在这里,您可以使用单个命令触发所需的包捕获,该命令将收集您运行诊断所需的所有数据。

持续操作通过指标报告,这些指标为您提供有关关键网络问题的统计信息。可以使用 Prometheus 管理这些指标以生成警报,并使用 Grafana 仪表板为您提供集群整体性能的概述,以及来自其他可观测性工具的数据。

Retina 提供的一个有用的指标是经常被忽略的指标:API 延迟。但是,在云原生开发中,您经常使用第三方 API。有些可能是云提供商的平台服务,而另一些可能是必不可少的业务数据源,例如 Salesforce 或 SAP Hana。在这里,您可以使用 Retina 的 API 服务器延迟来获取有助于跟踪服务器响应时间的指标。

拥有这些数据可以让您开始与 API 提供商进行诊断过程,帮助追踪任何延迟的来源。API 访问延迟可能是您的应用程序中的一个重大障碍,因此拥有这些数据可以帮助您提供更可靠、响应更快的应用程序。

Kubernetes 生态系统的成熟

Microsoft 已发布基于 Retina 的可观测性工具的预览版本,可用于 Azure Kubernetes 服务作为网络可观测性加载项。这适用于 Azure 托管的 Prometheus 和 Grafana。您可以在其文档中找到预配置指标的列表,但它目前仅提供 Retina 功能的一个子集,仅提供节点级指标。

使用 Retina 时要考虑的一个关键点是,它建立在 Azure 在 Kubernetes 方面的经验之上。开箱即用的捕获指标是 Azure 团队认为重要的指标,并且您正在利用支持世界上最大、最活跃的 Kubernetes 环境之一的知识。如果您需要其他指标,您可以为 Retina 构建自己的 eBPF 探针,然后可以与更广泛的 Kubernetes 社区共享。 开源需要共享专业知识才能取得成功。通过开放代码库,Microsoft 鼓励 Retina 开发人员将他们的知识带到平台,并希望 AWS、GCP 和其他大规模 Kubernetes 运营商与世界分享他们学到的网络知识。随着 Kubernetes 的成熟,基于 eBPF 的工具(如 Retina 和 Falco)将变得越来越重要,提供我们大规模交付安全可靠的云原生应用程序所需的数据。

发表回复

您的电子邮箱地址不会被公开。 必填项已用 * 标注