Общие вопросы о тестах Helm Chart
Я работаю с тестированием Helm Chart и немного запутался. У меня есть пара (глупых) вопросов,
- Что делает тестовый модуль? Зачем вообще делать Test Pod? Почему оригинальный Pod не может проводить тестирование?
- Как тестовый модуль взаимодействует с исходным модулем?
- Сообщает ли тестовый модуль исходному модулю о выполнении определенных задач?
- Если я хочу проверить порты и хосты (сервер ping), указывает ли тестовый модуль исходному модулю выполнить команду ping, или тестовый модуль выполняет ping? Если тестовый модуль выполняет тесты, как вы можете быть уверены, что исходный модуль работает правильно (т. е. ничего не делает)?
Возможно, немного теории о тестах Хелма было бы очень полезно для меня. Если есть документ с подробной информацией о тестах Helm, дайте мне знать.
Ответы 1
Представьте, что вы хотите знать, работает ли Stack Overflow. Итак, вы бежите curl https://stackoverflow.com. В 99,9% случаев немного волшебства с балансировщиками нагрузки и базами данных и чего-то еще не происходит, и вы получите список вопросов, но 0,1% времени вы получите страницу «что-то не так». То есть, отправив HTTP-запрос GET откуда-то извне приложения, вы все равно можете получить общее представление о том, работает ли оно.
Вы можете выполнять столько тестов, сколько хотите, из тестового модуля. Отправка пакетов ICMP ECHO, как это делает пинг(1), на самом деле не так уж интересна, поскольку она только проверяет, существует ли Сервис и работает ли сетевой уровень Kubernetes; он вообще не достигает вашего приложения. Простой запрос «Вы живы» может быть интересным, но тесты готовности и живучести тоже делают это. Я мог бы попытаться написать что-то, что зависит от доступности всего приложения и его зависимостей, немного больше, чем просто проверка того, отвечает ли конечная точка HTTP.
Необходимые инструменты тестирования, вероятно, не являются частью вашего основного приложения. Крайним примером этого является то, что многие образы Go построены на образах
FROM scratch, которые буквально не включают вообще ничего, кроме бинарного файла приложения, поэтому вам нужен отдельный образ, содержащийcurlи оболочку. Вы можете представить себе запуск более крупной тестовой системы, которой требуется какая-то языковая среда выполнения, не соответствующая обычному языку.Тестовый модуль «делает обычные запросы» к службе приложений. Часто это будет через HTTP, но это зависит от того, что именно делает приложение.
Тестовый модуль может выполнять HTTP-запросы POST, вызывающие определенные действия, и проверять их результат. Вы также можете возразить, что тестовый модуль не должен изменять данные во время производственного развертывания. Помимо обычного пути сетевого запроса, тестовый модуль не может заставить приложение «выполнить задачу».
Тестовый модуль может сделать известный набор (HTTP) запросов и проверить полученные результаты. Например, если он получает 503 Сервис недоступен, это почти наверняка плохо. Он может проверить, что ответ имеет правильный формат в соответствии со спецификацией OpenAPI. Вероятно, нет пути для случайного другого модуля, который заставит приложение выполнить произвольную команду, и это не поможет вам продемонстрировать, что приложение работает правильно.