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

Question

Я получаю сообщение об ошибке при запуске kubectl one one machine (windows)

кластер k8s работает на CentOs 7 kubernetes cluster 1.7 мастер, рабочий

Вот мой.kube\config

  
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: REDACTED
    server: https://10.10.12.7:6443
  name: kubernetes
contexts:
- context:
    cluster: kubernetes
    user: system:node:localhost.localdomain
  name: system:node:localhost.localdomain@kubernetes
current-context: system:node:localhost.localdomain@kubernetes
kind: Config
preferences: {}
users:
- name: system:node:localhost.localdomain
  user:
    client-certificate-data: REDACTED
    client-key-data: REDACTED
  

кластер построен с использованием kubeadm с сертификатами по умолчанию в каталоге pki

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

Answer 1

Я просто хочу поделиться, извините, я не смог предоставить это раньше, так как я только что понял, что это вызывает

поэтому на главном узле мы запускаем прокси-сервер kubectl

kubectl proxy --address 0.0.0.0 --accept-hosts '.*'

Я остановил это и вуаля ошибка исчезла.

Теперь я могу сделать

    kubectl получить узлы
ИМЯ СТАТУС ВОЗРАСТНОЙ ВЕРСИИ
centos-k8s2 готовый 3d        v1.7.5
localhost.localdomain Готовый 3d v1.7.5

Надеюсь, это поможет тем, кто наткнулся на этот сценарий

Answer 2

Еще одно решение на случай, если это кому-то поможет:

Мой сценарий:

• с помощью Windows 10
• Kubernetes устанавливается через Docker Desktop ui 2.1.0.1
• установщик создал файл конфигурации по адресу ~/.kube/config
• ценность в ~/.kube/config за server является https://kubernetes.docker.internal:6443
• используя прокси

Проблема: kubectl команды для этой конечной точки проходили через прокси, я понял это после запуска kubectl --insecure-skip-tls-verify cluster-info dump который отображал страницу ошибки прокси html.

Исправление: просто убедитесь, что этот URL-адрес не проходит через прокси, в моем случае в bash я использовалexport no_proxy=$no_proxy,*.docker.internal

Answer 3

Таким образом, kubectl не доверяет кластеру, потому что по какой-то причине конфигурация была испорчена (включая мою). Чтобы исправить это, вы можете использовать openssl для извлечения сертификата из кластера.

openssl.exe s_client -showcerts -connect IP:PORT

IP:PORT должен быть таким, как в вашей конфигурации написано после server:

Скопировать вставку, начиная с -----BEGIN CERTIFICATE----- к -----END CERTIFICATE----- (эти строки включены) в новый текстовый файл, скажем... myCert.crt Если есть несколько записей, скопируйте их все.

Теперь перейдите в.kube\config и вместо

certificate-authority-data: <wrongEncodedPublicKey>`

ставить

certificate-authority: myCert.crt

(предполагается, что вы поместили myCert.crt в ту же папку, что и файл конфигурации). Если вы сделали сертификат правильно, он будет доверять кластеру (попытался переименовать файл, и впоследствии он больше не доверял). Хотел бы я знать, какое кодирование использует данные сертификата-центра, но после нескольких часов поиска в Google я прибег к этому решению и, оглядываясь назад, считаю, что оно в любом случае более элегантно.

Answer 4

Бежать:

gcloud container clusters get-credentials standard-cluster-1 --zone us-central1-a --project devops1-218400

Вот devops1-218400 это название моего проекта Замените его названием вашего проекта.

Answer 5

В моем случае это просто сработало, добавив --insecure-skip-tls-verifyв конце kubectlкоманды, за один раз.

Answer 6

Я получил ту же ошибку во время работы $ kubectl get nodes как пользователь root. Я исправил это, экспортировав kubelet.conf к переменной среды.

$ export KUBECONFIG=/etc/kubernetes/kubelet.conf
$ kubectl get nodes

Answer 7

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

Answer 8

В моем случае я решил эту проблему, скопировав конфигурацию kubelet в мою домашнюю конфигурацию kube.

кот /etc/kubernetes/kubelet.conf > ~/.kube/config

Answer 9

Я удалил/закомментировал эту строкуcertificate-authority-data:и это сработало.

Answer 10

Для тех из вас, кто опоздал на обсуждение, как и я, и ни один из этих ответов не сработал для вас, у меня может быть решение:

Когда я скопировал свой файл.kube/config на свой компьютер с Windows 10 (с установленным kubectl), я не изменил IP-адрес с 127.0.0.1:6443 на IP-адрес мастера, который был 192.168.xx (при подключении компьютера с Windows 10 к кластеру raspberry pi в той же сети). Убедитесь, что вы это делаете, и это может решить вашу проблему, как и мою.

Answer 11

На GCP

проверь: версия gcloud

- localMacOS# gcloud версия

Выполните: --- localMacOS# gcloud контейнерные кластеры get-credentials 'clusterName' \ --zone=us-'zoneName'

Получите clusterName и zoneName из консоли - здесь: https://console.cloud.google.com/kubernetes/list?

ref:.x509 @ размещение на рынке в GCP #Kubernetes

Answer 12

Я получил это, потому что я не был подключен к офисной VPN

Answer 13

Это старый вопрос, но если он помогает кому-то еще, есть еще одна возможная причина.

Предположим, вы развернули Kubernetes с пользователем x. Если каталог.kube находится под пользователем /home/x и вы подключаетесь к узлу с пользователем root или y, он выдаст вам эту ошибку.

Вам нужно переключиться на профиль пользователя, чтобы kubernetes мог загрузить конфигурацию из каталога.kube.

Надеюсь это поможет.

Answer 14

В случае ошибки вы должны экспортировать все kubecfg, которые содержат сертификаты. kops export kubecfg "your cluster-name а также export KOPS_STATE_STORE=s3://"paste your S3 store",

Теперь вы сможете получить доступ и увидеть ресурсы вашего кластера.

Answer 15

В моем случае подключение к Azure было вызвано нашим прокси-сервером безопасности Netskope и было исправлено

      kubectl config set-cluster my-cluster --certificate-authority=path\to\Netskope.pem

az aks get-credentials --resource-group my-resource-group --name my-cluster

Answer 16

И есть еще один сценарий этой проблемы:

1. Кластер является общедоступным и работает на удаленных серверах. Однако доступ к порту6443блокируется брандмауэром. Единственный способ войти — через SSH с туннелем, перенаправляющим трафик от порта клиента к одному из удаленных главных узлов.127.0.0.1:6443. (Локальный порт 6443 здесь не использовался, поскольку Docker for Desktop уже использовал его для своего локального кластера.)
2. Конфигурация kubectl, предоставленная на сервере черезkubectl config view --rawбыл передан локальному клиенту и настроен там. В основном бегkubectlна главном узле кластера работает хорошо.
3. Конфигурация локального клиента принята для использованияhttps://127.0.0.1:16443вместо полного доменного имени главного узла, напримерhttps://m1.cluster.com:6443.

В этом сценарии проблема, по-видимому, связана с тем, что какой бы сертификат, который предлагает служба, использует полное доменное имя или использование IP-адреса с HTTPS, это приводит к проблемам с проверкой любого сертификата в целом.

Следовательно, мне пришлось использовать файл хостов локального клиента , чтобы индивидуально сопоставить полное доменное имя с127.0.0.1. После этого необходимо отменить принятие имени хоста на шаге 3 выше. Изменение порта здесь не является проблемой и поэтому может придерживаться, например,16443как показано здесь.

Для тех, кто не знает, в Windows файл находится по адресуC:\Windows\System32\drivers\etc\hostsи его можно редактировать с помощьюnotepadзапускать с повышенными привилегиями. Каждая строка отображает IP-адрес в список имен хостов, разделенных пробелами, с которыми он должен быть связан. Таким образом, вам придется добавить туда такую ​​​​строку:

      127.0.0.1 m1.cluster.com