Тайм-аут ожидания инициализации кластера, автоматическое обновление узлов не выполнено / или Запуск с ошибкой

Question

У меня есть несколько кластеров с 3 узлами в пуле узлов каждого кластера в моем проекте GCP, и у меня включено автоматическое обновление и восстановление.

Автоматическое обновление началось приблизительно через 3 дня go и все еще работает для версии GKE: 1.12.10-gke.17.

Теперь, когда в мои кластеры включен автоматический -обновление и автоматическое восстановление, несколько кластеров обновляются без проблем, и немногие другие запускают обновление / обновление с проблемами

В моем первом кластере несколько моих модулей вышли без возможности планирования, и возможные возможные действия со стороны GCP:

• Включить автоматическое масштабирование в одном или нескольких пулах узлов, для которых автоматическое масштабирование отключено.
• Увеличение размера одного или нескольких пулов узлов вручную.

при запуске " Контейнерные кластеры gcloud описывают "имя кластера", "зону" "

Я получаю подробную информацию о кластере. однако в разделе пулов узлов

 status: RUNNING_WITH_ERROR
  statusMessage: 'asia-south1-a: Timed out waiting for cluster initialization; cluster
    API may not be available: k8sclient: 7 - 404 status code returned. Requested resource
    not found.'
  version: 1.12.10-gke.17

ПРИМЕЧАНИЕ:

Я также вижу, что GCP предлагает

• Включить автоматическое масштабирование в одном или нескольких пулах узлов, которые имеют автоматическое масштабирование отключено.
• Сокращение одного или нескольких пулов узлов вручную.

из-за низкого уровня запросов ресурсов.

Пожалуйста, дайте мне знать, какие еще журналы я могу предоставить для решения этой проблемы.

ОБНОВЛЕНИЕ:

Мы просмотрели эти журналы, и служба поддержки Google считает, что, возможно, кублет не может отправить запрос подписи сертификата (CSR) или что он может иметь старые недействительные учетные данные. Чтобы помочь в устранении неполадок, вы можете ответить на следующие вопросы:

1. sudo journalctl -u kubelet> kubelet.log
2. sudo journalctl -u kube-node-installation> kube-node- installation.log
3. sudo journalctl -u kube-node-configuration> kube-node-configuration.log
4. sudo journalctl -u узел-проблема-детектор> узел-проблема-детектор.log
5. sudo journalctl -u docker> docker .log
6. sudo journalctl -u cloud-init> cloud-init.log

Любой узел, который запускается при запуске 1.13.12-gke.13 не удается подключиться к мастеру. Что-то еще, что происходит с узлами (например, отдых), происходит потому, что они пытаются исправить их в ремонте l oop и, похоже, не вызывает дополнительных проблем.

Answer 1

Это не совсем решение, а исправление. Мы смогли сузить до этого.

На пулах узлов у нас были метки «ограничение узла» для того, каким типом узлов это должно быть.

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

, поэтому мы удалили эти две метки селектора узлов и создали новый пул узлов. к нашему удивлению это сработало. Мы должны были перенести всю нагрузку, хотя.

мы следовали этому Облачная миграция