我如何在我的家庭实验室集群上安装Grafana Mimir

•2022年6月7日•10分钟

当我1月份开始在Grafana工作时，我已经习惯了使用私有云和on-prem基础设施，所以作为Grafana Mimir客户团队的高级软件工程师，我在这里的几乎所有工作对我来说都是新的。我刚接触Golang、Docker、Kubernetes、gRPC、公共云服务等。

Kubernetes尤其具有挑战性。在我的研究中Grafana米密尔而且Grafana企业指标在美国，我经历了两种极端之一的k8。对于本地开发，我在Docker或k3d中旋转所有内容。我可以破坏或调试任何我想要的东西，这对于代码开发非常好，但是我没有使用“真正的”集群的感觉。

在另一个极端，我使用我们的云集群，它们非常真实，性能非常好。然而，我们的目标是满足我们的SLOs，而不是破坏东西，因此我与这些集群的交互往往是在新版本和更改的精心计划的推出中进行的。

我需要的是一个中间地带来加速我的Kubernetes能力:一个物理的多节点集群，在那里我可以在一个小但不微不足道的规模上运行事情，并重复地破坏东西。

进入我的家庭实验室集群，又名“蜂巢”。

Homelab配置

这就是“蜂巢”。

之所以这样命名，是因为Beelink迷你电脑和我儿子帮我做的定制乐高架。我认为用蜂巢来描述Kubernetes集群也是一个恰当的比喻。每个微服务(蜜蜂)执行其指定的角色，每个荚(蜂房)与所需的资源隔离，整个事情是无形的协调和高效的。

硬件配置

我最初打算构建一个基于Raspberry pi的集群;然而，目前RPi几乎不可能买到，除非你愿意支付比零售高得多的价格。相反，我买了4台Beelink Mini PC作为Kubernetes节点。每个单元大致相当于树莓派4:

我不熟悉Beelink，所以上面的表格是一个方便的指南，用来比较众所周知的树莓派4B的配置。最后，我很高兴自己最终选择了Beelink单位，原因如下:

这个价格高于8GB的树莓派4B的零售价，但在当前供应紧张的市场中，与RPi经销商的当前价格相似或更低。
我对CPU的性能很满意。启用涡轮增压后，Beelink的频率提高了53%。同样重要的是，Beelink具有更大的L1和L2缓存。这些缓存的命中性能对于微服务的整体CPU性能至关重要。
与上一点相关，通过使用x86_64微架构，工作负载可以通过SSE、AVX等利用向量化操作。我们使用的很多软件都是为了在x86_64 cpu上使用这些SIMD优化而编译的。现代基于arm的CPU有一个名为Neon的SIMD单元，但必须编译代码才能使用它。像crc32这样的操作在RPC和基于存储的工作负载中无处不在，并且通过向量化指令可以大大提高它们的速度。
Beelink配有SSD硬盘，少了一件东西。
Beelink配有底盘、风扇等。我唯一需要做的就是乐高“架子”。

我的家庭实验室基础设施的另一个关键部分是我去年构建的一个TrueNAS服务器。除了拥有70TB的存储(42TB可用)，它还为Grafana米密尔，用于Kubernetes卷的NFS存储，一个Nexus私有Docker注册表，并有用于Pi-Hole (DNS)和Traefik(反向代理)的VM。下图显示了我的家庭实验室配置:

安装Kubernetes

作为Kubernetes的新手，我首先加入了Grafana实验室的#家庭实验室Slack小组，向同事们提问。bob电竞频道埃德·韦尔奇给了我很多好的建议。事实上，在看到他在会议期间后台的5节点RPi集群后，我产生了构建家庭实验室集群的想法。他建议我使用k3s分布，这是针对资源受限节点进行优化的。

在确定了k3之后，我看了很多YouTube视频。就像那句古老的格言，“测量两次，切割一次”，但对于YouTube教程来说，它是“观看三次，部署两次”，因为你肯定会在第一次就出错。有两个渠道特别有用:

电子蒂姆-所有的家庭实验室，k3s培养
娜娜科技世界-所有东西都是k8

我在Beelink节点上安装了一个Ubuntu服务器。然后，我使用下面视频中描述的基于ansible的方法安装一个完全配置的k3s HA集群，其中包含额外的组件，如kube-vip和MetalLB。

kube-vip和MetalLB都解决了我在早期尝试更手动地生成k3时遇到的问题，即在前端使用一个IP来表示集群，在控制平面之间进行负载平衡，并通过LoadBalancer类型将IP分配给服务，以便从集群外部访问它们。

在这一点上，我有一个完全运行的集群，所以我尝试通过Helm图表添加MySQL和MongoDB。实际上，我开始使用MySQL部署是通过使用我之前编写的OpenWeatherMap API从Go程序中填充天气和空气质量数据。

这是在Prometheus和Mimir安装之前集群的样子:

安装普罗米修斯

我决定安装普罗米修斯运营商通过执掌。就像安装k3s一样，安装Prometheus需要多次尝试和重启才能达到我想要的效果。最后我按照这个视频中的步骤做了:

我对默认图表值所做的唯一更改是设置远程写入配置，因为我知道接下来将安装Grafana Mimir。

远程写配置包含:

部署普罗米修斯有两个好处kube-prometheus-stack执掌图:

它预先配置了许多用于监视Kubernetes和节点的导出器和仪表板。它附带一个Grafana吊舱，可以随时查看所有的仪表盘。最后，我用这个豆荚来装咪咪和个人仪表盘。
通过ServiceMonitor配置，很容易添加额外的导出器并让Prometheus获取它们的度量。上面链接的“第2部分”视频讲述了为MongoDB设置该功能的过程。我能够遵循该教程，然后使用相同的过程将MySQL指标添加到Prometheus。Mimir Helm图表还使用ServiceMonitor向Prometheus提供指标。

一旦安装了操作员和其他导出器，我验证了我可以通过端口转发连接到Prometheus和Grafana吊舱并执行一些查询。最后，是格拉芙娜·米米尔上场的时候了。

安装Grafana Mimir

安装Mimir Helm图表是一个简单的两行:

❯helm repo add grafana https://grafana.github.io/helm-charts

❯helm install mimir grafana/mimir-distributed -f mimir.yaml

然而，还是有一些配置细节以覆盖特定于您的集群的值文件。在我的例子中，这些是需要配置的领域:

Prometheus的ServiceMonitor
对象存储
功能和组件数量

ServiceMonitor

让我们从ServiceMonitor开始，因为它是最直接的。下面是值文件中的相关部分。

serviceMonitor: enabled: true namespace: default namespaceSelector: matchNames:—default labels: release: kube-prometheus-stack

这里的关键部分是标签发布:kube-prometheus-stack这使得普罗米修斯的运营商能够发现哪些出口商的服务需要搜刮。根据普罗米修斯的部署方式，这部分可能略有不同。

安装完后，我通过Prometheus界面验证了Mimir指标正在被删除。然后我按照说明书Grafana Mimir文档来构建Mimir仪表板。这产生了一组JSON文件，我可以将其导入到由Prometheus操作符创建的Grafana pod中。

对象存储

可以通过在值文件的mimir->配置部分复制和粘贴完整的多行字符串来更改存储配置，然后根据需要进行更改。对应使用对象存储服务的三个组件，需要配置以下三部分:alertmanager_storage，blocks_storage,ruler_storage．每个过程都是相同的，但我将展示ruler_storage节，因为它很短。

下面是默认的节

{{- if . values .minio。ruer_storage: backend: s3 s3: endpoint: {{. release . enable}}}} -minio名称。{{.Release。名称空间}}。Svc:9000 bucket_name: {{include "mimir. xml "minioBucketPrefix”。}}-尺子access_key_id: {{. values .minio。accessKey}} secret_access_key: {{. values .minio. accessKey。不安全:true {{- end}}

下面是它在我的TrueNAS服务器上为S3桶定制后的样子:

ruler_storage:后端:s3 s3: endpoint: 192.168.4.200:29000 bucket_name: mimir-ruler access_key_id: mimir secret_access_key: NOT_MY_ACTUAL_SECRET_KEY insecure: true

正如您所看到的，我删除了Go模板，并使用在我的TrueNAS服务器中配置的端点、桶名和S3凭据。我配置了三个独立的桶，命名为mimir-alert，mimir-ruler,mimir-tsdb．

在安装Helm图表并等待了一段时间后，我可以看到数据开始从我的对象存储web界面中显示出来:

功能和组件数量

我尝试了启用memcached和摄入器的数量。可以单独启用/禁用前者memcached，memcached-queries,memcached-metadata值文件的部分。最后，我的节点对memcached非常不满。每个节点只有8GB的RAM，根本没有足够的空间。我肯定也不需要memcached，因为我将在系统上设置低负载级别。

组件计数对我来说确实有点神秘，因为我只在笔记本电脑或企业级集群上使用过Mimir。Helm图表回购中有一些很好的模板，可以用于各种大小的集群。为了简单起见，我使用了默认值，到目前为止，它工作得很好，尽管对于我的小集群来说有点过头了。

最后，我让Grafana Mimir在蜂巢上运行起来。

踢轮胎

在浏览了Mimir仪表板并看到对象存储开始被填满之后，我决定创建一个整体状态仪表板。仪表板(下图)显示了Grafana Mimir的总体硬件利用率指标、温度、组件数量和其他基本信息。

除了让我快速查看集群和Mimir的运行状况外，将仪表板移到一边并每30秒刷新一次还会给Mimir增加一些查询负载。(顺便说一句，忽略活动序列号，我的查询是不正确的。)

在撰写本文时，我已经拆除了旧的配置，并尝试使用稍微不同的Prometheus + Grafana Mimir设置。从内存使用情况可以看出，存在不平衡，beehive3同时具有Prometheus操作符和ingester，这是我不喜欢的。这是拥有这样一个家庭实验室集群的最大好处，我可以随意拆毁它并建立它，每次都能学到新东西。