Kubernetes cluster x509: проблема с сертификатом

Я установил кластер Kubernetes на aws, используя kops с использованием этот учебник в официальной ветке github kubernetes.

Кластер успешно настроен на AWS, но когда я пытаюсь запустить

kubectl get nodes

or

kops validate cluster

это говорит

[user@ip-70-0-0-7 ~]$ kubectl cluster-info
Unable to connect to the server: x509: certificate is valid for *.secure.hosting prod.com, not api.subdomain.mydomain.com

Это определенно проблема с моими сертификатами x509. Просто нужен легкий толчок в правильном направлении. Спасибо за ваше драгоценное время и помощь!

NOTE: I am running these commands from outside the cluster from a machine from where I did set up of cluster.


kubernetes amazon-web-services cluster-computing x509 kops
person Mr.Arjun    schedule 04.05.2017    source источник
comment
Какую ОС вы используете? По крайней мере, на CENTOS существует зависимость установки сертификатов.   -  person Norbert van Nobelen    schedule 04.05.2017
comment
Это амазонка ами   -  person Mr.Arjun    schedule 06.05.2017
comment
Привет, Арджун, ты решил это? Если да, то каким методом вы в конечном итоге воспользовались.   -  person Shruthi Bhaskar    schedule 04.09.2018
comment
@Shruti Тот, который упоминается в ответе Даниэля.   -  person Mr.Arjun    schedule 12.09.2018

Ответы (1)


arrow_upward
3
arrow_downward

Невозможно подключиться к серверу: x509: сертификат действителен для * .secure.hosting prod.com, а не для api.subdomain.mydomain.com

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

Если установленный вами кластер kubernetes действительно доступен через api.secure.hostingprod.com, то обновите свой $HOME/.kube/config, чтобы он сказал https://api.secure.hostingprod.com, где сейчас указано https://api.subdomain.mydomain.com, должно привести все в порядок.

В качестве альтернативы, если api.secure.hosting prod.com не является фактическим доменом, который вы можете использовать (например, если в вашем сертификате действительно есть пробел в имени хоста), у вас есть несколько вариантов.

Самым дешевым, но наименее правильным было бы просто сказать kubectl «Я знаю, что делаю, не проверяйте сертификат», установив параметр insecure-skip-tls-verify под записью cluster в файле $HOME/.kube/config:

- cluster:
    insecure-skip-tls-verify: true

Более утомительным, но и наиболее правильным было бы перевыпустить сертификат для сервера API, используя фактическое имя хоста (очевидно, api.subdomain.mydomain.com). Если вы знаете, как это сделать, лучше всего также добавить к сертификату «Альтернативные имена субъектов» (сокращенно «SAN»), чтобы члены кластера могли ссылаться на него как на https://kubernetes и / или https://kubernetes.default.svc.cluster.local вместе с Service IP-адрес, назначенный kubernetes Service в пространстве имен default. Весьма вероятно, что в вашем текущем сертификате есть те значения, которые openssl x509 -in /path/to/your.crt -noout -text покажут вам, какими они являются в настоящее время. Если вам нужна помощь с битами openssl, в CoreOS Kubernetes есть сценарий оболочки, который они используют, который может работать так, как написано, или, если ничто другое не дает очень конкретных рекомендаций.

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

person mdaniel    schedule 09.05.2017