一旦安装了kube-prometheus，使用kubectl top node时会出现错误

3 年 ago
逸, 科
2 minutes

首先

从启用了指标的kubespray状态中将其删除，并引入了kube-prometheus。

由于 v0.12.0 kube-prometheus 的错误，导致“kubectl top node”命令无法运行，因此我将记录下其经过。

环境

    • kubespray v2.21.0 (kubernetes: v1.25.6)

 

    kube-prometheus v0.12.0

请查看相关资料

    • GitHub Issues #926 – Document guidance to remove metrics-server before installing kube-prometheus

GitHub Issues #1764 – prometheus-adapter: failed querying node metrics

准备工作

如果在kubespray的addons.yml中启用了metrics-server，则如何处理将在下一节中进行说明。

如果您还使用其他方法或包来安装了node-exporter，则需要在安装kube-prometheus之前将其卸载，以避免冲突。

$ sudo apt remove prometheus-node-exporter

改变的地方

kube-prometheus導入之前的準備工作

如果已经安装了metrics-server，则按照以下步骤进行删除。
如果没有安装，请跳过并继续安装kube-prometheus。

#!/bin/bash

sudo kubectl delete service/metrics-server -n  kube-system
sudo kubectl delete deployment.apps/metrics-server  -n  kube-system
sudo kubectl delete apiservices.apiregistration.k8s.io v1beta1.metrics.k8s.io
sudo kubectl delete clusterroles.rbac.authorization.k8s.io system:aggregated-metrics-reader
sudo kubectl delete clusterroles.rbac.authorization.k8s.io system:metrics-server 
sudo kubectl delete clusterrolebinding metrics-server:system:auth-delegator
sudo kubectl delete clusterrolebinding system:metrics-server          
sudo kubectl delete rolebinding metrics-server-auth-reader -n kube-system 
sudo kubectl delete serviceaccount metrics-server -n kube-system

请确保不要删除与任务无关的资源。

如果使用kubespray的addons.yml来安装metrics-server，相关的YAML文件会被放置在node1的/etc/kubernetes/addons/metrics_server/目录下，因此我认为可以使用它。

$ sudo kubectl delete -f /etc/kubernetes/addons/metrics_server/

kube-prometheus安装后的工作

导入过程的步骤已经在另一篇文章中进行了总结，本文则提供了解决方案。

    Qiita – kube-prometheusをjsonnet-builderでカスタマイズした時の対応メモ

在此处引入后出现了以下错误。

$ sudo kubectl top node
error: metrics not available yet

为了解决这个问题，需要像参考资料中提到的第1764步骤那样，允许来自adapter的通信到promethes的networkpolicy。

$ sudo kubectl -n monitoring  edit networkpolicy prometheus-k8s

当编辑器启动后，您可以复制grafana的定义，并添加kube-prometheus。

  - from:
    - podSelector:
        matchLabels:
          app.kubernetes.io/name: prometheus-adapter
    ports:
    - port: 9090
      protocol: TCP

前后的差异如下。

--- a.yaml      2023-03-15 05:04:40.490062834 +0000
+++ b.yaml      2023-03-15 05:04:31.238491762 +0000
@@ -36,6 +36,13 @@
     ports:
     - port: 9090
       protocol: TCP
+  - from:
+    - podSelector:
+        matchLabels:
+          app.kubernetes.io/name: prometheus-adapter
+    ports:
+    - port: 9090
+      protocol: TCP
   podSelector:
     matchLabels:
       app.kubernetes.io/component: prometheus

这样kubectl top应该会开始工作了。

尽管顶部节点有对应的对策，但顶部的Pod出现了错误。

如果我们能通过此处的处理进行改善就好了，但是我们遇到了一个现象，即使顶部节点会有反应，但顶部节点下的子节点却无法运行。

$ sudo kubectl top node
NAME    CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%
node1   1234m        15%    7260Mi          24%
node2   682m         17%    7056Mi          45%
node3   697m         17%    3785Mi          24%
node4   790m         19%    6700Mi          42%

$ sudo kubectl -n monitoring top pod
error: Metrics not available for pod monitoring/alertmanager-main-0, age: 36m15.420243139s

以下是可能相关的报告：
– 可能涉及的报告如下。
– 与此相关的报告可能有以下内容。
– 下列是可能相关的报告。

    • https://stackoverflow.com/questions/71692797/prometheus-adapter-unable-to-fetch-cpu-metrics-for-pod-podname-skipping

 

    • https://github.com/kubernetes-sigs/prometheus-adapter/issues/496

 

    • https://github.com/kubernetes-sigs/prometheus-adapter/issues/385

 

    https://github.com/prometheus-operator/kube-prometheus/issues/926

对原因的调查

当使用”Metrics not available for pod”进行搜索时，有以下的Issues在metrics-server中进行了报告。

    https://github.com/kubernetes-sigs/metrics-server/issues/1061

这是为metrics-server而设计的，与kube-state-metrics没有直接关系，但有人指出dockershim可能存在问题。

通过将 cri-dockerd 更改为 containerd，我们可以确认 kubespray 的行为变化。

在kubespray中，提供了从dockerd迁移到containerd的迁移指南。

    https://github.com/kubernetes-sigs/kubespray/blob/master/docs/upgrades/migrate_docker2containerd.md

由于这个结果，顶级Pod成功运行了。

$ sudo kubectl top pod -A

NAMESPACE        NAME                                              CPU(cores)   MEMORY(bytes)
ingress-nginx    ingress-nginx-controller-2whld                    1m           120Mi
ingress-nginx    ingress-nginx-controller-4p7fb                    1m           123Mi
ingress-nginx    ingress-nginx-controller-6p2ft                    1m           122Mi
ingress-nginx    ingress-nginx-controller-zdqv4                    2m           165Mi
kube-system      calico-kube-controllers-75748cc9fd-5cks7          4m           22Mi 
kube-system      calico-node-gq89c                                 50m          136Mi
kube-system      calico-node-m74b8                                 40m          141Mi
kube-system      calico-node-qrz8x                                 35m          133Mi

节点的更改是逐台进行的，但是结果现在从被替换为containerd的节点返回。

目前我还无法确认从cri-dockerd转移到containerd时可能出现了哪些具体问题，但目前似乎有一种解决办法是从dockerd迁移到containerd。

以上

bannerAds