将 InfluxDB 和 Telegraf 部署到 Kubernetes 以进行监控

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

导航至

我在家中运行一个小型的 Kubernetes 集群，最初我将其设置为实验的地方。

因为它最初是一个游乐场，所以我从未费心去设置监控。然而，随着时间的推移，我最终将其用于更多的生产级工作负载，因此我决定可能应该在其中放置一些可观察性。

没有对集群的可见性实际上有点奇怪，因为即使我的鱼缸也能通过 InfluxDB 和 Grafana 调用我。我并不需要（或想要）集群能够生成页面，但即使只是为了容量规划，我也仍然想要底层的指标。

在这篇文章中，我将讨论部署和自动预配置一个 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 存储库 中有关指标的清单的副本。

为什么选择 InfluxDB？

使用 InfluxDB 和 Telegraf 提供了多项优势

  • 简单的离站复制（通过EDR）
  • 易于设置：Telegraf 包含了所有功能
  • 度量可以与 InfluxQL（以及/或SQL（如果复制到 v3））查询

因为 Telegraf 可以缓存数据，InfluxDB 可以接受写入历史数据，如果集群发生故障，那么在分析事件原因时，可以获取其状态的回溯性可见性。

当然，还有熟悉性：所有我的度量都存入 InfluxDB，所以使用我最熟悉的解决方案是最有意义的。

命名空间

所有内容都将部署到一个名为 monitoring 的命名空间中，所以首先我们需要创建它

创建密钥

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

  • InfluxDB 实例的管理员凭证
  • 创建 InfluxDB 实例的令牌
  • InfluxDB org 的名称
  • 两个非特权用户的凭证

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

我使用 gen_passwd 生成密码，但你可以使用任何适合你的方法。

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

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

存储

InfluxDB 需要一些持久存储，这样即使 pod 重启后，度量数据仍然可用。

通常，我使用 NFS 访问我 NAS，所以我定义了一个基于 NFS 的物理卷及其关联的声明

可选：边缘数据复制

由于我们将 InfluxDB 部署到监控集群中，为了确保连续性，我们可能希望将数据复制到其他位置（如 InfluxDB 云或另一个 OSS 实例），以便它也存在于集群之外。

OSS 2.X 有一个名为 Edge Data Replication 的功能——这涉及定义远程（即我们想要复制到的地方）并指定应复制的 bucket。

为此，你需要

  • 远程实例的 URL
  • 远程实例的认证令牌
  • 与远程实例一起使用的 org ID
  • 你想要写入的远程 bucket 的 ID

如果你决定不配置 EDR 并稍后添加，你始终可以手动启用。

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

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

预配置 InfluxDB 认证

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

但是，还有一个问题：尽管镜像允许我们通过 DOCKER_INFLUXDB_INIT_ADMIN_TOKEN 传递一个已知的令牌值，但它用于创建 operator 令牌。

operator 令牌是一个 非常 有特权的凭证，我们并不真的希望将其传递给 Grafana 和 Telegraf。

我们需要预填充一些更少的特权凭证，但镜像和 InfluxDB 都没有提供创建（非 operator）令牌 的已知值的方法。我们可以编写一个脚本来调用 API 并在将它们写入 k8s 密钥之前铸造一对令牌，但我们需要给予 某些 更新密钥的能力，这并不是最佳选择。

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

InfluxDB 镜像可以运行任意的 init 脚本（但只有当 Influx 的数据文件存在时才会触发它们，因此没有意外重新运行的风险）。

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

部署InfluxDB

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

关于此定义需要注意的事项

  • 变量DOCKER_INFLUXDB_INIT_BUCKET和DOCKER_INFLUXDB_INIT_RETENTION告诉InfluxDB创建一个名为telegraf的bucket，并设置90天的保留策略。
  • 我的NFS共享配置为权限压缩，所以我包含了一个securityContext来使用适当的UID。
  • 我们将从我们的secret中提供的各种值通过环境变量使其可用。
  • 除了PVC外，我们还将包含初始化脚本的configmap挂载到容器中。

部署需要由服务前端，所以我们接下来定义它，通过8086端口转发

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

现在我们应该能够检索服务详情

现在也应该能够使用集群IP对InfluxDB执行查询（将$INFLUX_TOKEN替换为您在首次定义secret时生成的令牌）。

我们应该能够使用只读凭证与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兼容。

结论

如果您一直跟着做，您现在应该有一个接收Kubernetes集群中每个资源度量的InfluxDB实例。如果您启用了EDR，这些度量将复制到外部实例，以确保在故障期间监控的连续性。

我现在有了一些了解集群内部情况的方法，包括我需要确保资源请求不会被设置得太高，从而在过程中无谓地限制容量。

尽管YAML的冗长性使得它看起来比实际多得多，但要让InfluxDB和Telegraf在集群中运行起来并不需要太多。

凭据和配置的自动配置意味着，如果我想从头开始，我只需清除PVC并滚动Pods——镜像将重新创建凭据，一切都将恢复。

要开始使用InfluxDB上的此项目或其他项目，现在就注册一个免费的云账户。