0

我在集群上部署了 metrics-server。吊舱按预期运行。

kubectl get --raw "/apis/metrics.k8s.io/v1beta1/nodes

返回：

错误：您必须登录到服务器（未经授权）

指标服务器 pod 内的日志如下所示：

I0727 13:33:23.905320       1 serving.go:273] Generated self-signed cert (/tmp/apiserver.crt, /tmp/apiserver.key)                                                                                                                          │
│ [restful] 2019/07/27 13:33:26 log.go:33: [restful/swagger] listing is available at https://:8443/swaggerapi                                                                                                                                │
│ [restful] 2019/07/27 13:33:26 log.go:33: [restful/swagger] https://:8443/swaggerui/ is mapped to folder /swagger-ui/                                                                                                                       │
│ I0727 13:33:26.284542       1 serve.go:96] Serving securely on [::]:8443                                                                                                                                                                   │
│ W0727 13:33:47.904111       1 x509.go:172] x509: subject with cn=kubernetes-proxy is not in the allowed list: [system:auth-proxy]                                                                                                          │
│ E0727 13:33:47.904472       1 authentication.go:62] Unable to authenticate the request due to an error: [x509: subject with cn=kubernetes-proxy is not allowed, x509: certificate signed by unknown authority]

此错误消息看起来像是配置错误的 RBAC 规则，但是我的集群中没有 auth-proxy cluster-role...

cn=kubernetes-proxy 的主题不在允许列表中：[system:auth-proxy]

在某些时候它可能是一个简单的 RBAC 错误配置吗？

设置 --kubelet-insecure-tls 没有帮助

我在 Scaleway 上运行 Ubuntu 的裸机服务器上使用 k3s 版本 0.7.0

4

1 回答 1

2

好的，当我遇到同样的问题时，这是我的研究：

K3S 具有以下 API-server 标志（默认）： --requestheader-allowed-names=system:auth-proxy

我“猜测”这是一个集群角色，但我还不能 100% 确定，因为默认情况下它在 K3S 集群中不存在。查看日志，我发现基本上 API 服务器在抱怨用于识别kubectl top请求的 TLS-cert 中的 CN 是不允许的（也就是 not in system:auth-proxy）。我不知道为什么使用它cn=kubernetes-proxy而不是中提到的帐户~/.kube/config。

无论如何，快速修复如下： 编辑您的/etc/systemd/system/k3s.serviceExecStart 位，如下所示：

ExecStart=/usr/local/bin/k3s \
    server \
    --kube-apiserver-arg="requestheader-allowed-names=system:auth-proxy,kubernetes-proxy"

然后使用 . 运行systemctl daemon-reload并重新启动 K3S systemctl restart k3s。

您现在应该在运行时看到此设置弹出窗口： kubectl get configmap -n kube-system "extension-apiserver-authentication" -o yamlunder: requestheader-allowed-names。

现在你所要做的就是杀死/重新启动你的 metrics-server pod，等待几分钟让它抓取指标（默认情况下每 60 秒一次），你现在应该可以运行kubectl top [pod|node].

因为这对我来说已经足够好了，所以我会把它留在这里，但我很好奇它为什么/如何使用cn=kubernetes-proxy，或者为什么用于识别 CN 的证书没有被requestheader-client-ca-file.

于 2019-07-30T11:21:43.347 回答