Обновление Kubernetes приводит к тому, что модуль зависает при завершении


У меня проблема с развертыванием kubernetes. Вероятно, это будет некачественный вопрос, извините за это: я новичок в управлении сервером и не могу связаться с человеком, который настраивал серверы в первую очередь, поэтому я с трудом
Моя конфигурация (в среде тестирования) состоит из одного главного узла и двух обычных узлов, каждый из которых содержит одну реплику модуля (всего два модуля), содержащего образ докера, на котором работает сервер wildfly.
Я возился со средой тестирования, потому что раньше у нас возникала проблема: иногда после развертывания (случайным образом, через несколько минут или несколько позже) блоки выходили из строя (время ожидания проверки жизнеспособности) и переходили в CrashLoopBackOff. Я добавил строку в код, чтобы регистрировать информационное сообщение каждый раз, когда вызывался тест живучести, чтобы увидеть, вызывался ли он вообще, и я повторно развернул (развернуть конфигурацию без изменений). Поскольку проблема возникает случайным образом, я потратил полдня на повторное развертывание каждый час или около того (без каких-либо изменений) и отслеживание журналов. Не повезло.

Итак, вот часть, где что-то пошло не так:
После развертывания в n-й раз я начал видеть события о FailedScheduling. Глядя на состояние модуля, я вижу, что один из двух модулей из старого репликационного пакета застрял на Завершение, а модуль, который должен занять свое место, застрял на Ожидании. Я могу решить проблему, позвонив kubectl delete pod --force --grace-period=0 [pod name], но это происходит снова каждый раз, когда я развертываю, поэтому, конечно, это не идеально. Я еще не пытался развернуть в производственной среде.
Вот журналы:
Статус: https://pastebin.com/MHuWV2dM
События: https://pastebin.com/8hvpg9n5
Опишите модули: https://pastebin.com/QFmkUQB3
Заранее благодарю за любую помощь, которую вы можете оказать.

Источник

1 ответ

Это вызвано ограниченными ресурсами ЦП и комбинацией конфигурации зонда живучести.

Модуль не может быть развернут, потому что не хватает процессора, и он застрял в состоянии ожидания:

Events:
  Type     Reason                 Age                    From                                                  Message
  ----     ------                 ----                   ----                                                  -------
  Warning  FailedScheduling       10m                    default-scheduler                                     0/3 nodes are available: 1 PodToleratesNodeTaints, 2 Insufficient cpu.

Живая зонд:

Liveness:  http-get http://:8080/igoodi-rest/api/health delay=45s timeout=1s period=10s #success=1 #failure=6

который настроен на перехват http-get с таймаутом всего 1 с, через 45 с после развертывания. Ваши стручки терпят неудачу, которые ловят почти сразу и в конечном счете прекращаются.

Под 1:

Events:
  Type     Reason                 Age                    From                                                 Message
  ----     ------                 ----                   ----                                                 -------
...
  Normal   Created                10m                    kubelet, ip-172-20-46-26.eu-west-1.compute.internal  Created container
  Normal   Started                10m                    kubelet, ip-172-20-46-26.eu-west-1.compute.internal  Started container
  Warning  Unhealthy              9m11s (x2 over 9m21s)  kubelet, ip-172-20-46-26.eu-west-1.compute.internal  Liveness probe failed: Get http://100.96.2.247:8080/igoodi-rest/api/health: net/http: request canceled (Client.Timeout exceeded while awaiting headers)

Под 2:

Events:
  Type     Reason                 Age                    From                                                  Message
  ----     ------                 ----                   ----                                                  -------
...
  Normal   Created                10m                    kubelet, ip-172-20-32-139.eu-west-1.compute.internal  Created container
  Normal   Started                10m                    kubelet, ip-172-20-32-139.eu-west-1.compute.internal  Started container
  Warning  Unhealthy              9m14s (x3 over 9m34s)  kubelet, ip-172-20-32-139.eu-west-1.compute.internal  Liveness probe failed: Get http://100.96.1.253:8080/igoodi-rest/api/health: net/http: request canceled (Client.Timeout exceeded while awaiting headers)

1. Убедитесь, что URL-адрес для проверки работоспособности зонда корректен. Используйте curl из узлов, чтобы увидеть, доступен ли он. В некоторых приложениях для проверки работоспособности URL-адреса иногда используется "healthz" вместо "health". Если время проверки работоспособности все еще истекло на правильном URL, увеличьте время ожидания на 1 с.

2. Убедитесь, что у вас не закончились доступные ресурсы. Бег kubectl top nodes увидеть использование ресурсов.

3. Проверьте логи kubelet. Как посмотреть логи кубелетов или кейс Amazon EKS.

4. Изучите жизненный цикл завершения Kubernetes, который может повлиять на то, сколько времени потребуется для завершения работы бобов. Прочтите это руководство.

ОБНОВИТЬ:

Согласно кубернетес документации

Ручное принудительное удаление следует выполнять с осторожностью, поскольку оно может нарушить не более одной семантики, присущей StatefulSet. StatefulSets может использоваться для запуска распределенных и кластерных приложений, которым требуется стабильная сетевая идентификация и стабильное хранилище. Эти приложения часто имеют конфигурацию, которая опирается на ансамбль с фиксированным числом членов с фиксированными идентификаторами. Наличие нескольких членов с одинаковыми идентификационными данными может привести к катастрофическим последствиям и может привести к потере данных (например, сценарий разделения мозга в системах на основе кворума).

Один или несколько узлов могли быть затронуты этим и должны быть перезапущены. Бег kubectl delete pod --force --grace-period=0 [pod name] могло быть причиной этого.

Источник
Другие вопросы по тегам