замена хоста kube-master – новый хост ‘запрещен’

Вопрос или проблема

kubelet_node_status.go:73] "Попытка зарегистрировать узел" node="kube-master.work"
eviction_manager.go:282] "Менеджер эвакуации: не удалось получить сводку статистики" err="не удалось получить информацию об узле: узел \"kube-master.work\" не найден"
controller.go:145] "Не удалось обеспечить существование аренды, будет повторная попытка" err="leases.coordination.k8s.io \"kube-master.work\" запрещено: Пользователь \"system:node:kube-master\" не может получить ресурс \"leases\" в группе API \"coordination.k8s.io\" в пространстве имен \"kube-node-lease\": может получить доступ только к аренде узла с тем же именем, что и у запрашивающего узла" interval="7s"
kubelet_node_status.go:96] "Невозможно зарегистрировать узел на сервере API" err="узлы \"kube-master.work\" запрещены: узел \"kube-master\" не имеет права изменять узел \"kube-master.work\"" node="kube-master.work"
server.go:304] "Не удалось аутентифицировать запрос из-за ошибки" err="[недействительный токен, учетные записи службы \"metrics-server\" не найдены]"

Ответ или решение

Заменяя узел kube-master в кластере Kubernetes и столкнувшись с ошибками доступа, связанными с авторизацией и регистрации узла, важно детально оценить порядок действий и возможные упущения. Давайте проанализируем вашу ситуацию и предложим возможные решения.

Проблема

Вы пытаетесь заменить существующий мастер-узел на новый сервер с Rocky9, скопировав файлы сертификатов и восстановив etcd. Ошибки, на которые вы наткнулись, указывают на проблемы с доступом и авторизацией, при этом сообщения о статусе узла и ошибках управления лизензиями сигнализируют о том, что новый узел не может пройти регистрацию и взаимодействовать с API-сервером.

Причины ошибки

1. Использование неправильного имени узла: Вы указали, что новый узел имеет то же имя и IP-адрес, что и старый. Однако Kubernetes использует компоненты механизма RBAC для управления доступом, и доступ к ресурсам (таким как лизенции) может быть ограничен из-за неправильной настройки ролей или прав доступа.

2. Отсутствие токена для аутентификации: Ошибка [invalid bearer token, serviceaccounts "metrics-server" not found] указывает на то, что служебная учетная запись, необходимая для работы, не может быть найдена или неправильно настроена. Это может быть результатом неверной конфигурации после переноса.

3. Недостаток необходимых файлов и конфигураций: Возможно, вы не скопировали все необходимые файлы конфигурации и сертификаты, такие как файлы для kubelet, kubeconfig и т.д.

Рекомендации по исправлению

1. Проверка и обновление конфигураций узла:

   • Убедитесь, что kubelet на новом узле настроен правильно. Проверьте файл конфигурации /var/lib/kubelet/kubeadm-flags.env и убедитесь, что параметры указаны корректно, а также совпадают с предыдущим узлом.

2. Очистка данных и перезапуск узла:

   • Возможно, есть остаточные данные о старом узле. Попробуйте удалить содержимое каталога /var/lib/kubelet/pki, а затем перезапустите kubelet.

3. Копирование всех сертификатов:

   • Убедитесь, что все необходимые сертификаты и ключи, включая ca.crt, apiserver.crt и соответствующие ключи, были успешно перенесены на новый узел.

4. Проверка прав доступа:

   • Проверьте настройки RBAC: убедитесь, что учетная запись system:node:kube-master имеет права на доступ к необходимым ресурсам, включая лизенции. Вам, возможно, потребуется отредактировать роли и привязки ролей.

5. Инициализация кластера:

   • Если предыдущие шаги не помогли, попробуйте повторить инициализацию кластера с использованием команд kubeadm и внимательно следите за результатами. Убедитесь, что используете флаг --apiserver-apiserver-advertise-address <IP-адрес>.

6. Проверка состояния etcd:

   • Убедитесь, что etcd работает корректно, и данные, восстановленные с помощью резервной копии, действительно были корректно перенесены.

7. Обновление конфигураций Metrics Server:

   • Если вы используете Metrics Server, проверьте его установку и конфигурацию, чтобы устранить ошибку, связанную с отсутствием служебной учетной записи.

В случае, если после выполнения всех этих рекомендаций проблема останется нерешённой, стоит рассмотреть возможность обращения в сообщество Kubernetes или к официальной документации для более детальной диагностики проблем.