我在这里需要一点帮助。我有一个正在运行的 Kubernetes 集群，还有一台专用的机器用于监控，上面运行着 Prometheus。我已经运行了节点导出器并抓取了机器级指标，例如 CPU、内存、文件系统等。
但我仍然对如何继续感到困惑。我只是尝试将 Kubernetes 元素集成到 Prometheus 中（我从服务开始）。（基本）抓取配置和服务帐户（令牌）没有太大问题。我的问题如下。
最重要的是：我想知道为什么基本上每个人的首选策略都是在他们想要监控的同一个集群内运行 Prometheus？对我来说，这感觉是一个非常糟糕的主意。我错过了什么？我的意思是，对我来说，逻辑很简单：如果我的 Kubernetes 出现故障（无论出于何种原因），监控（包括警报）也会随之中断，我认为应该避免这种情况。
目前，我尝试包括对 Kubernetes 服务的监控（作为开始）。但它们都关闭了，因为 Prometheus 无法访问诸如 之类的地址
http://argo-server.argo.svc:2746/metric。至少这证明了 Prometheus 可以成功地与 Kubernetes API 通信（所以这很好），但这也意味着，即使 Prometheus 本身也希望在 Kubernetes 内部运行，因为这些地址只能从内部访问（这将循环关闭到点 1）。我还偶然发现了一种称为“代理模式”的东西。我还不确定这是否能解决我的问题。考虑到“代理模式”（以及对其工作原理的模糊理解），我可以想到一种场景，即我在 Kubernetes 集群中以代理模式部署 Prometheus。它的唯一工作是充当真正的 Prometheus 的某种代理，后者在集群外以服务器模式运行。似乎还可以将其配置为基本上将指标推送到另一个 Prometheus 服务器，这与 Prometheus 的仅拉取策略有点冲突。那么，这种设计可行吗？这是一个好主意吗？
所以基本上我需要输入将 Prometheus 放在哪里（集群内部还是外部），以及为什么？还有一些关于收集 Kubernetes 指标并将其带入集群外部的 Prometheus 的良好策略的线索。