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

Я пытаюсь установить kubernetes с kubelet 1.4.5 на бета-версию CoreOS (1192.2.0).

Я использую слегка модифицированную версию сценариев установки контроллера и рабочего процесса из https://github.com/coreos/coreos-kubernetes/tree/master/multi-node/generic

поэтому в целом я создал лицензии на Gentoo Linux, используя следующий скрипт bash:

#!/bin/bash
export MASTER_HOST=coreos-2.tux-in.com
export K8S_SERVICE_IP=10.3.0.1
export WORKER_IP=10.79.218.3
export WORKER_FQDN=coreos-3.tux-in.com
openssl genrsa -out ca-key.pem 2048
openssl req -x509 -new -nodes -key ca-key.pem -days 10000 -out ca.pem -subj "/CN=kube-ca"
openssl genrsa -out apiserver-key.pem 2048
openssl req -new -key apiserver-key.pem -out apiserver.csr -subj "/CN=kube-apiserver" -config openssl.cnf
openssl x509 -req -in apiserver.csr -CA ca.pem -CAkey ca-key.pem -CAcreateserial -out apiserver.pem -days 365 -extensions v3_req -extfile openssl.cnf
openssl genrsa -out ${WORKER_FQDN}-worker-key.pem 2048
openssl req -new -key ${WORKER_FQDN}-worker-key.pem -out ${WORKER_FQDN}-worker.csr -subj "/CN=${WORKER_FQDN}" -config worker-openssl.cnf
openssl x509 -req -in ${WORKER_FQDN}-worker.csr -CA ca.pem -CAkey ca-key.pem -CAcreateserial -out ${WORKER_FQDN}-worker.pem -days 365 -extensions v3_req -extfile worker-openssl.cnf
openssl genrsa -out admin-key.pem 2048
openssl req -new -key admin-key.pem -out admin.csr -subj "/CN=kube-admin"
openssl x509 -req -in admin.csr -CA ca.pem -CAkey ca-key.pem -CAcreateserial -out admin.pem -days 365
echo done

а это openssl.cnf

[req]
req_extensions = v3_req
distinguished_name = req_distinguished_name
[req_distinguished_name]
[ v3_req ]
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
subjectAltName = @alt_names
[alt_names]
DNS.1 = coreos-2.tux-in.com
DNS.2 = coreos-3.tux-in.com
IP.1 = 10.3.0.1
IP.2 = 10.79.218.2
IP.3 = 10.79.218.3

а это мой worker-openssl.cnf

[req]
req_extensions = v3_req
distinguished_name = req_distinguished_name
[req_distinguished_name]
[ v3_req ]
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
subjectAltName = @alt_names
[alt_names]
IP.1 = 10.79.218.3
DNS.1 = coreos-3.tux-in.com

Моя машина контроллера coreos-2.tux-in.com, которая разрешается в lan ip 10.79.218.2

моя рабочая машина coreos-3.tux-in.com, которая разрешается в lan ip 10.79.218.3

он создал лицензии просто отлично. но когда я использую их и устанавливаю скрипт контроллера на основную машину, я вижу, что при запуске journalctl -xef -u kubelet я заметил следующие сообщения:

Nov 08 21:24:06 coreos-2.tux-in.com kubelet-wrapper[2018]: E1108 21:24:06.805868    2018 event.go:208] Unable to write event: 'x509: certificate signed by unknown authority' (may retry after sleeping)
Nov 08 21:24:06 coreos-2.tux-in.com kubelet-wrapper[2018]: E1108 21:24:06.950827    2018 reflector.go:203] pkg/kubelet/kubelet.go:384: Failed to list *api.Service: Get https://coreos-2.tux-in.com:443/api/v1/services?resourceVersion=0: x509: certificate signed by unknown authority
Nov 08 21:24:07 coreos-2.tux-in.com kubelet-wrapper[2018]: E1108 21:24:07.461042    2018 reflector.go:203] pkg/kubelet/config/apiserver.go:43: Failed to list *api.Pod: Get https://coreos-2.tux-in.com:443/api/v1/pods?fieldSelector=spec.nodeName%3D10.79.218.2&resourceVersion=0: x509: certificate signed by unknown authority
Nov 08 21:24:07 coreos-2.tux-in.com kubelet-wrapper[2018]: E1108 21:24:07.461340    2018 reflector.go:203] pkg/kubelet/kubelet.go:403: Failed to list *api.Node: Get https://coreos-2.tux-in.com:443/api/v1/nodes?fieldSelector=metadata.name%3D10.79.218.2&resourceVersion=0: x509: certificate signed by unknown authority
Nov 08 21:24:08 coreos-2.tux-in.com kubelet-wrapper[2018]: E1108 21:24:08.024366    2018 reflector.go:203] pkg/kubelet/kubelet.go:384: Failed to list *api.Service: Get https://coreos-2.tux-in.com:443/api/v1/services?resourceVersion=0: x509: certificate signed by unknown authority
Nov 08 21:24:08 coreos-2.tux-in.com kubelet-wrapper[2018]: E1108 21:24:08.171170    2018 eviction_manager.go:162] eviction manager: unexpected err: failed GetNode: node '10.79.218.2' not found
Nov 08 21:24:08 coreos-2.tux-in.com kubelet-wrapper[2018]: E1108 21:24:08.543619    2018 reflector.go:203] pkg/kubelet/kubelet.go:403: Failed to list *api.Node: Get https://coreos-2.tux-in.com:443/api/v1/nodes?fieldSelector=metadata.name%3D10.79.218.2&resourceVersion=0: x509: certificate signed by unknown authority
Nov 08 21:24:08 coreos-2.tux-in.com kubelet-wrapper[2018]: E1108 21:24:08.543926    2018 reflector.go:203] pkg/kubelet/config/apiserver.go:43: Failed to list *api.Pod: Get https://coreos-2.tux-in.com:443/api/v1/pods?fieldSelector=spec.nodeName%3D10.79.218.2&resourceVersion=0: x509: certificate signed by unknown authority

kubernetes kubelet coreos
person ufk    schedule 08.11.2016    source источник
comment
Не могли бы вы также заглянуть в журналы других компонентов Kubernetes? Особенно мастер-аписервер. Если я правильно понимаю, вы сможете увидеть компоненты с помощью docker ps и отобразить их с помощью docker logs <containerid>.   -  person svenwltr    schedule 12.11.2016
comment
Использование ракеты. И у меня нет конкретных журналов для каждого контейнера   -  person ufk    schedule 12.11.2016

Ответы (4)


arrow_upward
2
arrow_downward

В документации говорится, что флаг --tls-cert-file требует объединения ЦС после сертификата. В вашем случае это apiserver.pem:

--tls-cert-file Файл, содержащий сертификат x509 для HTTPS. (Сертификат ЦС, если таковой имеется, объединенный после сертификата сервера). Если --tls-cert-file и --tls-private-key-file не указаны, самозаверяющий сертификат и ключ генерируются для общедоступного адреса и сохраняются в каталоге, переданном --cert-dir.

Если я правильно понял, что вы создаете сертификат, apiserver.pem не содержит корневого ca.

person svenwltr    schedule 11.11.2016
comment
спасибо за Ваш ответ. я добавил ca в файл apiserver.pem, но результаты точно такие же. - person ufk; 12.11.2016
comment
что вы имеете в виду под добавлением? - person stephanlindauer; 08.12.2016

arrow_upward
0
arrow_downward

Я использую kubelet с rkt на CoreOS 1192.2.0.

Это модуль, который я использую для запуска kubelet на рабочем месте:

[Unit]
Description=Kubelet via Hyperkube ACI
Requires=k8s-assets.target
After=k8s-assets.target
[Service]
EnvironmentFile=/etc/proxy.env
Environment="RKT_OPTS=--volume=resolv,kind=host,source=/etc/resolv.conf --mount volume=resolv,target=/etc/resolv.conf --volume var-log,kind=host,source=/var/log --mount volume=var-log,target=/var/log"
Environment=KUBELET_VERSION=v1.4.0_coreos.0
ExecStartPre=/usr/bin/mkdir -p /etc/kubernetes/manifests
ExecStart=/usr/lib/coreos/kubelet-wrapper \
--api-servers=https://10.203.69.108 \
--register-node=true \
--allow-privileged=true \
--config=/etc/kubernetes/manifests    \
--hostname-override=node2.my.domain  \
--cluster_dns=10.3.0.10 \
--cluster_domain=cluster.local \
--kubeconfig=/etc/kubernetes/worker-kubeconfig.yaml \
--tls-cert-file=/etc/kubernetes/ssl/worker.pem \
--tls-private-key-file=/etc/kubernetes/ssl/worker-key.pem
Restart=always
RestartSec=10
[Install]
WantedBy=multi-user.target

Что важно, так это

--api-servers, которые должны указывать на IP адрес главного сервера.

--tls-cert-file, который должен указывать на открытый ключ рабочего сертификата.

--tls-private-key-file, который должен указывать на закрытый ключ рабочего сертификата.

--kubeconfig, который должен указывать на действительный файл kubeconfig.

Вот мой файл kubeconfig (он содержит путь к ЦС, подписавшему сертификаты):

apiVersion: v1
kind: Config
clusters:
- name: local
  cluster:
    certificate-authority: /etc/kubernetes/ssl/ca.pem
users:
- name: kubelet
  user:
    client-certificate: /etc/kubernetes/ssl/worker.pem
    client-key: /etc/kubernetes/ssl/worker-key.pem
contexts:
- context:
    cluster: local
    user: kubelet
  name: kubelet-context
current-context: kubelet-context
person Yves Blusseau    schedule 15.11.2016
comment
Здравствуй. спасибо за Ваш ответ. я закрыл рабочий сервер, и я все еще получаю те же сообщения об ошибках. это означает, что это на самом деле не относится к рабочей конфигурации, нет? - person ufk; 15.11.2016
comment
Я думаю, вы инвертировали DNS-имя рабочего/мастера и IP-адрес рабочего/мастера. Вы написали, что рабочая машина — это coreos-3.tux-in.com с ip 10.79.218.3 (в сценарии bash для генерации сертификатов), но после того, как вы написали: моя рабочая машина — это coreos-2.tux-in.com который разрешает lan ip 10.79.218.3 - person Yves Blusseau; 16.11.2016

arrow_upward
0
arrow_downward

Ваши сертификаты OpenSSL являются «самоподписанными»:

openssl genrsa -out ca-key.pem 2048
openssl req -x509 -new -nodes -key ca-key.pem -days 10000 -out ca.pem -subj "/CN=kube-ca"

То есть вы подписываете их вместо доверенного центра сертификации. Это должно быть совершенно нормально и безопасно, пока вы храните закрытые ключи в безопасности.

Если вы хотите, чтобы он был подписан центром сертификации, вам необходимо создать CSR (запрос на подпись сертификата).

https://www.digitalocean.com/community/tutorials/openssl-essentials-working-with-ssl-certificates-private-keys-and-csrs

person Alex W    schedule 18.11.2016
comment
Здравствуй. спасибо за Ваш ответ. так проблема в том, что они самоподписанные? если я хочу продолжать использовать самозаверяющие сертификаты, что мне делать? как мне избавиться от этой ошибки? - person ufk; 19.11.2016

arrow_upward
0
arrow_downward

в общем, решение состояло в том, чтобы создать еще один порт etcd2, который подключается к петлевому устройству каждой машины и работает на http вместо https. дополнительная информация по адресу запросы calico-policy-controller etcd2 сертификаты другого coreos-сервера

person ufk    schedule 12.01.2017