Какое назначение контейнеризации помимо изоляции ресурсов
Что проверяют
Понимаете ли вы, что контейнер прежде всего единица поставки, а не облегчённая виртуалка. Следом обычно спрашивают, как вы собираете образ для Go-сервиса и что меняется для рантайма Go внутри контейнера с лимитами.
Как отвечать
Помимо изоляции контейнеризация даёт:
- неизменяемый артефакт: образ собирается один раз в CI, и в тест, стейдж и прод едет один и тот же образ с одним digest. «У меня работает» перестаёт быть аргументом;
- упаковку окружения: вместе с приложением едут системные библиотеки, сертификаты, часовые пояса;
- единый формат для оркестратора: Kubernetes не важно, на чём написан сервис, он запускает образ, следит за health-проверками, перезапускает и масштабирует реплики;
- быстрые выкладки и откаты: откат это смена тега или digest на предыдущий, без ручной возни с пакетами на сервере;
- плотность: контейнеры стартуют за секунды и делят ядро хоста, на одной машине их помещается больше, чем виртуалок;
- воспроизводимое локальное окружение: база, брокер и соседние сервисы поднимаются через Docker Compose, в тестах через Testcontainers.
Дальше привяжите к Go. Сервис собирается в статический бинарник (CGO_ENABLED=0), и многоэтапная сборка даёт образ на базе scratch или distroless/static размером в десятки мегабайт. В scratch нет CA-сертификатов и базы часовых поясов: их копируют из этапа сборки или встраивают пакетом time/tzdata. С Go 1.25 рантайм учитывает лимит CPU из cgroup при выборе GOMAXPROCS, в более старых версиях для этого подключали automaxprocs. Для памяти задают GOMEMLIMIT чуть ниже лимита контейнера, чтобы сборщик мусора срабатывал раньше OOM killer.
Где спотыкаются
Называют главным плюсом безопасность. Контейнеры делят ядро хоста, и изоляция у них слабее, чем у виртуальной машины. Безопасность требует отдельной работы: запуск не от root, минимальный образ, сканирование уязвимостей.
Кладут в прод образ со всем тулчейном Go на сотни мегабайт вместо многоэтапной сборки.
Не знают, что старый Go в контейнере с лимитом в 2 CPU на 64-ядерной ноде выставлял GOMAXPROCS равным 64 и упирался в троттлинг.