部署 InfluxDB 和 Telegraf 监控 Kubernetes

作者：Ben Tasker / 开发者
2024 年 9 月 17 日

导航至

我在家运行一个小型 Kubernetes 集群，最初是为了实验而设置的。

因为它最初是一个试验场，所以我从未费心设置监控。但是，随着时间的推移，我最终将更多类似生产的工作负载放在上面，所以我决定应该部署一些可观测性。

考虑到即使我的鱼缸也可以呼叫我，没有集群的可见性实际上有点奇怪。我不需要（或想要）集群能够生成页面，但我仍然想要底层指标，即使只是为了容量规划。

在这篇文章中，我将讨论部署和自动预配置 InfluxDB OSS 2.x 实例（可选 EDR）和 Telegraf，以收集指标以便使用 Grafana 进行可视化。

计划

首先，快速概述计划

  • 创建一个专用命名空间（称为 monitoring）
  • 部署和预配置 InfluxDB OSS 2.x 实例以写入指标
  • 将 Telegraf 部署为 DaemonSet，以在每个节点上使用 kubernetes 和 kube_inventory 插件运行
  • 在 Grafana 中绘制指标图表（我已经有一个 Grafana 实例——如果您需要部署一个，请参阅此处）

因为这是一个家庭实验室，所以我将犯一个运维错误，并将 InfluxDB 部署到我正在使用它来监控的同一个集群中。

如果您在生产环境中执行此操作，则应通过在其他地方部署 InfluxDB、使用 InfluxDB Cloud 或配置 边缘数据复制 (EDR) 以便将数据复制出集群，来确保在中断期间指标可用。

在下面的步骤中，我使其易于配置 EDR（如果您不需要，则无需更改；只需不创建该密钥即可）。

在本文档中，我将包含 YAML 代码片段。假设您会将它们附加到一个文件（我的文件名为 influxdb-kubemonitoring.yml），以便在各个点馈送到 kubectl 中。

对于那些赶时间的人，我的 article_scripts repo 中也提供了清单副本。

为什么选择 InfluxDB？

使用 InfluxDB 和 Telegraf 具有许多优势

  • 轻松的异地复制（通过 EDR）
  • 易于设置：Telegraf 已包含所有内容
  • 可以使用 InfluxQL 查询指标（和/或 SQL，如果复制到 v3 中）

由于 Telegraf 可以缓冲数据，并且 InfluxDB 可以接受写入到过去的数据，因此如果集群确实发生故障，则有可能在以后分析事件原因时获得对其状态的回顾性可见性。

当然，还有熟悉度：我的所有指标都进入 InfluxDB，因此使用我最熟悉的解决方案最有意义。

命名空间

所有内容都将部署到名为 monitoring 的命名空间中，因此首先我们需要创建该命名空间

密钥创建

我们将需要定义一个包含多个项目的密钥，包括

  • InfluxDB 实例的管理员凭据
  • 要在 InfluxDB 实例中创建的令牌
  • InfluxDB 组织的名称
  • 两个非特权用户的凭据

这些将用于在 InfluxDB 中创建帐户。

我使用 gen_passwd 生成密码，但使用任何适合您的工具。

为了创建随机令牌，我使用了

创建一个名为 influxdb-info 的密钥

存储

InfluxDB 需要一些持久存储，以便我们的指标在 pod 滚动后仍然可用。

通常，我使用 NFS 来访问我的 NAS，因此我定义了一个 NFS 支持的物理卷和一个关联的声明

可选：边缘数据复制

由于我们将 InfluxDB 部署到受监控的集群中，为了帮助确保连续性，我们可能希望将数据向前复制（到 InfluxDB Cloud 或另一个 OSS 实例），以便它也存在于集群外部。

OSS 2.X 具有一个名为 边缘数据复制 的功能——这涉及定义一个远程位置（即，我们要复制到的位置），然后指定应复制哪个存储桶。

为此，您将需要

  • 您的远程实例的 URL
  • 远程实例的身份验证令牌
  • 要与远程实例一起使用的组织 ID
  • 您要写入的远程存储桶的 ID

如果您决定不配置 EDR 并且想要稍后添加它，您可以随时手动启用它。

为了启用 EDR，我们将定义一个密钥来保存配置它所需的信息

我们稍后在本文中创建的清单将引用这些值（它们是可选的，因此如果未定义密钥，则不应出错）。

预配置 InfluxDB 身份验证

InfluxDB 容器支持通过环境变量预配置凭据，因此我们将传入对我们之前创建的密钥的引用。

但是，仍然有一个问题：尽管映像允许我们传递已知的令牌值（通过 DOCKER_INFLUXDB_INIT_ADMIN_TOKEN），但它用于创建操作员令牌。

操作员令牌是一个极其特权的凭据，我们真的不希望将其传递到 Grafana 和 Telegraf 中。

我们需要预填充一些权限较低的凭据，但映像和 InfluxDB 都没有提供创建具有已知值的（非操作员）令牌的方法。我们可以编写一个脚本来调用 API 并生成一对令牌，然后在将它们写入 k8s 密钥之前，但我们需要给某些东西更新密钥的能力，这有点不太理想。

相反，我们可以创建一个用户名/密码对，然后可以将其与 v1 API 一起使用。

InfluxDB 映像可以运行任意初始化脚本（但仅在 Influx 的数据文件存在时才触发它们，因此不存在意外重新运行的风险）。

我们将定义一个 ConfigMap 来存储一个小脚本，该脚本将创建一个 DBRP 策略和一对非特权用户（一个只读，一个只写）。如果我们选择启用 EDR，该脚本还会配置 EDR。

部署 InfluxDB

接下来，我们需要部署 InfluxDB 本身。

关于此定义的注意事项是

  • 变量 DOCKER_INFLUXDB_INIT_BUCKET 和 DOCKER_INFLUXDB_INIT_RETENTION 告诉 InfluxDB 创建一个名为 telegraf 的存储桶，保留策略为 90 天。
  • 我的 NFS 共享配置为压缩权限，因此我包含了一个 securityContext 以使用适当的 UID。
  • 我们通过环境变量使密钥中的各种值可用。
  • 除了 PVC 之外，我们还将包含初始化脚本的 configmap 挂载到容器中。

Deployment 需要由服务来充当前端，因此我们接下来定义该服务，传递端口 8086

如果我们应用到目前为止的工作

我们现在应该能够检索服务详细信息

现在应该也可以使用集群 IP 对 InfluxDB 运行查询（将 $INFLUX_TOKEN 替换为您首次定义密钥时生成的令牌）。

我们应该也能够将只读凭据与 v1 查询 API 一起使用

部署 Telegraf

将 Telegraf 部署到 Kubernetes 中非常容易。但是，授权它从 Kubernetes API 获取信息涉及与 k8s 身份验证模型交互，这有点复杂。

首先，我们将定义一个名为 telegraf 的服务帐户，然后授权该帐户与 kubelet 和集群 API 通信。

定义服务帐户

定义一对集群角色

注意：从技术上讲，您可能可以将它们组合起来，但由于它们提供对不同事物的访问权限，因此我更喜欢将它们分开。

最后，创建角色绑定以将两者链接回服务帐户

摆脱了这种不愉快的事情之后，我们就可以配置和部署 Telegraf 了。

由于 Telegraf 配置很简单，我们将其放入 ConfigMap 中。

注意：无需手动替换变量；我们将在容器配置中设置它们。

然后，我们准备好定义我们的 DaemonSet。

这里有几个重要的点

  • 我们通过环境变量 HOSTIP 公开节点 IP
  • 我们通过 spec.nodeName 将环境变量 HOSTNAME 设置为节点主机名
  • 我们从我们之前创建的密钥中传入凭据
  • 我们将目录从主机映射到容器中
  • 我们将我们的 configmap 挂载为配置
  • 我们设置 MONITOR_HOST 以使用我们为 InfluxDB 创建的服务的名称 (http://influxdb:8086)。

如果我们应用更新后的配置

Telegraf 应该会启动并开始从 Kubernetes API 收集指标。

我们可以通过跟踪 Telegraf 的日志来检查

如果它没有记录错误，那么一切正常。

检查指标

我们可以通过登录其 Web 界面来确认指标是否正在 InfluxDB 中到达。

假设您已部署到集群中，请运行以下命令获取集群 IP

然后，在浏览器中访问 http://[集群 IP]:8086。

您应该能够使用您在本过程开始时创建的凭据登录。

如果您浏览到数据资源管理器，您应该会看到一堆与 Kubernetes 相关的指标。

仪表板

随着指标进入 InfluxDB，我们现在只需要一个仪表板来帮助可视化事物。我在 Grafana 中完成所有仪表板操作，这样我只需要去一个地方即可可视化来自各种来源的指标。

我们需要告诉 Grafana 如何与我们的新 InfluxDB 实例通信，因此

  • 汉堡菜单
  • 连接
  • 连接数据
  • 搜索 InfluxDB

在 Grafana 中添加新的 InfluxDB 数据源时，您需要提供以下内容

  • 语言：InfluxQL（因为我们正在使用 v1 API）
  • URL：如果 InfluxDB 和 Grafana 在同一集群中运行，您可以简单地使用 InfluxDB 服务名称。否则，您需要提供 IP 或域名

在 Grafana 中使用以下设置

  • 数据库：telegraf
  • 用户：kubestatsro
  • 密码：我们之前定义的密码

创建数据源后，我们可以开始使用如下查询提取统计信息

最终，我们正在构建一个单一仪表板，使我们能够查看节点、命名空间和 pod 级别的资源使用情况。

例如，我们可以看到我的 Atuin 同步服务器 已分配了比实际使用量多得多的资源（可能阻止其他工作负载在该节点上进行调度）： 仪表板的可导入副本可以在 Github 上找到。因为它使用 InfluxQL，所以它应该与 InfluxDB 1.x、2.x 和 3.x 兼容。

结论

如果您一直按照说明操作，您现在应该拥有一个 InfluxDB 实例，该实例接收有关 Kubernetes 集群中每个资源的指标。如果您启用了 EDR，这些指标将被复制到外部实例，以帮助确保在中断期间监控的连续性。

我现在有办法更多地了解集群内部发生的事情，包括我需要的信息，以确保资源请求不会设置得太高，从而不必要地限制容量。

尽管 YAML 的冗长性使其看起来比实际情况复杂得多，但将 InfluxDB 和 Telegraf 在集群中启动并运行并没有花费太多时间。

凭据和配置的自动配置意味着，如果我想重新开始，我可以简单地擦除 PVC 并滚动 pod——映像将重新创建凭据，并且一切都将恢复正常。

要开始此项目或 InfluxDB 上的另一个项目，请立即注册一个免费的云帐户。