Одна физическая машина может сымитировать нагрузку миллиона пользователей (на самом деле даже больше но там вопрос на сколько сложная логика у тестов, в общем случае в нагрузочных тестах объем и порядок запросов фиксирован и не включает полный анализ ответов, т.е. это просто список url которые нужно загрузить в сессии) поэтому затраты на это последнее, о чем нужно беспокоиться, они минимальны.
kubernetes, rabbitMQ, и прочие плюшки - это только инструменты, и кстати их использование не обязательно (хотя идеи используемые в них использовать так или иначе придется), и требования именно для их использования так же минимальны.
Если говорить про конкретику - kubernetes можно развернуть буквально на одном физическом сервере (на виртуальных машинах) и полноценно изучать все его фишки, кстати будет отлично видны накладные расходы на те 'удобства', которые оно предоставляет, но помним что когда кластер разрастется до нескольких физических машин, это станет уже незаметно.
p.s. возможность автоматического добавления мощностей, это когда идеология такой возможности заранее закладывается при разработки приложений (это не только само приложение но и организация сервисов, их настройка и порядок и правила управление всем этим), а затем, когда управляющим центром, в автоматическом режиме на основе мониторинга нагрузки, автоматически поднимаются новые машины (сам факт этого тесно переплетается с источником этих машины - физически люди у тебя бегают и железные ящики к проводам подключают или скрипты поднимают новые машины в облачном датацентре) и на них запускаются дополнительные экземпляры сервисов.
И да, все это можно вообще реализовать без существующих инструментов, написать десяток другой небольших скриптов, собственно так они (большие продукты типа kubernetes) и появились, кому то надоел зоопарк скриптов и разношерстных приложений для этого
Средний
Средний
