Долгий рестарт stateful-сервиса редко выглядит как проблема конфигурации безопасности. Но именно так безопасный default в Kubernetes превратился в 30 минут простоя на каждый перезапуск.
Проблема проявилась на масштабе. Atlantis, который управляет Terraform через GitLab MR, работает как singleton StatefulSet и хранит состояние в PersistentVolume. Любой рестарт — для обновления credentials или онбординга — блокирует все plan/apply операции. При ~100 рестартах в месяц это дало более 50 часов простоя. Симптом выглядел странно: pod создавался быстро, но зависал до старта init-контейнера. Kubernetes events не давали объяснения. Деградация становилась заметной только после роста PV до миллионов файлов и исчерпания inodes.
Разбор показал, что узкое место не в сети и не в pull образов. Kubelet монтировал PV быстро, но дальше происходила скрытая операция: рекурсивное изменение прав доступа (chgrp -R) на всём файловом дереве. Это следствие настройки securityContext с fsGroup. Kubernetes по умолчанию (fsGroupChangePolicy: Always) гарантирует доступ, меняя ownership каждого файла при каждом монтировании. На больших volumes это превращается в O(n) по числу файлов операцию. Без этой настройки Atlantis не смог бы работать как non-root, поэтому полностью отказаться от fsGroup нельзя — это компромисс между безопасностью и временем старта.
Решение оказалось точечным. В Kubernetes доступна альтернатива — fsGroupChangePolicy: OnRootMismatch. В этом режиме kubelet проверяет только корень volume и не запускает рекурсивный chgrp, если права уже корректны. Перед изменением проверили, что процессы не меняют group ownership внутри PV. Это важно: при несогласованных правах можно получить ошибки доступа на рантайме. После этого добавили одну строку в spec.securityContext.
Результат — сокращение времени рестарта с ~30 минут до ~30 секунд. Метрики CPU или I/O не изменялись — ускорение связано исключительно с устранением лишней файловой операции. В сумме это вернуло около 50 часов инженерного времени в месяц.
Этот кейс показывает типичный паттерн: безопасные defaults Kubernetes хорошо работают на малых объёмах, но масштаб делает их линейные операции заметными. Если у вас есть большие PersistentVolume и долгие рестарты, стоит проверить:
- используется ли fsGroup
- какое значение у fsGroupChangePolicy
- есть ли рекурсивные операции при mount
Если данных о поведении файловой системы нет, переключение на OnRootMismatch требует осторожности. Но при контролируемой модели записи это прагматичное улучшение, которое убирает скрытую O(n) стоимость из критического пути старта.