Go в контейнерах: GOMAXPROCS против квоты CPU, GOMEMLIMIT против OOM и multi-stage Dockerfile с правильным кэшем

Ложь про CPU: GOMAXPROCS против квоты CFS

GOMAXPROCS по умолчанию равен числу CPU, которое сообщает ОС, — а в контейнере это хост, потому что cgroup-лимит CPU не является числом ядер. limits.cpu: 2 превращается в cpu.max: 200000 100000: 200 мс процессорного времени на 100-мс учётный период, суммарно по всем потокам — именно так CFS (Completely Fair Scheduler, планировщик ядра Linux, делящий процессорное время квотами по периодам) видит ограничение контейнера. Эти два числа живут в разных единицах, и рантайм исторически читал только не то. Механика отказа на 64-ядерной ноде: GOMAXPROCS=64 означает до 64 OS-потоков, параллельно исполняющих горутины, плюс фоновые воркеры GC размером в четверть GOMAXPROCS — ещё 16 потоков, которые просыпаются одновременно во время сборки мусора. Под нагрузкой они исчерпывают 200-мс квоту через считаные миллисекунды после начала периода, и планировщик жёстко останавливает всю cgroup до следующего. Задержка не деградирует плавно — она квантуется в кратные окна троттлинга; это и есть обрыв p99 в 8 раз из крючка. Диагноз — два чтения: /sys/fs/cgroup/cpu.stat (nr_throttled растёт вровень с nr_periods, throttled_usec огромен) и метрика рантайма, показывающая GOMAXPROCS в размер хоста.

Лестница лечения, от старого к новому: переменная GOMAXPROCS в спеке пода рядом с лимитом CPU, чтобы они менялись вместе; либо импорт go.uber.org/automaxprocs, читающего квоту cgroup на старте; либо Go 1.25+, где рантайм наконец делает это сам — на Linux дефолт GOMAXPROCS теперь уважает cgroup-лимит CPU (с округлением вверх, не ниже 2, по-прежнему не выше числа ядер хоста), и рантайм даже перепроверяет его при изменении лимита. Честные оговорки: считаются только лимиты — CPU-реквесты задают cpu.weight, то есть коэффициент при конкуренции, а не квоту, и из него GOMAXPROCS не выводится; явная переменная или вызов в коде всегда побеждают; а поды, сознательно живущие без лимита, по-прежнему получают дефолт в размер хоста — и для них это корректно.

Память: трейдофф OOM-kill против давления GC

У лимита памяти та же форма: ядро принуждает limits.memory через OOM-kill (принудительное завершение процесса из-за нехватки памяти) контейнера, а куча Go растёт по политике, которая про cgroups не слышала. С дефолтным GOGC=100 пиковая куча достигает примерно удвоенного живого набора — сервис с 600 МиБ живых данных в поде на 1 ГиБ не «близок к лимиту», он за ним на границе следующего цикла GC. GOMEMLIMIT (Go 1.19+) замыкает контур: поставьте его около 90% лимита контейнера, и пейсер GC примет его как мягкий потолок для всей памяти под управлением рантайма — кучи, стеков, структур рантайма. Механизм — то, что стоит запомнить: по мере приближения к лимиту пейсер планирует сборки всё агрессивнее, превращая давление памяти в процессорное время GC вместо SIGKILL. Трейдофф явный и обычно правильный: сервис, жгущий 30% CPU на GC в пике, деградирует; сервис, убитый ядром, лежит — и по пути потерял все запросы в полёте.

Честность конструкции держится на двух деталях. Лимит сознательно мягкий: рантайм ограничивает CPU сборщика примерно 50%, так что когда живая куча действительно не помещается, Go превышает лимит (и тогда может быть убит OOM), а не уходит в лайвлок из непрерывных сборок — защита от смертельной спирали. А 90% запаса — не суеверие: аллокации cgo, mmap-регионы и память ядра, записанная на cgroup, рантайму невидимы, поэтому GOMEMLIMIT=лимит означает смерть пода, пока Go уверен, что всё в порядке. Задавайте его переменной окружения в деплойменте, рядом с лимитом памяти, чтобы оба числа ревьюились и менялись вместе — env-конфигурация здесь и есть контракт, та же спираль, что в уроке про конфигурацию в go/07.

Dockerfile с правильным кэшем

Статический бинарник сводит контейнерную историю к упаковке: артефакт деплоя — один файл, а образ существует, чтобы доставить его плюс хранилище TLS-доверия:

FROM golang:1.25 AS build
WORKDIR /src
COPY go.mod go.sum ./
RUN go mod download            # отдельный слой: сбрасывается только при смене зависимостей
COPY . .
RUN CGO_ENABLED=0 go build -trimpath -ldflags="-s -w" -o /out/api ./cmd/api

FROM gcr.io/distroless/static-debian12:nonroot
COPY --from=build /out/api /api
ENTRYPOINT ["/api"]

Порядок слоёв и есть стратегия кэширования. Слой пересобирается, когда меняются его входы, — и вместе с ним пересобирается всё, что после него; значит, вопрос к каждой инструкции — как часто меняются её входы. go.mod и go.sum меняются редко; исходники — каждый коммит. Скопировать только манифесты модулей, скачать, и потом копировать исходники — значит обычный коммит воспроизводит слой скачивания из кэша (0 с) и платит только за компиляцию; переверните порядок — сначала COPY . . — и каждый коммит заново качает весь граф модулей (30-90 с на реальном дереве зависимостей, каждую сборку, вечно). Кэш-монтирования BuildKit идут на шаг дальше (RUN --mount=type=cache,target=/go/pkg/mod go mod download сохраняет кэш модулей между сборками даже при изменении go.mod), но именно порядок COPY — то место, где ошибаются.

Выбор рантайм-стадии — настоящее решение. scratch — минимум: образ буквально равен бинарнику, но вы наследуете все дыры: нет CA-сертификатов (первый HTTPS-вызов падает), нет tzdata, нет /etc/passwd для непривилегированного пользователя, нет шелла для отладки. distroless/static стоит примерно 2 МиБ сверху и привозит ровно это: корневые CA, tzdata, пользователя nonroot — шелла по-прежнему нет, что одновременно фича безопасности и отладочный трейдофф, закрываемый эфемерными debug-контейнерами. В обоих случаях итоговый образ — около 10-15 МиБ против билдера на ~850 МиБ, которому в прод нельзя никогда. Числа на память: бинарник ~7-9 МиБ со стрипом, база distroless/static ~2 МиБ, время пулла — фактически круговой путь до реестра.