集群外Prometheus抓取Kubernetes节点指标报context deadline exceeded求助

你当前是通过kube-apiserver代理的方式拉取节点指标，出现context deadline exceeded错误可按以下优先级排查：

• 第一步：手动验证拉取能力
  先在Prometheus部署的服务器上执行curl命令，模拟Prometheus的拉取请求，确认底层链路是否正常：

# 把<你的token内容>替换成/etc/prometheus/token文件里的实际值，<节点名>替换为集群内实际节点名称
curl -k -H "Authorization: Bearer <你的token内容>" "https://172.16.21.31:443/api/v1/nodes/<节点名>/proxy/metrics"

如果命令执行后返回403，说明你使用的ServiceAccount没有nodes/metrics/proxy的RBAC权限，需要给对应的ServiceAccount绑定包含以下权限的ClusterRole：

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: prometheus-metrics-reader
rules:
- apiGroups: [""]
  resources: ["nodes/metrics", "nodes/proxy"]
  verbs: ["get", "list"]

如果命令执行长时间无响应返回超时，说明要么apiserver转发压力大，要么节点本身返回指标过慢。

• 第二步：调整作业超时时间
  你当前全局的scrape_timeout是30s，走apiserver代理转发的链路比直接拉取节点指标多了一跳，很容易触发超时。可以单独给kubernetes-nodes作业设置更长的超时时间：

- job_name: 'kubernetes-nodes'
  scrape_timeout: 60s # 新增这行，优先级高于全局配置
  kubernetes_sd_configs:            
  - role: node
    kubeconfig_file: /etc/prometheus/dev-zznty9y19-kubeconfig
  # 其余配置保持不变

• 第三步：优化采集链路（推荐）
  走apiserver代理拉取所有节点指标会给apiserver带来额外的转发压力，节点数量超过10个时很容易出现超时。更推荐直接拉取节点kubelet的10250端口指标，修改kubernetes-nodes作业的relabel配置即可：

relabel_configs:
- action: labelmap
  regex: __meta_kubernetes_node_label_(.+)
- target_label: __address__
  source_labels: [__meta_kubernetes_node_address_InternalIP]
  replacement: ${1}:10250 # 直接指向节点的10250端口
- target_label: __metrics_path__
  replacement: /metrics

修改前需要确认Prometheus所在服务器的网络可以访问所有K8s节点的10250端口。

内容的提问来源于stack exchange，提问作者Nguyen Phu Cuong