2016-09-05 4 views
0

Я работаю с:Kubernetes livenessProbe выключение при запуске приложения

kubernetes 1.3.6

.. с этой частью в файле развертывания моего приложения:

livenessProbe: 
     httpGet: 
     path: /liveness 
     port: 8082 
     initialDelaySeconds: 120 

.. так что, когда я описываю стручок, я получил это

Liveness: http-get http://:8082/liveness delay=120s timeout=1s period=10s #success=1 #failure=3 

Мое приложение часто начинается в 110-115 секунд, но иногда это занимает больше (из-за задержки DB, внешние услуги повторить, и т.д ..).

Проблема, которую я вижу, заключается в том, что когда требуется более 130/140 секунд (initialDelaySeconds + period), kubernetes заставляет выключать и перезагружать pod с нуля. Когда у вас много реплик (50-60), это означает, что полное развертывание иногда занимает 10-15 минут больше, чем обычное. Очевидно, что решение состоит в том, чтобы увеличить initialDelaySeconds, но тогда для развертывания потребуется намного больше времени.

Я посмотрел здесь, и там нет ничего, что кажется, чтобы решить эту проблему: http://kubernetes.io/docs/api-reference/v1/definitions/#_v1_probe

В идеале я хотел бы иметь что-то, что работает в обратном направлении: не «initialDelaySeconds», но в максимальное количество времени, чтобы начать стручок. Если это время проходит, кубернетес заставляет выключить стручок и пытается в другое время.

ответ

2

Наконец-то я получил хорошее решение, которое в настоящий момент отлично работает!

Я установил:

  • readinessProbe.initialDelaySeconds: равен минимальное время запуска из приложения
  • livenessProbe.initialDelaySeconds: равно максимальное время запуска приложения + несколько секунд

Так что kubernetes (после readinessProbe.initialDelaySeconds) начинает проверку готовности датчика для того, чтобы добавить стручок к балансировке. Затем (после livenessProbe.initialDelaySeconds) он начинает проверять также зонд живой силы, в случае необходимости перезагрузки модуля.

0

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

Формула времени вы ищете бы

initialDelaySeconds + period * (failureTreshold - 1)

(-1 потому что зонд выполнен сразу после initialDelaySeconds). Вы можете настроить maximumAmountOfTime (параметр, который вы хотите иметь), изменив эти 3 значения.

EDIT: после комментария от OP, выше ответ неверен, кажется, что увеличение initialDelaySeconds - единственное, что вы можете сделать сейчас.

+0

Ну, проблема заключается в том, что в описании сказано: «Минимальные последовательные сбои для зонда, которые будут считаться не пройденными ПОСЛЕ ПОЛУЧЕНИЯ ПОСЛЕДУЮЩИХ. По умолчанию 3. Минимальное значение равно 1.« Поэтому он должен преуспеть один раз перед сбоем. Порог делает свою работу! –

+0

Вы правы, я пропустил это. Я думаю, что ваш единственный вариант - увеличить initialDelaySeconds. И вы можете отправить запрос функции в https://github.com/kubernetes/kubernetes/issues, объясняющем ваш вариант использования. – Nebril

+0

ИЛИ (это взломано, но может работать), вы можете создать зонд живой активности, который будет успешным при первом запуске (возможно, использовать условное значение в bash с настройкой переменной env?), Но будет запускать ваш обыденный зонд в последующих прогонах. Таким образом, у вас будет «преуспевающий» модуль, и вы сможете использовать период и порог ошибки. – Nebril

Смежные вопросы