Сервер метрик не может аутентифицировать запрос из-за ошибки сертификата

Question

Я развернул metrics-сервер в своем кластере. стручки работают как положено.

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

вернуть:

ошибка: Вы должны войти в систему на сервере (не авторизовано)

журналы внутри модулей сервера метрик выглядят так:

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...

субъект с cn=kubernetes-proxy отсутствует в списке разрешенных: [system:auth-proxy]

Может ли это быть простая неправильная конфигурация RBAC в какой-то момент?

Настройка --kubelet-insecure-tls не помогает

Я использую K3S версии 0.7.0 на сервере baremetals под управлением Ubuntu в Scaleway

Answer 1

Итак, вот мое исследование, когда я столкнулся с той же проблемой:

K3S имеет следующий флаг API-сервера (по умолчанию):--requestheader-allowed-names=system:auth-proxy

Я предполагаю, что это роль кластера, но я еще не уверен на 100%, поскольку по умолчанию она не существует в кластере K3S. Просматривая журналы, я обнаружил, что в основном сервер API жалуется на то, что CN в TLS-сертификате используется для идентификации kubectl top запрос не разрешен (иначе не в system:auth-proxy). Почему он использует cn=kubernetes-proxy вместо учетной записи, упомянутой в ~/.kube/config мне неизвестно.

В любом случае, быстрое решение заключается в следующем: /etc/systemd/system/k3s.service ExecStart-bit выглядит следующим образом:

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 yaml под: requestheader-allowed-names,

Теперь все, что вам нужно сделать, это убить / перезапустить модуль метрик-сервера, подождать несколько минут, пока он очистит метрики (по умолчанию каждые 60 с), и теперь вы сможете запускать kubectl top [pod|node],

Поскольку это достаточно хорошо для меня, я оставлю это здесь, но мне чертовски любопытно, почему / как он использует cn=kubernetes-proxy или почему сертификат используется для идентификации того, что CN не подписан requestheader-client-ca-file,