Prometheus无法抓取Kubernetes指标

bnlyeluc  于 2023-10-17  发布在  Kubernetes
关注(0)|答案(3)|浏览(201)

我使用kubeadm设置了一个kubernetes集群。然后我使用社区Helm图表在上面部署了Prometheus。我注意到prometheus不能从调度器、etcd或控制器管理器中抓取指标。
例如,我看到这样的错误:

Get "https://192.168.3.83:10259/metrics": dial tcp 192.168.3.83:10259: connect: connection refused

我得到这些错误的原因是因为实际上在https://192.168.3.83:10259/metrics上没有监听。这是因为kube-scheduler将--bind-address设置为127.0.0.1
解决这个问题的一种方法是手动编辑/etc/kubernetes/manifests中的manifest文件,将--bind-address更改为0.0.0.0
当我这样做的时候,普罗米修斯就能够获得这些指标。
然而,这是正确的解决方案吗?我假设这些清单文件实际上是由kubernetes本身管理的,我可能不应该直接编辑它们,而应该做其他事情。但是什么?
edit:我注意到我对manifest文件所做的更改在升级时确实会被覆盖。现在我又失去了etcd和其他指标。
我肯定漏掉了什么明显的东西。
我想也许改变“clusterconfiguration”Map表就可以了。但如果你能做到这一点(以及你应该如何做到这一点)是没有记录在任何地方。
我有一个开箱即用的kubernetes和开箱即用的prometheus,它不收集指标。我不可能是唯一一个卷入这个问题的人。真的没有解决办法吗?

kdfy810k

kdfy810k1#

暴露kube-scheduler、etcd或kube-controller manager(并持久化更改)

您可以在www.example.com上公开这些指标0.0.0.0就像您通过编辑XMLMap然后将这些更改拉到每个控制平面节点所做的那样。这些更改将在升级过程中保持不变。对于etcd,这也可以用另一种更好的方式来完成(见下文)

第一步:用下面的命令编辑Map:

kubectl edit -n kube-system cm/kubeadm-config

按照here所述添加/更改相关绑定地址,但以etcd为例,如下所示:

kind: ClusterConfiguration
etcd:
  local:
    extraArgs:
      listen-metrics-urls: http://0.0.0.0:2381

第二步:* 注意:* 请阅读此处以了解升级命令 *,然后再 * 将其应用于您关心的任何群集,因为它也可能更新群集组件版本,除非您刚刚进行了升级:)

因此,为了反映更改,您需要在每个控制平面节点上运行kubeadm upgrade node(请一次运行一个..)这将关闭受影响的pod(您对其进行了更改的pod),并启动一个新的示例,其中暴露了指标。您可以使用以下示例验证之前和之后:netstat -tulpn | grep etcd
对于etcd,Prometheus中的默认端口是2379,因此还需要在prometheus值文件中将其调整为2381

kubeEtcd:
  service:
    port: 2381
    targetPort: 2381

上述解决方案的来源在这里

删除现有的etcd指标,不进一步暴露

对于ETCD指标,还有第二种可能是首选的访问指标的方法,即使用端口2379上已经公开的https 指标端点(需要身份验证)。你可以用Curl验证这一点:

curl https://<your IP>:2379/metrics -k --cert /etc/kubernetes/pki/etcd/healthcheck-client.crt --key /etc/kubernetes/pki/etcd/healthcheck-client.key

为此,我们需要为Prometheus提供正确的证书,作为Kubernetes中的秘密。此处描述的步骤和概述如下:
在部署Prometheus的名称空间中创建一个secret。

kubectl -n monitoring create secret generic etcd-client-cert --from-file=/etc/kubernetes/pki/etcd/ca.crt --from-file=/etc/kubernetes/pki/etcd/healthcheck-client.crt --from-file=/etc/kubernetes/pki/etcd/healthcheck-client.key

将以下内容添加到您的prometheus helm值文件

prometheus:
  prometheusSpec:
    secrets: ['etcd-client-cert']

kubeEtcd:
  serviceMonitor:
   scheme: https
   insecureSkipVerify: false
   serverName: localhost
   caFile: /etc/prometheus/secrets/etcd-client-cert/ca.crt
   certFile: /etc/prometheus/secrets/etcd-client-cert/healthcheck-client.crt
   keyFile: /etc/prometheus/secrets/etcd-client-cert/healthcheck-client.key

Prometheus现在应该能够使用我们在secret中安装的证书访问https端点。我认为这是etcd的首选方式,因为我们不会进一步公开开放的http端点。

v7pvogib

v7pvogib2#

当我在AWS上部署我的设置时,我遇到了同样的错误,其中包括三个节点,其中主节点(控制平面)和私有工作节点位于私有子网中,而公共工作节点位于公共子网中。我从source创建了一个HAproxy,并对直通配置进行了修改以使其工作:

apiVersion: v1
kind: ConfigMap
metadata:
  name: metrics-proxy-master
data:
  haproxy.cfg: |
    defaults
      mode http
      timeout connect 5000ms
      timeout client 5000ms
      timeout server 5000ms
      default-server maxconn 10

    frontend kube-controller-manager
      bind ${NODE_IP}:10257
      mode tcp
      option tcplog
      http-request deny if !{ path /metrics }
      default_backend kube-controller-manager
    backend kube-controller-manager
      mode tcp
      server kube-controller-manager 127.0.0.1:10257 check

    frontend kube-scheduler
      bind ${NODE_IP}:10259
      mode tcp
      option tcplog
      http-request deny if !{ path /metrics }
      default_backend kube-scheduler
    backend kube-scheduler
      mode tcp
      server kube-scheduler 127.0.0.1:10259 check

    frontend etcd
      bind ${NODE_IP}:2381
      http-request deny if !{ path /metrics }
      default_backend etcd
    backend etcd
      server etcd 127.0.0.1:2381

---
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: metrics-proxy-master
spec:
  selector:
    matchLabels:
      app: metrics-proxy-master
  template:
    metadata:
      labels:
        app: metrics-proxy-master
    spec:
      hostNetwork: true
      serviceAccountName: default
      nodeSelector:
        node-role.kubernetes.io/control-plane: ""
      tolerations:
        - effect: NoSchedule
          key: node-role.kubernetes.io/control-plane
          operator: Exists
      containers:
        - name: haproxy
          image: haproxy:2.2.8
          env:
            - name: NODE_IP
              valueFrom:
                fieldRef:
                  apiVersion: v1
                  fieldPath: status.hostIP
          ports:
            - name: kube-ctrl-mgr  # Port names are limited to 15 characters
              containerPort: 10257
            - name: kube-scheduler
              containerPort: 10259
            - name: etcd
              containerPort: 2381
          volumeMounts:
            - mountPath: /usr/local/etc/haproxy
              name: haproxy-config
      volumes:
        - configMap:
            name: metrics-proxy-master
          name: haproxy-config

然后应用kubectl apply -f haproxy.yaml

mbskvtky

mbskvtky3#

对于那些使用minikube进行测试的人-
没有足够的代表,否则我会对阿皮森的回答发表评论,这对我很有效。但是我使用的是minikube,所以我必须调整minikube的start语句,添加以下内容来公开etcd指标(相当于kubectl edit -n kube-system cm/kubeadm-config中的更新)。
最后一行是相关的添加(这与我在官方文档中找到的不同- prometheus operator - kube-prometheus

minikube start --kubernetes-version=v1.23.0 \
--memory=6g \
--bootstrapper=kubeadm \
--extra-config=kubelet.authentication-token-webhook=true \
--extra-config=kubelet.authorization-mode=Webhook \
--extra-config=scheduler.bind-address=0.0.0.0 \
--extra-config=controller-manager.bind-address=0.0.0.0 \
--extra-config=etcd.listen-metrics-urls=http://0.0.0.0:2381

希望这有帮助

相关问题