具有多个kube-state-metric实例的重复度量

时间:2020-01-14 11:33:47

标签: kubernetes monitoring devops prometheus kube-state-metrics

问题

从普罗米修斯查询 kube-state-metrics 中的度量时,数据重复。

运行3个 kube-state-metrics 实例的示例查询和结果:

查询:

kube_pod_container_resource_requests_cpu_cores{namespace="ns-dummy"}

指标

kube_pod_container_resource_requests_cpu_cores{container="appname",endpoint="http",instance="172.232.35.142:8080",job="kube-state-metrics",namespace="ns-dummy",node="ip-172-232-34-25.ec2.internal",pod="app1-appname-6bd9d8d978-gfk7f",service="prom-kube-state-metrics"}
1
kube_pod_container_resource_requests_cpu_cores{container="appname",endpoint="http",instance="172.232.35.142:8080",job="kube-state-metrics",namespace="ns-dummy",node="ip-172-232-35-22.ec2.internal",pod="app2-appname-ccbdfc7c8-g9x6s",service="prom-kube-state-metrics"}
1
kube_pod_container_resource_requests_cpu_cores{container="appname",endpoint="http",instance="172.232.35.17:8080",job="kube-state-metrics",namespace="ns-dummy",node="ip-172-232-34-25.ec2.internal",pod="app1-appname-6bd9d8d978-gfk7f",service="prom-kube-state-metrics"}
1
kube_pod_container_resource_requests_cpu_cores{container="appname",endpoint="http",instance="172.232.35.17:8080",job="kube-state-metrics",namespace="ns-dummy",node="ip-172-232-35-22.ec2.internal",pod="app2-appname-ccbdfc7c8-g9x6s",service="prom-kube-state-metrics"}
1
kube_pod_container_resource_requests_cpu_cores{container="appname",endpoint="http",instance="172.232.37.171:8080",job="kube-state-metrics",namespace="ns-dummy",node="ip-172-232-34-25.ec2.internal",pod="app1-appname-6bd9d8d978-gfk7f",service="prom-kube-state-metrics"}
1
kube_pod_container_resource_requests_cpu_cores{container="appname",endpoint="http",instance="172.232.37.171:8080",job="kube-state-metrics",namespace="ns-dummy",node="ip-172-232-35-22.ec2.internal",pod="app2-appname-ccbdfc7c8-g9x6s",service="prom-kube-state-metrics"}

观察

当为 kube-state-metrics 运行N个Pod时,每个指标都将上升Nx。如果是单个Pod,我们将获得正确的信息。

可能的解决方案

  1. 按比例缩小到kube-state-metrics的单个实例。 (降低可用性是一个问题)
  2. 启用分片。 (解决了重复问题,但仍然较少)

根据docs,对于水平缩放,我们必须将分片参数传递给Pod。

碎片是零索引的。因此,我们必须传递每个Pod的索引和分片总数。

我们正在使用Helm chart,并且已将其部署为部署。

问题

  1. 在可能的情况下,如何在这种情况下将不同的参数传递给不同的容器?
  2. 考虑到k8负载的自我修复特性,我们是否应该担心 kube-state-metrics 的可用性?
  3. 我们什么时候应该真正将其扩展到多个实例?

1 个答案:

答案 0 :(得分:0)

如果容器关闭,则可以仅对kube-state-metric的单个副本使用“自我修复”部署,该部署将启动一个新容器。由于kube-state-metric is not focused on the health of the individual kubernetes components。如果您的群集太大并且每秒更改许多对象,它只会影响您。

它不专注于单个Kubernetes组件的运行状况,而是关注内部各种对象(例如部署,节点和pod)的运行状况。

对于小型集群,使用这种方式没有问题,但是您确实需要一个高可用性监视平台,我建议您看一下以下两篇文章: creating a well designed and highly available monitoring stack for kuberneteskubernetes monitoring