ClusterPodMonitring定义了如何抓取集群中所有有标签的pod监视器。在kubernetes集群中，我们应该在什么命名空间中定义这个CR。什么是最佳实践?
我在某处读到它被使用"这个资源是一个专门用于集群范围的度量(比如kube-state-metrics)的工具"。为什么在这种情况下我们不能使用PodMonitoring?
https://github.com/GoogleCloudPlatform/prometheus-engine/blob/v0.3.1/doc/
PodMonitoring与ClusterPodMonitoring基本相同。它们只是在CustomResourceDefinition中的spec.scope不同，就像你可以在GitHub repo中看到的那样。后者是集群范围的定义，而PodMonitoring是命名空间的。根据您的需要，您可以自由地选择使用哪一个-要么您想要每个命名空间分开您的刮刀作业，要么您不想。
ClusterPodMonitoring资源可以在集群中的所有名称空间中发现目标，因此最佳实践是在它自己的名称空间中生成它，例如命名为monitoring。
PodMonitoring资源只能在自己的命名空间中发现目标。
进一步，这取决于你想要哪些标签与(Cluster)PodMonitoring.spec.selector匹配。在所有集群中保持一致总是一个好主意，如果使用集群范围或名称空间监视则是独立的。
tldr;kubernetes中的CRD可以在作用域Namespaced或Cluster(k8s docs)中定义，定义它们可以访问哪些资源。Google通过ClusterPodMonitoring做到了这一点。