Контейнеры, Docker и Kubernetes на пальцах для аналитика

Однажды я принёс баг разработчику: «на stage форма падает». Он пожал плечами — «у меня локально всё работает». И ведь не врал: у него на машине стояла одна версия библиотеки, на сервере — другая, и код вёл себя по-разному. Мы потеряли день на то, что оказалось разницей в окружении, а не в коде. Контейнеры придумали ровно против этого дня. С тех пор, когда я слышу «у меня работает», я первым делом спрашиваю: а окружение одинаковое? Если приложение упаковано в контейнер — ответ «да» по построению, и копать надо в другом месте. Аналитику не нужно уметь собирать контейнеры. Нужно понимать, какую проблему они решают и почему слова «масштабируется» и «воспроизводимо» теперь значат что-то конкретное.

Какую проблему решает контейнер

Любое приложение живёт не в вакууме — ему нужно окружение: определённая версия языка, набор библиотек, системные настройки, переменные. На машине разработчика одно, на сервере другое, на проде третье — и приложение, которое прекрасно работает в одном месте, спотыкается в другом из-за невидимой разницы. Это и есть классическое «у меня работает», которое съедает дни на ровном месте.

Контейнер решает это просто: давайте упакуем приложение вместе с его окружением в одну коробку. Внутри коробки всё нужное — правильная версия языка, все библиотеки, настройки. Коробку целиком переносим куда угодно, и где её ни запусти, внутри одно и то же. Не «приложение плюс надежда, что на сервере всё совпадёт», а «приложение плюс его мир, запечатанные вместе». Аналогия — не рецепт, который повар читает и готовит из того, что нашлось на кухне, а готовый набор «всё в одной коробке, добавь воды»: результат предсказуем, потому что ничего не зависит от того, что было на конкретной кухне.

Образ против контейнера: рецепт и блюдо

Два слова, которые путают, а разница простая. Образ (image) — это шаблон, рецепт, неизменный слепок: «вот такое приложение с вот таким окружением». Образ лежит и не меняется. Контейнер — это запущенный по образу экземпляр, живой процесс. Из одного образа можно запустить хоть десять контейнеров — как из одного рецепта приготовить десять одинаковых блюд.

	Образ (image)	Контейнер
Что это	шаблон, рецепт	запущенный экземпляр
Состояние	неизменный, лежит	работает, живёт
Сколько	один	сколько угодно из одного образа
Аналогия	рецепт блюда	готовое блюдо

Зачем аналитику эта разница: именно из неё растёт всё масштабирование. Когда говорят «поднимем ещё три копии сервиса», это значит «запустим ещё три контейнера из того же образа». Образ один — копий много, и все одинаковые, потому что рецепт один.

Зачем Docker

Docker — это инструмент, который сделал контейнеры удобными и массовыми. Он умеет две главные вещи: собрать образ по описанию (что положить в коробку — какая база, какие библиотеки, какой код) и запустить из образа контейнер. Описание коробки задают текстовым файлом — он читается почти как список шагов:

FROM python:3.12
COPY . /app
RUN pip install -r requirements.txt
CMD python app.py

По-человечески это: «возьми готовое окружение с Python 3.12, положи внутрь мой код, доустанови библиотеки из списка, а при запуске выполни вот эту команду». Docker по этому файлу собирает образ — и дальше образ можно запускать где угодно, он несёт окружение в себе. Аналитику не нужно писать такие файлы, но полезно узнавать их в репозитории: это и есть «рецепт коробки», и по нему видно, из чего собрано приложение.

Оркестратор и Kubernetes: когда коробок много

Один-два контейнера человек запустит руками. Но реальная система — это десятки и сотни контейнеров, которые надо запускать, следить за ними, перезапускать упавшие, добавлять копии под нагрузку и убирать, когда нагрузка спала. Делать это вручную невозможно. Нужен управляющий — оркестратор: программа, которая дирижирует контейнерами, как дирижёр оркестром.

Самый известный оркестратор — Kubernetes (часто пишут «k8s»). Что он делает простыми словами:

• Запускает нужные контейнеры на доступных серверах — сам решает, где именно.
• Лечит: контейнер упал — Kubernetes поднимает новый на его место, не дожидаясь человека.
• Масштабирует: нагрузка выросла — добавляет копии контейнера, упала — убирает лишние.
• Распределяет запросы между копиями, чтобы нагрузка ложилась ровно.

flowchart LR
  IMG["Образ (рецепт)"] --> K["Kubernetes (оркестратор)"]
  K --> C1["Контейнер-копия 1"]
  K --> C2["Контейнер-копия 2"]
  K --> C3["Контейнер-копия 3"]
  C1 -. упал .-> K
  K -. поднимает заново .-> C1

Схема читается так: из одного образа оркестратор поднимает несколько одинаковых контейнеров-копий — все по одному рецепту, потому отличаться не могут. Kubernetes следит за каждой: если копия упала, он замечает это и поднимает новую на её место, не дожидаясь, пока кто-то проснётся ночью. А если запросов стало больше — он просто добавляет ещё копий из того же образа. Главная идея: оркестратор берёт на себя рутину «следить и перезапускать», а человек только говорит ему, сколько копий держать и когда добавлять.

Связь с микросервисами и CI/CD

Контейнеры не живут отдельно — они сцепляются с двумя темами, про которые есть отдельные записи. Во-первых, с архитектурой. Когда систему режут на много мелких сервисов (см. монолит против микросервисов), каждый сервис обычно и пакуют в свой контейнер — отдельную коробку с собственным окружением. Именно поэтому микросервисы и контейнеры почти всегда идут в паре: десятки независимых сервисов удобно держать как десятки независимых коробок, и оркестратор управляет всем этим хозяйством.

Во-вторых, с окружениями и выкаткой. Помните идею «код едет через dev → stage → prod» из записи про CI/CD и окружения? Контейнер — это то, что делает её честной. Через все окружения едет один и тот же образ, не пересобранный заново под каждое, а ровно тот, что проверили. Поэтому «на stage работало, а на prod упало из-за разницы окружений» перестаёт быть возможным: окружение запечатано внутри коробки и едет вместе с ней. Контейнер — это техническая гарантия воспроизводимости, на которую опирается весь пайплайн.

Облако против своего железа

Коротко про то, где всё это крутится. Серверы можно держать свои — купить железо, поставить в стойку, обслуживать самим: дороже на старте и хлопотно, зато всё под своим контролем (иногда это требование по безопасности данных). А можно арендовать мощности в облаке — у Yandex Cloud, AWS и подобных: платишь за то, что используешь, мощности добавляются по кнопке, железо чужая забота. Для контейнеров разницы почти нет — коробка одинаково едет и туда, и туда; это и есть одно из её достоинств. Выбор «своё или облако» — это в основном про деньги, контроль и требования безопасности, а не про технологию контейнеров.

Масштабирование как ответ нагрузке

Здесь контейнеры смыкаются с нефункциональными требованиями. Когда в спеке написано «система держит 10 000 одновременных пользователей», ответом на это число обычно служит горизонтальное масштабирование — добавить копий контейнера и раскидать нагрузку между ними. Это противоположность «вертикальному» — купить один сервер помощнее. Горизонтальное масштабирование как раз и есть та суперсила, которую даёт связка «контейнеры плюс оркестратор»: нагрузка выросла — подняли ещё копий, спала — убрали.

Что меняется для аналитика

Аналитик не настраивает Docker и не пишет манифесты Kubernetes — это инженерная работа. Но три вещи теперь читаются иначе. Первое: «масштабируется» — это про копии одного контейнера, а не про магию; и масштабируется не всё подряд, а только то, что не упирается в общий узкий ресурс. Второе: окружения воспроизводимы — если приложение в контейнере, «у меня работает, а у вас нет» из-за разницы окружений практически исчезает, и при разборе бага это сразу сужает поиск. Третье: контейнер — это та коробка, что едет через весь пайплайн неизменной, поэтому «проверили на stage» и «то же поедет на prod» наконец-то означают одно и то же. Понимать эти три вещи — достаточно, чтобы говорить с инженерами на одном языке и не пугаться слов «под», «нода» и «реплика».

Частые вопросы

Чем образ отличается от контейнера?

Образ (image) — это неизменный шаблон, рецепт: описание приложения вместе с его окружением, которое просто лежит и не меняется. Контейнер — это запущенный по образу живой экземпляр. Из одного образа можно поднять сколько угодно одинаковых контейнеров, как приготовить много блюд по одному рецепту. Эта разница важна для понимания масштабирования: «добавить копий сервиса» означает «запустить ещё контейнеров из того же образа», и все они одинаковые именно потому, что рецепт один.

Что такое Kubernetes простыми словами?

Это оркестратор — управляющий, который дирижирует множеством контейнеров. Когда контейнеров десятки и сотни, человек физически не может за всеми следить: Kubernetes сам запускает их на серверах, перезапускает упавшие, добавляет копии под нагрузку и убирает лишние, когда нагрузка спала, и распределяет запросы между копиями. Сам он не сервер, а программа поверх обычных серверов: серверы — сцена, контейнеры — музыканты, Kubernetes — дирижёр.

Зачем аналитику вообще знать про контейнеры?

Чтобы три вещи в требованиях значили что-то конкретное. «Масштабируется» — это про добавление копий контейнера (горизонтальное масштабирование), и масштабируется не всё, а только то, что не упирается в общий ресурс. «Воспроизводимое окружение» — это про то, что контейнер несёт окружение в себе, поэтому dev, stage и prod ведут себя одинаково. И «выкатили то, что проверили» — потому что через пайплайн едет один и тот же образ. Настраивать ничего не надо, надо понимать, почему эти слова теперь не пустые.