Работают ли тесты живучести Kubernetes параллельно с вашим приложением?

У меня есть под, работающий на Kubernetes, для которого я разрабатываю тест живучести. Мое приложение читает из очереди (через цикл, который постоянно ищет новые сообщения и выполняет другие функции, если обнаруживает их) и не отображается через HTTP, поэтому мне нужна проверка жизнеспособности команд. Я думаю, подойдет ли простая реализация:

livenessProbe:
      exec:
        command:
        - cat
        - /tmp/healthy

Однако я не уверен, будет ли cat успешным, даже если приложение «застряло» в какой-то момент цикла - файл все равно будет там. Это сводится к фундаментальному отсутствию понимания зондов живучести, которые мне не удалось найти в документации - предположительно, они запускаются каким-то образом последовательно с вашим приложением, поэтому, если ваше приложение не запущено, команда не может быть выполнена? Но я не уверен в этом.

Если команда может выполняться параллельно, я считаю, что мне понадобится какая-то проверка метки времени, когда я обновляю файл в каждом цикле, а зонд живучести проверяет свою метку времени. Если первый способ работает, он проще, но может ли кто-нибудь подтвердить, так ли это? Спасибо.

Изменить: мой код приложения. Я добавил в sleep (60) s, чтобы попытаться проверить, не сработает ли зонд живучести, если файл не будет обновлен в течение минуты, но они не будут частью обычного кода приложения.

INITIALISATION CODE

with open('loaded.txt','w') as f:          # readiness probe = check this file exists
    f.write('loaded')

current_backoff = 0
    max_backoff = 10
    while True:
        if current_backoff < max_backoff:
            current_backoff +=1
        with open('loaded.txt','w') as f:
            f.write('loaded')
            sleep(60)

        messages = input_queue_client.receive_messages(visibility_timeout=100)
        for message in messages:
            with open('loaded.txt','w') as f:
                f.write('loaded')
            sleep(60)
            current_backoff = 0
 
            CODE TO PROCESS MESSAGES

        sleep(current_backoff)

Моя проверка живучести пытается:

1.

        livenessProbe:
          exec:
            command:
              - find
              - /var/app/loaded.txt
              - -mmin 
              - '+0.1'
          initialDelaySeconds: 10
          periodSeconds: 10
  1. (команда возвращает ошибку, если что-то возвращается из find, в противном случае - cat файл)
        livenessProbe:
          exec:
            command:
              - find
              - /var/app/loaded.txt
              - -mmin 
              - '+0.1'
              - -exec
              - cat
              - '/var/app/loaded.txt{}'
              -  ;
          initialDelaySeconds: 10
          periodSeconds: 10
  1. (команда возвращает ошибку, если что-то возвращается из find, в противном случае ничего не возвращает)
        livenessProbe:
          exec:
            command:
              - find
              - /var/app/loaded.txt
              - -mmin 
              - '+0.1'
              - -exec
              - if[[{}]]
              - ;
          initialDelaySeconds: 10
          periodSeconds: 10

Я также пробовал все это с - вместо +. Зонд никогда не выходит из строя, несмотря на очень короткое окно (которое в конечном итоге будет длиннее!) И команду сна.


person Lucy    schedule 11.11.2020    source источник


Ответы (1)


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

В вашем случае вы можете касаться /tmp/healthy файла каждый раз, когда начинаете новую итерацию в цикле. И используйте команду типа find /tmp/health -mmin +0.5 для проверки работоспособности. Эта команда ничего не возвращает, если файл старше получаса. Если команда проверки работоспособности ничего не возвращает, предполагается, что проверка прошла успешно.

person Grigoriy Mikhalkin    schedule 11.11.2020
comment
Спасибо за объяснение, это полезно. Я пытался использовать предложенное вами решение, но я думаю, что проверка работоспособности проходит независимо от того, был ли файл изменен за последние 0,5 минуты. Если команда ничего не возвращает, предполагается, что проверка работоспособности проходит. Если команда возвращает файл, похоже, также предполагается, что он проходит. Как я могу заставить его возвращать код состояния ошибки, если файл слишком старый? - person Lucy; 11.11.2020
comment
Я использовал: `livenessProbe: exec: command: - find - /myfile.txt - -mmin - '-0.5' 'Также пробовал с +0.5! - person Lucy; 11.11.2020
comment
@Lucy Странно, проверка работоспособности не должна проходить, если команда что-то возвращает. Вы пытались создать файл только один раз и после этого не трогали его? - person Grigoriy Mikhalkin; 11.11.2020
comment
@ Люси, не могли бы вы показать какой-нибудь минимальный пример вашего приложения, чтобы я мог попытаться воспроизвести вашу проблему локально? - person Grigoriy Mikhalkin; 11.11.2020
comment
проверка работоспособности не должна проходить, если команда что-то возвращает - я думал, что обычная команда проверки работоспособности cat file.txt, которая что-то вернет (содержимое файла)? - person Lucy; 12.11.2020
comment
Я отредактировал основной пост со структурой своего приложения @Grigoriy Mikhalkin - person Lucy; 12.11.2020
comment
Кажется, что find всегда возвращает код состояния 0 (успех), если он находит файл, независимо от того, соответствует ли он критерию -mmin. Это приводит к прохождению проверки работоспособности независимо от того, возвращает ли -mmin файл. Я предполагаю, что мне нужно направить вывод в команду, код успеха которой зависит от того, является ли ввод нулевым или ненулевым, но мне трудно найти подходящий метод. - person Lucy; 12.11.2020
comment
@Lucy Я бы посоветовал вам задать новый вопрос, например, как установить код ошибки в команде проверки живучести или что-то в этом роде. - person Grigoriy Mikhalkin; 12.11.2020
comment
Спасибо, я решил проблему сегодня утром, построив отдельный сценарий bash с указанными условными кодами выхода, а затем выполнив его как команду проверки живучести. Спасибо за вашу помощь! - person Lucy; 13.11.2020