1. Обзор
В этом руководстве мы собираемся проиллюстрировать, как поддерживать работоспособность приложения, развернутого в OpenShift .
2. Что такое здоровое приложение?
Во-первых, давайте попробуем понять, что значит поддерживать работоспособность приложения.
Очень часто у приложений внутри подов возникают проблемы. В частности, приложение может перестать отвечать или начать отвечать некорректно.
Приложение может стать неработоспособным из-за временных проблем, таких как ошибки конфигурации или подключения к внешним компонентам, таким как базы данных, хранилище или другие приложения.
Первым шагом в создании отказоустойчивого приложения является реализация автоматических проверок работоспособности модулей . В случае возникновения проблемы поды будут перезапущены автоматически, без ручного вмешательства.
3. Проверка работоспособности с помощью зондов
Kubernetes и, следовательно, OpenShift предлагает два типа зондов: зонды живучести и зонды готовности.
Мы используем зонды живучести, чтобы знать, когда необходимо перезапустить контейнер. OpenShift перезапускает модуль, когда проверка работоспособности завершается сбоем и модуль становится недоступным.
Зонды готовности проверяют доступность контейнера для приема трафика. Мы считаем pod готовым, когда готовы все его контейнеры. Балансировщики нагрузки службы удаляют модуль, когда он не находится в состоянии готовности.
В случае, если запуск контейнера занимает много времени, механизм позволяет нам направлять соединения на поды, готовые принять требуемый трафик. Это может произойти, например, когда необходимо инициализировать набор данных или установить соединение с другим контейнером или внешней службой.
Мы можем настроить liveness probe двумя способами:
- Редактирование файла развертывания модуля
- Использование мастера OpenShift
В обоих случаях полученный результат остается одинаковым. Первый механизм унаследован непосредственно от Kubernetes, уже рассмотренный в другом туториале .
Вместо этого в этом руководстве мы покажем, как настроить датчики с помощью графического пользовательского интерфейса OpenShift.
4. Зонды живости
Мы определяем проверку жизнеспособности как параметр для конкретных контейнеров в файле конфигурации развертывания. Все контейнеры внутри пода наследуют эту конфигурацию.
Если зонд был создан как проверка HTTP или TCP , зонд будет выполняться с узла, на котором работает контейнер . OpenShift выполняет зонд внутри контейнера, когда зонд создается как скрипт.
Итак, давайте добавим новый тест живучести к приложению, развернутому в OpenShift:
- Выберем проект, которому принадлежит приложение
- На левой панели мы можем нажать
Приложения -> Развертывания. - Выберем выбранное приложение
- Во вкладке Application Deployment Configuration выбираем ссылку в оповещении
Add Health Checks .Оповещение присутствует только в том случае, если для приложения не настроена проверка работоспособности. - На новой странице давайте выберем
Add Liveness Probe . - Затем давайте настроим живость зонда по своему вкусу:
Давайте разберем, что означает каждая из этих настроек Liveness Probe:
Тип: тип проверки работоспособности. Мы можем выбирать между проверкой HTTP(S), проверкой выполнения контейнера или проверкой сокета.Использовать HTTPS: установите этот флажок, только если служба liveness предоставляется через HTTPS.Путь: путь, по которому приложение предоставляет проверку живучести.Порт: порт, на котором приложение предоставляет пробу живучести.Начальная задержка: количество секунд после запуска контейнера до выполнения зонда — если оставить пустым, по умолчанию оно равно 0.Тайм-аут: количество секунд, после которого обнаруживается тайм-аут зонда — по умолчанию 1 секунда, если пусто .
OpenShift создает новый DeploymentConfig для приложения. Новый DeploymentConfig будет содержать определение вновь настроенного зонда.
5. Датчики готовности
Мы можем настроить датчики готовности, чтобы убедиться, что контейнер готов к приему трафика до того, как он будет считаться активным. В отличие от проверки работоспособности, если контейнер не проходит проверку готовности, этот контейнер остается активным, но не может обслуживать трафик.
Зонд готовности необходим для развертывания без простоев.
Как и в случае с проверкой живучести, мы можем настроить проверку готовности с помощью мастера OpenShift или непосредственно отредактировав файл развертывания пода.
Поскольку мы уже настроили пробу живучести, давайте теперь настроим пробу готовности:
- Выберите проект, к которому принадлежит приложение
- На левой панели мы можем нажать
Приложения -> Развертывания. - Выберем выбранное приложение
- На вкладке «Конфигурация развертывания приложения» мы можем нажать кнопку «
Действия» в правом верхнем углу и выбрать «Изменить проверки работоспособности». - На новой странице давайте выберем
Add Readiness Probe . - Затем давайте настроим датчик готовности по своему вкусу:
Как видно для зонда живучести, настраиваемые параметры следующие:
Тип: тип проверки работоспособности. Мы можем выбирать между проверкой HTTP(S), проверкой выполнения контейнера или проверкой сокета.Использовать HTTPS: установите флажок, только если служба готовности предоставляется в HTTPS.Путь: путь, по которому приложение предоставляет пробу готовности.Порт: порт, на котором приложение предоставляет пробу готовности.Начальная задержка: количество секунд после запуска контейнера до выполнения зонда (по умолчанию 0).Тайм-аут : количество секунд, после которого обнаруживается тайм-аут зонда (по умолчанию 1) .
Опять же, OpenShift создает новый DeploymentConfig , содержащий тест готовности, для нашего приложения.
6. Завершите
Пришло время протестировать то, что мы представили. Предположим, у нас есть приложение Spring Boot для развертывания в кластере OpenShift. Для этого мы можем обратиться к нашему туториалу , где тестовое приложение представлено в виде пошагового развертывания.
Как только приложение будет правильно развернуто, мы можем начать с настройки зондов, следуя тому, что было представлено в предыдущих абзацах. Приложение Spring Boot использует Spring Boot Actuator для предоставления конечных точек проверки работоспособности. Мы можем найти больше информации о настройке Actuator в нашем специальном руководстве .
В конце установки на странице конфигурации развертывания будет показана информация о вновь настроенных зондах:
Теперь пришло время проверить, правильно ли работают датчики готовности и живучести.
6.1. Проверьте датчик готовности
Попробуем смоделировать развертывание новой версии приложения. Зонд готовности позволяет нам выполнять развертывание с нулевым временем простоя. В этом случае, когда мы развернем новую версию, OpenShift создаст новый модуль, соответствующий новой версии. Старый модуль будет продолжать обслуживать трафик до тех пор, пока новый модуль не будет готов к приему трафика, то есть до тех пор, пока проверка готовности нового модуля не вернет положительный результат.
На панели управления OpenShift внутри страницы нашего проекта, если мы посмотрим на середину этапа развертывания, мы увидим представление развертывания с нулевым временем простоя:
6.2. Протестируйте Liveness Probe
Вместо этого давайте смоделируем отказ зонда живучести.
Предположим, что проверка работоспособности, выполненная приложением в этот момент, вернет отрицательный результат. Это говорит о недоступности ресурса, необходимого для работы пода.
OpenShift уничтожит модуль n раз (по умолчанию n равно 3) и создаст его заново. Если проблемы будут решены на этом этапе, состояние работоспособности модуля будет восстановлено. В противном случае OpenShift рассматривает модуль в состоянии Failed , если зависимые ресурсы остаются недоступными во время попыток.
Давайте проверим это поведение. Давайте откроем страницу, содержащую список событий, связанных с модулем. Мы должны увидеть экран, похожий на следующий:
Как мы видим, OpenShift зафиксировал сбой проверки работоспособности, убил модуль и попытался перезапустить его.
7. Заключение
В этом руководстве мы рассмотрели два типа зондов OpenShift.
Мы использовали датчики готовности и живучести параллельно в одном контейнере. Мы использовали оба из них, чтобы убедиться, что OpenShift перезапускает контейнеры при возникновении проблем и не позволяет трафику достигать их, когда они еще не готовы к обслуживанию. Полный исходный код наших примеров здесь, как всегда, находится на GitHub .