主页 / server / 问题 / 1165464
Accepted
Seididieci
Asked: 2024-09-19 21:35:45 +0800 CST

kubernetes metrics-server 从所有节点获取 403

  • 772

我已经使用 Fedora 的本指南创建了一个 kubernetes 集群：https ://docs.fedoraproject.org/en-US/quick-docs/using-kubernetes/

我设置了 1 个控制面板和 1 个工作节点（2 个 libvirt VM），并且能够部署应用程序、入口、运行等等……

我唯一想念的是获取一些指标（kubectl top nodes/ ），所以我尝试使用官方 yaml 文件（ https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yamlkubectl top pods ）安装指标服务器。

然后我编辑了部署以修复添加--kubelet-insecure-tls到参数列表中的 x509 证书错误（这不是生产集群，所以我保留了默认的自签名证书）。

我的问题是度量服务器不工作：在日志中它显示抓取节点错误，因为它在请求资源时得到 403（禁止）：“

I0919 08:32:37.415029       1 dynamic_serving_content.go:132] "Starting controller" name="serving-cert::/tmp/apiserver.crt::/tmp/apiserver.key"
I0919 08:32:37.415090       1 secure_serving.go:213] Serving securely on [::]:10250
I0919 08:32:37.415119       1 tlsconfig.go:240] "Starting DynamicServingCertificateController"
E0919 08:32:37.417167       1 scraper.go:149] "Failed to scrape node" err="request failed, status: \"403 Forbidden\"" node="f40-work1"
E0919 08:32:37.421847       1 scraper.go:149] "Failed to scrape node" err="request failed, status: \"403 Forbidden\"" node="f40main"

我被困在那里，无法弄清楚如何解决这个问题，谷歌也帮不了我......

节点版本：

NAME        STATUS   ROLES                                            AGE     VERSION   INTERNAL-IP       EXTERNAL-IP   OS-IMAGE                           KERNEL-VERSION            CONTAINER-RUNTIME
f40-work1   Ready    metrics-server-aggregated-reader                 2d19h   v1.29.8   192.168.124.128   <none>        Fedora Linux 40 (Server Edition)   6.10.10-200.fc40.x86_64   cri-o://1.28.2
f40main     Ready    control-plane,metrics-server-aggregated-reader   2d20h   v1.29.8   192.168.124.146   <none>        Fedora Linux 40 (Server Edition)   6.10.9-200.fc40.x86_64    cri-o://1.28.2

我用角色标记了两个节点metrics-server-aggregate-reader并尝试修复错误但没有成功......

kubernetes

1 个回答

  1. Best Answer

    到目前为止，只有一种最丑陋的黑客方法对我在 1.24+ k8s 集群版本上起作用（是的，我已经阅读并关注了大量的问题，并尝试了各种方法，包括直接向 metrics-server 作者提问，但对我都不起作用（但是，有些方法似乎对某些人有用））：

    免责声明：请勿关注

    更改--authorization-mode=Webhook为--authorization-mode=AlwaysAllowkubelet 启动环境（基于 redhat 的实例在单元文件中定义它，我更喜欢在/etc/systemd/system/kubelet/service.d中使用插入式配置包含）并重新启动 kubelet。

    这次黑客攻击实际上禁用了 kubelet 服务端口 10250 上的授权，因此任何拥有网络连接的人都可以用它做他能想到的所有肮脏的事情。

    欢迎下方提供任何更优雅的工作解决方案。

    • 1

相关问题