由于证书错误,指标服务器无法验证请求
metrics-server unable to authenticate the request due to certificate error
我在集群上部署了 metrics-server。 pods 是预期的 运行。
kubectl get --raw "/apis/metrics.k8s.io/v1beta1/nodes
return:
error: You must be logged in to the server (Unauthorized)
metrics server pods 中的日志是这样的:
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...
subject with cn=kubernetes-proxy is not in the allowed list:
[system:auth-proxy]
会不会是某个时候简单的 RBAC 配置错误?
设置 --kubelet-insecure-tls 没有帮助
我在 baremetals 服务器上使用 k3s 版本 0.7.0 运行 Ubuntu 在 Scaleway
好的,这是我遇到同样问题时的研究:
K3S 具有以下 API-服务器标志(默认):
--requestheader-allowed-names=system:auth-proxy
我'guessing'这是一个集群角色,但我还不能 100% 确定,因为默认情况下它不存在于 K3S 集群中。查看日志,我发现基本上 API 服务器抱怨 TLS 证书中用于识别 kubectl top
请求的 CN 是不允许的(也就是不在 system:auth-proxy
中)。我不知道为什么它使用 cn=kubernetes-proxy
而不是 ~/.kube/config
中提到的帐户。
无论如何,快速修复如下:
将您的 /etc/systemd/system/k3s.service
ExecStart 位编辑为如下所示:
ExecStart=/usr/local/bin/k3s \
server \
--kube-apiserver-arg="requestheader-allowed-names=system:auth-proxy,kubernetes-proxy"
然后运行systemctl daemon-reload
并使用systemctl restart k3s
重启K3S。
您现在应该会在 运行 中看到此设置弹出窗口:
kubectl get configmap -n kube-system "extension-apiserver-authentication" -o yaml
下:requestheader-allowed-names
.
现在你所要做的就是 kill/restart 你的 metrics-server pod,等待几分钟让它抓取指标(默认情况下每 60 秒一次),你现在应该可以 运行 kubectl top [pod|node]
.
因为这对我来说已经足够好了,所以我会把它留在这里,但我很好奇 why/how 它正在使用 cn=kubernetes-proxy
或者为什么用于识别 CN 的证书不是requestheader-client-ca-file
.
签名
我在集群上部署了 metrics-server。 pods 是预期的 运行。
kubectl get --raw "/apis/metrics.k8s.io/v1beta1/nodes
return:
error: You must be logged in to the server (Unauthorized)
metrics server pods 中的日志是这样的:
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...
subject with cn=kubernetes-proxy is not in the allowed list: [system:auth-proxy]
会不会是某个时候简单的 RBAC 配置错误?
设置 --kubelet-insecure-tls 没有帮助
我在 baremetals 服务器上使用 k3s 版本 0.7.0 运行 Ubuntu 在 Scaleway
好的,这是我遇到同样问题时的研究:
K3S 具有以下 API-服务器标志(默认):
--requestheader-allowed-names=system:auth-proxy
我'guessing'这是一个集群角色,但我还不能 100% 确定,因为默认情况下它不存在于 K3S 集群中。查看日志,我发现基本上 API 服务器抱怨 TLS 证书中用于识别 kubectl top
请求的 CN 是不允许的(也就是不在 system:auth-proxy
中)。我不知道为什么它使用 cn=kubernetes-proxy
而不是 ~/.kube/config
中提到的帐户。
无论如何,快速修复如下:
将您的 /etc/systemd/system/k3s.service
ExecStart 位编辑为如下所示:
ExecStart=/usr/local/bin/k3s \
server \
--kube-apiserver-arg="requestheader-allowed-names=system:auth-proxy,kubernetes-proxy"
然后运行systemctl daemon-reload
并使用systemctl restart k3s
重启K3S。
您现在应该会在 运行 中看到此设置弹出窗口:
kubectl get configmap -n kube-system "extension-apiserver-authentication" -o yaml
下:requestheader-allowed-names
.
现在你所要做的就是 kill/restart 你的 metrics-server pod,等待几分钟让它抓取指标(默认情况下每 60 秒一次),你现在应该可以 运行 kubectl top [pod|node]
.
因为这对我来说已经足够好了,所以我会把它留在这里,但我很好奇 why/how 它正在使用 cn=kubernetes-proxy
或者为什么用于识别 CN 的证书不是requestheader-client-ca-file
.