x509: сертификат, подписанный неизвестным центром метрик-сервером

Я новичок в kubernetes, и я наконец понял, как запустить сервер метрик как задокументированный https://github.com/kubernetes-sigs/metrics-server. В случае, если кто-то еще задается вопросом, вам необходимо выполнить развертывание на главном узле, а также иметь как минимум одного рабочего в кластере.

Итак, я получаю эту ошибку:

E0818 15:25:22.835094       1 manager.go:111] unable to fully collect metrics: [unable to fully scrape metrics from source kubelet_summary:<hostname-master>: unable to fetch metrics from Kubelet <hostname-master> (<hostname-master>): Get https://<hostname-master>:10250/stats/summary?only_cpu_and_memory=true: x509: certificate signed by unknown authority, unable to fully scrape metrics from source kubelet_summary:<hostname-worker>: unable to fetch metrics from Kubelet <hostname-worker> (<hostname-worker>): Get https://<hostname-worker>:10250/stats/summary?only_cpu_and_memory=true: x509: certificate signed by unknown authority]

Я использую свои собственные центры сертификации (не самоподписанные), и я изменил файл components.yml (образец):

args:
  - --cert-dir=/tmp/metricsServerCas
  - --secure-port=4443
  - --kubelet-preferred-address-types=Hostname

Я знаю, что могу отключить tls с помощью этого флага --kubelet-insecure-tlsЯ уже пробовал. Я хочу использовать свои собственные центры сертификации для дополнительной безопасности.

У меня есть много других вопросов (несколько примеров), например:

сертификат x509, подписанный неизвестным органом - Kubernetes и kubectl не могут подключиться к серверу: x509: сертификат, подписанный неизвестным органом

Хотя это я уже применил chown, мой $HOME/.kube/config все еще вижу эту ошибку.

Где я ошибаюсь?

Обновление: на работнике я создаю каталог, например/tmp/ca и я добавляю файл (ы) ca в каталог.

Я еще не очень хорошо разбираюсь в точках крепления и предполагаю, что что-то делаю не так. Синтаксис изображений по умолчанию можно найти здесь https://github.com/kubernetes-sigs/metrics-server/releases/tag/v0.3.7 (см. Файл components.yml).

Я попытался создать каталог на моем рабочем столе, например /tmp/ca, и изменил флаг --cert-dir=/tmp/ca а также mountPath: /tmp/ca

Когда я развертываю файл, например:

kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/download/v0.3.7/components.yaml

Я все время получаю сообщение об ошибке от metrics-server-xxxx:

panic: open /tmp/client-ca-file805316981: read-only file system

Хотя я дал полный доступ к каталогу, например:

$ ls -la /tmp/ca
total 8
drwxr-xr-x.  2 user user   20 Aug 19 16:59 .
drwxrwxrwt. 18 root        root        4096 Aug 19 17:34 ..
-rwxr-xr-x.  1 user user 1025 Aug 19 16:59 ca.crt

Я не уверен, что ошибаюсь.

Как это должно быть настроено, чтобы кто-то мог использовать несамоподписанные сертификаты? Я вижу, что большинство людей используют не SSL, чего я бы хотел избежать.

Пример моих аргументов на изображении:

spec:
  selector:
    matchLabels:
      k8s-app: metrics-server
  template:
    metadata:
      name: metrics-server
      labels:
        k8s-app: metrics-server
    spec:
      serviceAccountName: metrics-server
      volumes:
      # mount in tmp so we can safely use from-scratch images and/or read-only containers
      - name: tmp-dir
        emptyDir: {}
      containers:
      - name: metrics-server
        image: k8s.gcr.io/metrics-server/metrics-server:v0.3.7
        imagePullPolicy: IfNotPresent
        args:
          - --cert-dir=/tmp/ca
          - --secure-port=4443
          - --kubelet-preferred-address-types=Hostname
        ports:
        - name: main-port
          containerPort: 4443
          protocol: TCP
        securityContext:
          readOnlyRootFilesystem: true
          runAsNonRoot: true
          runAsUser: 1000
        volumeMounts:
        - name: tmp-dir
          mountPath: /tmp/ca
      nodeSelector:
        kubernetes.io/os: linux
        kubernetes.io/arch: "amd64"

Обновление 2: добавление команды curl от мастера к рабочему, включая вывод ошибки:

$ curl --cacert /etc/kubernetes/pki/ca.crt https://node_hostname:10250/stats/summary?only_cpu_and_memory=true
curl: (60) Peer's certificate issuer has been marked as not trusted by the user.
More details here: http://curl.haxx.se/docs/sslcerts.html

curl performs SSL certificate verification by default, using a "bundle"
 of Certificate Authority (CA) public keys (CA certs). If the default
 bundle file isn't adequate, you can specify an alternate file
 using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
 the bundle, the certificate verification probably failed due to a
 problem with the certificate (it might be expired, or the name might
 not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
 the -k (or --insecure) option.

3 ответа

Публикация этого ответа как вики-сайта сообщества, чтобы обеспечить лучшую видимость, поскольку решение было опубликовано в комментариях.

Раньше я использовал версию 1.18.2 и сервер метрик v0.3.6. Развертывание происходило через кубеадм. Да, все требования были точно такими же, как у сервера метрик / требований. Хорошей новостью является то, что я запустил его, обновив мою версию k8s до 1.19.0 и используя последнюю версию v0.3.7. Он работает с самоподписанными сертификатами.

Проблема устранена обновлением:

  • Kubernetes: 1.18.2 -> 1.19.0
  • Metrics-server: 0.3.6 -> 0.3.7

Это обновление разрешено запускать metrics-server с участием tls включен (самоподписанные сертификаты).


Дополнительные ресурсы, которые могут помочь при развертывании metrics-server с участием tls:

Как безопасно запустить metrics-server? Предлагаемая конфигурация:

  • Кластер с включенным RBAC
  • Порт порта только для чтения Kubelet отключен
  • Подтвердите сертификат kubelet, подключив файл CA и предоставив флаг --kubelet-certificate-Authority серверу метрик
  • Избегайте передачи небезопасных флагов на сервер метрик (--deprecated-kubelet-complete-insecure, --kubelet-insecure-tls)
  • Рассмотрите возможность использования ваших собственных сертификатов (--tls-cert-file, --tls-private-key-file)

Создайте конфигурационную карту для хранения сертификата CA, который использовался для создания сертификата обслуживания kubelet.

kubectl -n kube-system create configmap ca --from-file=ca.crt=/etc/kubernetes/pki/ca.crt -o yaml

Затем используйте volumeMounts, чтобы использовать его в модуле сервера метрик.

spec:
  volumes:
  - emptyDir: {}
    name: tmp-dir
  - configMap:
      defaultMode: 420
      name: ca
    name: ca-dir
  containers:
    args:
      - --cert-dir=/tmp
      - --secure-port=4443
      - --kubelet-certificate-authority=/ca/ca.crt
      - --kubelet-preferred-address-types=Hostname
    volumeMounts:
    - mountPath: /tmp
      name: tmp-dir
    - mountPath: /ca
      name: ca-dir

Вы можете следовать тому же подходу и использовать --tls-cert-file а также --tls-private-key-file для использования вашего собственного сертификата вместо самоподписанного сертификата.

Для моих друзей на EKS убедитесь, что у вас установлено имя пользователя (а не указано только имя сеанса, как я):

      robert ❱ kubectl get configmaps -n kube-system aws-auth -o yaml | grep MyTeamRole$ -A 3
- rolearn: arn:aws:iam::123546789012:role/MyTeamRole
  username: {{SessionName}}
  groups:
    - system:masters
robert ❱ kubectl top node
error: You must be logged in to the server (Unauthorized)
robert ❱ 1 ❱ kubectl edit configmap -n kube-system aws-auth
configmap/aws-auth edited
robert ❱ kubectl get configmaps -n kube-system aws-auth -o yaml | grep MyTeamRole$ -A 3
    - rolearn: arn:aws:iam::123546789012:role/MyTeamRole
      username: literally_anything:{{SessionName}}
      groups:
        - system:masters
robert ❱ kubectl top node
NAME                                       CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%
ip-10-0-3-103.us-west-2.compute.internal   341m         17%    1738Mi          52%
...
robert ❱ kubectl logs -n kube-system -l app.kubernetes.io/instance=metrics-server
E0407 22:34:45.879156       1 authentication.go:63] "Unable to authenticate the request" err="verifying certificate SN=801591513699736721, SKID=, AKID= failed: x509: certificate signed by unknown authority"
E0407 22:34:49.399854       1 authentication.go:63] "Unable to authenticate the request" err="verifying certificate SN=801591513699736721, SKID=, AKID= failed: x509: certificate signed by unknown authority"
E0407 22:34:50.691133       1 authentication.go:63] "Unable to authenticate the request" err="verifying certificate SN=3949940469908359789, SKID=, AKID= failed: x509: certificate signed by unknown authority"
E0407 22:34:51.827629       1 authentication.go:63] "Unable to authenticate the request" err="verifying certificate SN=3949940469908359789, SKID=, AKID= failed: x509: certificate signed by unknown authority"
E0407 22:39:07.288163       1 authentication.go:63] "Unable to authenticate the request" err="verifying certificate SN=3949940469908359789, SKID=, AKID= failed: x509: certificate signed by unknown authority"
E0407 22:39:08.755492       1 authentication.go:63] "Unable to authenticate the request" err="verifying certificate SN=801591513699736721, SKID=, AKID= failed: x509: certificate signed by unknown authority"
E0407 22:39:09.801957       1 authentication.go:63] "Unable to authenticate the request" err="verifying certificate SN=801591513699736721, SKID=, AKID= failed: x509: certificate signed by unknown authority"
E0407 22:40:32.405458       1 authentication.go:63] "Unable to authenticate the request" err="verifying certificate SN=801591513699736721, SKID=, AKID= failed: x509: certificate signed by unknown authority"
E0407 22:43:09.791769       1 authentication.go:63] "Unable to authenticate the request" err="verifying certificate SN=3949940469908359789, SKID=, AKID= failed: x509: certificate signed by unknown authority"
E0407 22:44:14.244221       1 authentication.go:63] "Unable to authenticate the request" err="verifying certificate SN=3949940469908359789, SKID=, AKID= failed: x509: certificate signed by unknown authority"
robert ❱
Другие вопросы по тегам