> Поясни? Где и зачем он нужен? Мне прям интересно - я уже
> лет 15 занимаюсь живыми серверными приложениями, развёрнутыми от 1 компа до
> 10000. Но видимо чего-то не понимаю, и сейчас узнаю что-то полезное
> для своей профессии, прям тут в комментариях Опеннета.

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

Рассмотрим облачного провайдера CI/CD. В кубе держится пул из воркеров. Каждый воркер для запуска пайплайна запускает dind, который менеджит запуск каждого шага в отдельном контейнере. Каждому из этих диндов выделяется Persistent Volume, который закрепляется за ним и может быть использован для хранения кэшей и передачи информации между шагами пайплайна. Чтобы не переплачивать за аренду ресурсов, шедулер тюнится, чтобы заполнять одну ноду до конца, и только потом переходить на следующую. Таким образом провиженер позволяет запрашивать у облака новую ноду только тогда, когда пул текущих нод заполнен полностью ворклоадом. Данная инфраструктура сейчас реально существует и ежедневно поддерживает тысячи клиентов по всему миру.

Теперь посмотрим общий подход для организации разработки в произвольной компании. Чтобы протестировать изменения разработчика, берётся его PR, бампается версия чарта, и в тестовом кластере создаётся воркспейс под данную задачу, и туда накатывается стабильная версия всех компонент приложения + изменённый компонент разработчика. Облачная архитектура позволяет легко выделить дополнительные ресурсы и обеспечить непрерывный цикл разработки-тестирования.

Парочка российских проектов, связанных с товарооборотом и ЭДО. Эти ребята не используют все преимущества k8s, однако даже они испытывают огромный буст производительности, благодаря миграции в куб. Благодаря концепциям сервиса и ингресс-контроллера, теперь можно не думать о том, чтобы синхронно за увеличением количества реплик, обновлять апстримы условного nginx-а. Куб берёт это на себя. Поэтому, когда им требуется быстро смасштабироваться горизонтально, они просто увеличивают количество реплик.

И это только капля в море. Настройка менеджмента сертификатов на условном дедике -- штука крайне кривая по сравнению с cert-manager-ом. Чтобы перевыписывать сертификаты letsencrypt-ом, на дедике нужно корректно настроить веб-сервис для работы с webroot. В кубе -- reissue происходит автоматически, а об ингресс-контроллере думать не нужно совсем. Манифесты и хелм-чарты (читай, пакеты для куба), в кои-то веки обеспечили декларативное описание сложных программных комплексов. Раньше это достигалось прямыми руками, теперь же иначе просто невозможно. Порог вхождения в эту область увеличился, и это хорошо. Я уже не говорю, что Canary и Blue-Green встроены непосредственно в концепцию деплоймента. Я помню, как когда-то реализовывал эти схемы на ansible. Деплоймент маст хэв.

В общем, Вам надо зайти на амазон или гугл, и просто попробовать.