我想在Prometheus服务器之外的GKE集群上进行监视
按照标题所说的事情去做。
不会解释如何使用GKE控制台，kubectl命令或gcloud命令。
前提 – 前提 tí)
GKE（限定公開クラスタ）的有效网络已经获得主节点的批准。可以通过云监控来监视节点自身的CPU、内存等情况。（虽然也考虑了使用节点导出器进行集中管理，但是我在使用AWS云监控时发现，云计算引擎的运行状态最好由云平台提供的监控系统来查看，这样不会出错。）
我想做的事情
由于k8s（GKE）内置的API无法获取每个Pod的CPU使用率等信息，所以我想将kube-state-metrics插入到Prometheus中进行详细观察。
此外，除了在该文章中所提及的方法之外，还可以选择以下方式：
– 使用 Prometheus 的远程读写功能
– 使用 Prometheus 的联邦功能
– 使用 prometheus-to-sd 将 kube-state-metrics 的指标发送到 stackdriver（不再使用 Prometheus）。
有很多可行的策略，取决于要求和操作方式。
不过，这次不是要整合多个群集的状态，所以联邦化似乎有些不同。
他需要的东西
我想要试试k8s内置的API。
目前没有什么事情，但事先安排好后来可能会有各种用途。
我不想为kube-state-metrics创建ingress。
虽然我想在NW内部进行公开，但不希望对外公开。
虽然考虑了内部负载均衡，但是目前的流量不需要进行负载均衡，并且根据目前的情况（2021年4月11日），最低费用似乎是每1小时0.075美元，如果能避免支付，我不想付费。
我想在GCE上独立建立一个Prometheus服务器（希望将其置于集群之外）。
如果考虑最终使用federation进行聚合的情况，我想先组建一个可以从集群外部触及的配置。
我总算搞定了这件事
・使用监视系统的专用节点池，最多只需1台电脑，且附加专用标记以创建
・创建供监视系统使用的namespace、clusterrole、bind、serviceaccount
・将kube-state-metrics部署到专用节点池中
・使用NodePort指定的服务进行关联
・从使用GCE部署的普通Prometheus中通过gce-sd-config进行访问
・通过集群的endpoint、证书和sa token访问k8sAPI
・成功获取了监控指标！
样品，官方文件
以下是一些相关链接：
1. https://github.com/syanhaiD/gke_prac_prom
2. https://github.com/kubernetes/kube-state-metrics/tree/master/examples
3. https://prometheus.io/docs/prometheus/latest/configuration/configuration/
创建一个专用标签附加的监视专用节点池，且最多只有一个CA。
如果在部署了应用程序的池中添加监视系统，考虑到自动缩放等问题，会变得很麻烦，所以我们会专门创建一个不自动增加或减少的节点池。
我们将其命名为“prometheus-pool”作为示例。
此外，为了在prometheus中进行发现时使用，我们会给它附加一个专用标签。
我们将其命名为“kube-state-metrics-tag”作为示例。
创建用于监视系统的namespace、clusterrole、bind和serviceaccount。
既用实务时，我不会像个最强SA那样嗡嗡地操作，但在示例中，我也会正确地创建这些部分。不过，因为官方文件中已经有了适当的示例，所以我并不会遇到太多困难。就示例而言，它们在以下链接中：
https://github.com/syanhaiD/gke_prac_prom/blob/main/k8s/namespace.yaml
https://github.com/syanhaiD/gke_prac_prom/blob/main/k8s/serviceaccount.yaml
https://github.com/syanhaiD/gke_prac_prom/blob/main/k8s/clusterrole.yaml
https://github.com/syanhaiD/gke_prac_prom/blob/main/k8s/clusterrole_binding.yaml
只要在这些部分即可。另外，我之所以创建一个独立的命名空间而不使用kube-system，纯粹是出于个人爱好，所以使用kube-system也没有任何问题。
将kube-state-metrics部署到专用节点池。
由于有正式的部署，所以我认为不会特别困难。以下是示例：
https://github.com/syanhaiD/gke_prac_prom/blob/main/k8s/kube_state_metrics.yaml
关于镜像，在2021年4月11日，gcr.io上的v1.9.5在部署后会出现CrushLoop问题，查看内部发现在执行某些进程时缺少权限，因此我从quay获取了最新的v1系列版本。
在NodePort上绑定的服务
由于我不使用Ingress，所以我会使用NodePort。示例在这里：
https://github.com/syanhaiD/gke_prac_prom/blob/main/k8s/service.yaml
这样。这里也没有特别“独特”的部分，所以应该没有问题。
从集群外的Prometheus服务器进行访问。
不管是使用二进制文件还是使用Docker，启动Prometheus服务器几乎没有任何问题，无需特别说明。
通往k8s API访问的路径
GKE集群终结点可以从GKE控制台获取。
GKE集群证书也可以从GKE控制台获取，但在打开令牌时一次性获取可能更方便。
服务账户令牌是按照示例进行的。
kubectl -n prometheus get serviceaccounts forprom -o yaml
当你敲击它时
secrets:
- name: forprom-token-xxxxxxxxxxx
因为输出的YAML包含这样的元素，
kubectl -n prometheus get secrets forprom-token-xxxxxxxxxxx -o yaml
这将是将结果中的令牌Base64解码后的内容。
将ca.crt进行Base64解码后，您将看到类似于GKE控制台中的证书。
将解码结果保存为文件，并在prometheus服务器上使用。
tls_config和authorization在kubernetes_sd_configs的内部和外部分别需要一个。
虽然可能还会有一些预测，但是在指定的示例中处理流程如下。
-
- 在kubernetes_sd_configs中指定的tls_config和authorization用于经过api_server的认证访问并发现监控目标。Prometheus将从发现的对象的私有IP地址获取指标（在这种情况下，我认为是控制平面的私有IP地址）。
-
- 由于控制平面的私有IP地址无法从集群外访问，需要通过relabel进行替换，让其访问公共IP的/metrics端点。
- kubernetes_sd_configs中指定的tls/auth是在发现时使用的，在抓取时不会被使用。因此，通过在relabel_configs的同一级别上进行定义，可以确保在抓取时也传递认证信息。
我认为可能会变成那种感觉。虽然仍然感到有些复杂，但希望在进行网络爬取时能够指定与发现模块相同的认证信息，这样就可以实现这个选项。
kube-state-metrics节点之路
这个没有什么需要解释的。因为我们是通过NodePort进行关联的，只需要在gce_sd_configs中正常发现即可。
如果要注意一点的话，原始状态下，由于权限不足，Prometheus无法获取到GCE的列表，所以需要将具有查看GCE以上权限的服务帐号提供给Prometheus服务器实例，或者按照https://prometheus.io/docs/prometheus/latest/configuration/configuration/#gce_sd_config中所述，设置环境变量或将JSON文件放置在指定位置。
指标达到了，太棒了！！
呀！
