Вопросы Теги

Какой сертификат использует kubelet?

Это кластер 1.16 на основе kubeadm. Насколько я понимаю, работа mTLS между apiserver и kubelet выглядит так:

apiserver -> kubelet 

--kubelet-client-certificate & --kubelet-client-key => The certs & key given here(apiserver) is for apiserver(client) to kubelet (server)
--client-ca => The CA given here(kubelet) is what verfies if request from apiserver is indeed the right one.

И тогда у нас есть другой способ:

kubelet -> apiserver 

--tls-cert-file & --tls-key-file => Passed in kubelet conf. Generally present at /var/lib/kubelet/pki/kubelet.{crt,key}
--kubelet-certificate-authority => The above cert gets verified by this CA passed in apiserver

Однако есть kubelet Файл .conf присутствует в / etc / kubernetes, который снова имеет данные-сертификата клиента и данные-ключа-клиента . Когда используется этот сертификат клиента?

Кроме того, если мы включим автоповорот в kubelet, появится сертификат клиента в разделе /var/lib/kubelet/pki/kubelet-client-current.pem ], на который можно или не может ссылаться в kubelet.conf в зависимости от используемой версии kubeadm (из-за ошибки в kubeadm до 1.17). Я не понимаю, как и когда используются сертификаты клиента kubelet. Любая помощь по этому поводу?

0
задан 17 May 2021 в 18:23
1 ответ

Данные client-certificate-data и client-key-data существуют из-за ошибки. Это хорошо отражено в официальных документах:

Предупреждение: На узлах, созданных с помощью kubeadm init, до версии kubeadm 1.17, существует ошибка, при которой вы вручную должны изменить содержимое kubelet.conf. После завершения kubeadm init, вам следует обновить kubelet.conf для указания на повернутые клиентские сертификаты kubelet сертификаты, заменив client-certificate-data и client-key-data на:

client-certificate: /var/lib/kubelet/pki/kubelet-client-current.pem
client-key: /var/lib/kubelet/pki/kubelet-client-current.pem

Некоторые полезные источники с дополнительной информацией:

EDIT:

Основываясь на kubelet integration:

Когда вы запускаете kubeadm join, kubeadm использует мандат Bootstrap Token для выполнения TLS bootstrap, который извлекает учетные данные, необходимые для загрузки kubelet-config-1.X ConfigMap и записывает его в /var/lib/kubelet/config.yaml. Файл динамического окружения генерируется точно так же, как и kubeadm init.

Далее, kubeadm выполняет следующие две команды для загрузки новой конфигурации в кубелет: 

systemctl daemon-reload && systemctl restart kubelet

После того, как кубелет загрузит новую конфигурацию, kubeadm записывает файл /etc/kubernetes/bootstrap-kubelet.conf файл KubeConfig, который содержит сертификат CA и Bootstrap Token. Они используются кубелетом для выполнения TLS Bootstrap и получения уникальной учетной записи, которая хранится в /etc/kubernetes/kubelet.conf. Когда этот файл будет записан, файл kubelet завершил выполнение TLS Bootstrap.

Это указывает на то, что сертификаты/удостоверения, хранящиеся в kubelet.conf, используются в процессе запуска кублета. Удаление этого файла или изменение его содержимого будет проверено во время перезапуска kubelet. Это можно проверить самостоятельно следующим образом:

  • Если вы удалите файл:
failed to run kubelet: unable to load bootstrap kubeconfig
  • Если вы неправильно настроите файл или предоставите неверные сертификаты:
config loaded from file: /etc/kubernetes/kubelet/conf
bootstrap.go:240 unable to read existing bootstrap client config: f.e. invalid configuration
or unable to load TLS certificates from existing bootstrap client config: data does not contain any valid RSA or ECDSA certificate

Также, в качестве побочного примечания:

Я настоятельно рекомендую использовать более новую версию Kubernetes, поскольку ваша версия на 5 основных версий старше текущей стабильной: 1.21 / 8 апреля 2021 года. Если вы будете следить за обновлением, это избавит вас от многих проблем в будущем.

1
ответ дан 28 July 2021 в 14:07

Теги

Похожие вопросы