Prometheus Node Exporter在Kubernetes中遭遇AppArmor限制的解决方案

问题背景

在Kubernetes环境中部署Prometheus Node Exporter时，当尝试启用systemd收集器并以非root用户身份运行时，可能会遇到AppArmor策略限制的问题。这个问题表现为无法建立DBus连接，导致systemd指标收集失败。

问题现象

当Node Exporter以非root用户运行时，日志中会出现如下错误信息：

couldn't get dbus connection: An AppArmor policy prevents this sender from sending this message to this recipient; type="method_call", sender="(null)" (inactive) interface="org.freedesktop.DBus" member="Hello" error name="(unset)" requested_reply="0" destination="org.freedesktop.DBus" (bus)

而同样的配置在以root用户运行时则工作正常。这个问题不仅影响Node Exporter的systemd收集器，同样也会影响专门的systemd_exporter。

根本原因分析

该问题的根本原因是Kubernetes节点上运行的containerd默认会为容器应用一个名为"cri-containerd.apparmor.d"的AppArmor策略。这个策略限制了容器内进程与系统DBus服务的通信，而systemd收集器正是通过DBus接口来获取系统服务信息的。

可以通过以下命令验证容器当前的AppArmor配置：

cat /proc/self/attr/apparmor/current

在受限制的容器中，输出会是：

cri-containerd.apparmor.d (enforce)

解决方案

方法一：解除AppArmor限制

最直接的解决方案是修改Pod的安全配置，使容器运行在"unconfined"模式下：

securityContext:
  apparmor.security.beta.kubernetes.io/defaultProfileName: unconfined

应用此配置后，再次检查AppArmor状态应该显示为"unconfined"。

方法二：自定义AppArmor策略

如果出于安全考虑不能完全解除限制，可以创建一个自定义的AppArmor策略，仅允许必要的DBus通信。这需要：

1. 在节点上创建自定义AppArmor策略文件
2. 在Pod定义中引用这个策略

方法三：使用root用户运行

虽然Node Exporter设计为可以非特权用户运行，但在某些严格控制的Kubernetes环境中，临时使用root用户可能是一个可行的变通方案：

securityContext:
  runAsUser: 0

不过，这种方法违背了最小权限原则，不推荐长期使用。

最佳实践建议

1. 评估安全需求：根据实际安全需求选择最合适的解决方案，平衡功能需求和安全要求。

2. 监控配置：在修改AppArmor配置后，确保监控系统能够正确收集所有预期的指标。

3. 文档记录：在团队内部记录这些配置变更，确保所有成员了解这些特殊配置的原因。

4. 定期审查：随着Kubernetes和容器运行时的更新，定期审查这些配置是否仍然必要。

总结

在Kubernetes环境中运行Node Exporter的systemd收集器时，AppArmor策略可能会造成意外的限制。通过理解底层机制并合理配置容器安全上下文，可以解决这一问题，同时保持适当的安全级别。建议优先考虑自定义AppArmor策略的方法，在确保功能可用的同时维持系统的安全性。