У меня проблема с развертыванием кубернетов. Вероятно, это будет некачественный вопрос, я сожалею об этом: я новичок в управлении серверами, и я не могу связаться с человеком, который изначально настраивал серверы, поэтому я с трудом.
Моя конфигурация (в тестовой среде) состоит из одного главного узла и двух обычных узлов, на каждом из которых размещается одна реплика модуля (всего два модуля), содержащая образ докера, на котором запущен сервер 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
Заранее благодарим вас за любую помощь, которую вы можете оказать.
Это вызвано ограниченными ресурсами процессора и комбинацией конфигурации вашего зонда живучести.
Под не удается развернуть, потому что не хватает процессора и он застрял в состоянии ожидания:
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, который может повлиять на время, необходимое для завершения работы подов. Прочтите это руководство.
ОБНОВИТЬ:
В соответствии с документация kubernetes
Ручное принудительное удаление следует проводить с осторожностью, так как оно может нарушить не более одной семантики, присущей StatefulSet. StatefulSets может использоваться для запуска распределенных и кластерных приложений, которым требуется стабильная сетевая идентификация и стабильное хранилище. Эти приложения часто имеют конфигурацию, основанную на ансамбле фиксированного числа членов с фиксированными идентификаторами. Наличие нескольких участников с одной и той же идентификацией может иметь катастрофические последствия и может привести к потере данных (например, сценарий разделения мозга в системах на основе кворума).
Это могло повлиять на один или несколько узлов, и их необходимо перезапустить. Бег kubectl delete pod --force --grace-period=0 [pod name] могло быть причиной этого.