<p>I deployed metrics-server on my cluster. the pods are running as expected.</p>

<p><code>kubectl get --raw "/apis/metrics.k8s.io/v1beta1/nodes</code> </p>

<p>return:</p>

<blockquote>
  <p>error: You must be logged in to the server (Unauthorized)</p>
</blockquote>

<p>the logs inside metrics server pods are like this:</p>

<pre><code>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]
</code></pre>

<p>This error message looks like a misconfigured RBAC rule, however there is no auth-proxy cluster-role in my cluster...</p>

<blockquote>
  <p>subject with cn=kubernetes-proxy is not in the allowed list:
  [system:auth-proxy]</p>
</blockquote>

<p>Can it be a simple RBAC misconfiguration at some point?</p>

<p>Setting up --kubelet-insecure-tls does'nt help</p>

<p>I am using k3s version 0.7.0 on baremetals server running Ubuntu at Scaleway</p>

Duduche
<p>Ok, so here's my research when I encountered the same issue:</p>

<p>K3S has the following API-server flag (default):
<code>--requestheader-allowed-names=system:auth-proxy</code></p>

<p>I'm 'guessing' this is a cluster role but I'm not 100% sure yet since it doesn't exist within the K3S cluster by default. Looking at the logs I found that basically the API server is complaining that the CN in the TLS-cert used to identify the <code>kubectl top</code> request is not allowed (aka not in <code>system:auth-proxy</code>). Why it's using <code>cn=kubernetes-proxy</code> instead of the account mentioned in <code>~/.kube/config</code> is unknown to me.</p>

<p>Anyhow, the quick fix is as follows:
Edit your <code>/etc/systemd/system/k3s.service</code> ExecStart-bit to look like the following:</p>

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

<p>Then run <code>systemctl daemon-reload</code> and restart K3S using <code>systemctl restart k3s</code>.</p>

<p>You should now see this setting pop-up in when you run:
<code>kubectl get configmap -n kube-system "extension-apiserver-authentication" -o yaml</code> under: <code>requestheader-allowed-names</code>.</p>

<p>Now all you have to do is kill/restart your metrics-server pod, wait for a few minutes for it to scrape metrics (by default every 60s), and you should now be able to run <code>kubectl top [pod|node]</code>.</p>

<p>Since this is good enough for me I'll leave it here, but I am damn curious as to why/how it's using <code>cn=kubernetes-proxy</code> or why the cert used to identify that CN isn't signed by <code>requestheader-client-ca-file</code>.</p>
