Я недавно обновил до kubeadm, который, как я ожидаю, будет вращать все сертификаты, и для хорошей меры я также выполнил kubeadm init phase certs all, но я не уверен, какие шаги необходимы, чтобы проверить, что сертификаты все правильно установлены и не собирается истечь.
Я видел, что ссылка на SO-ответ kubeadm init phase kubeconfig all требуется дополнительно, но не может найти в документация kubernetes kubeadm, в которой говорится, что его необходимо использовать в соединение с фазовыми сертификатами.
Что мне нужно сделать, чтобы убедиться, что кластер не встретит сертификаты с истекшим сроком действия?
Я попытался проверить, подключившись к безопасному локальному порту: echo -n | openssl s_client -connect localhost:10250 2>&1 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' | openssl x509 -text -noout | grep Not, что дает мне срок действия в следующем месяце.
В то время как openssl x509 -in /etc/kubernetes/pki/apiserver.crt -noout -text и openssl x509 -in /etc/kubernetes/pki/apiserver-kubelet-client.crt -noout -text дают даты за год вперед.
Эти противоречивые даты, безусловно, вызывают у меня беспокойство, что я окажусь, как и многие другие, с сертификатами с истекшим сроком действия. Как мне встать перед этим?
Спасибо за любые советы.
2 ответа
По сути, kubeadm init phase certs all регенерирует все ваши сертификаты, включая ваш ca.crt (центр сертификации), а компоненты Kubernetes используют аутентификацию на основе сертификатов для подключения к kube-apiserver (kubelet, kube-scheduler, kube-controller-manager) ) так что вам также придется восстановить почти все эти конфиги, запустив kubeadm init phase kubeconfig all
Имейте в виду, что вам придется восстановить kubelet.conf на всех ваших узлах, поскольку его также необходимо обновить, чтобы подключиться к kube-apiserver с новым ca.crt. Кроме того, убедитесь, что вы добавили все свои имена хостов / IP-адреса, которые ваш kube-apiserver будет обслуживать, {{ X2}} команда (--apiserver-cert-extra-sans)
Скорее всего, вы не видите обновленные сертификаты при подключении через openssl, потому что вы не перезапустили компоненты Kubernetes и, в частности, kube-apiserver. Таким образом, вам придется запустить ваш kube-apiserver, kube-scheduler, kube-controller-manager и т. Д. (Или kube-apiserver, kube-планировщики и т. Д., Если вы используете многоуровневую панель управления). Вам также придется перезапустить ваши кубелец на всех ваших узлах.
Месяц спустя я узнал немного больше и хотел обновить этот вопрос для тех, кто следует за мной.
Я подал проблему в Kubernetes, запрашивая дополнительную информацию о том, как процесс обновления kubeadm автоматически обновляет сертификаты , Документация по Kubernetes говорит:
Примечание: kubelet.conf не включен в приведенный выше список, поскольку kubeadm настраивает kubelet для автоматического обновления сертификата.
После обновления я не увидел автоматического обновления сертификата для kubelet. Затем мне сообщили, что:
решение о том, когда вращать сертификат, является недетерминированным, и это может произойти на 70-90% от общего срока службы сертификата, чтобы предотвратить перекрытие при вращении сертификата узла.
Они также предоставили следующий процесс, который разрешил мою последнюю выдачу сертификатов:
sudo mv /var/lib/kubelet/pki /var/lib/kubelet/pki-backup
sudo systemctl restart kubelet
# the pki folder should be re-created.
Похожие вопросы
Связанные вопросы
Новые вопросы
kubernetes
ВОПРОСЫ KUBERNETES ДОЛЖНЫ БЫТЬ СВЯЗАНЫ С РАЗРАБОТЧИКОМ Kubernetes - это платформа с открытым исходным кодом, предназначенная для автоматизации развертывания, масштабирования и работы контейнеров приложений на нескольких хостах и / или в облаках. Вопросы о настройке кластеров следует задавать на https://serverfault.com