Очистка кэша Nginx в Docker и Kubernetes: практическое руководство | AdminWiki
Logo

Очистка кэша Nginx в Docker и Kubernetes: практическое руководство

20 августа 2026 11 мин. чтения
Содержание статьи

Введение: зачем очищать кэш Nginx в контейнерных средах

Кэш Nginx хранит готовые ответы бэкенда, чтобы не гонять каждый запрос к приложению. При обновлении статики, изменении конфигурации или отладке эти сохранённые файлы устаревают. Пользователь получает старую версию страницы, хотя бэкенд уже отдал новую. Если требуется именно полная очистка, содержимое кэш-директории нужно удалить.

В Docker очистка выполняется через docker exec внутри работающего контейнера или через управление volume. В Kubernetes задача решается разовыми Job, проверками ReadinessProbe и Persistent Volumes. ReadinessProbe сама по себе не очищает кэш: она только показывает, может ли под принимать трафик. Цель одна - убрать устаревшие файлы, не уронив сервис. Это руководство даёт готовые команды и манифесты для обеих сред.

Если вы ещё не настраивали кэширование, начните с базовой настройки proxy_cache в Nginx. Для глубокого понимания структуры кэш-директории и параметров proxy_cache_path изучите руководство по очистке и инвалидации кеша Nginx.

Как понять, где именно лежит кэш

Перед удалением определите фактический путь, способ хранения и объект, который подключён к Nginx. Не ориентируйтесь только на каталог /var/cache/nginx: в кастомной конфигурации путь задаётся директивой proxy_cache_path, а данные могут находиться в volume, bind mount или PVC.

Проверка в Docker

Сначала посмотрите путь кэша в активной конфигурации и список подключённых хранилищ:

docker exec <container_name> nginx -T | grep proxy_cache_path
docker inspect <container_name> --format '{{range .Mounts}}{{println .Type .Name .Source .Destination}}{{end}}'

В выводе docker inspect поле Destination показывает путь внутри контейнера, а Source - путь на хосте или идентификатор хранилища. Если Source указывает на Docker volume, проверьте его отдельно через docker volume inspect. Для bind mount убедитесь, что на хосте используется именно нужная директория.

Проверка в Kubernetes

В Kubernetes проверьте конфигурацию Nginx, описание Pod и состояние PVC в том же namespace:

kubectl -n <namespace> exec <pod_name> -- nginx -T | grep proxy_cache_path
kubectl -n <namespace> describe pod <pod_name>
kubectl -n <namespace> get pvc nginx-cache-pvc

В секциях Volumes и Mounts из describe должно быть видно, какой PVC подключён и в какой путь он смонтирован. Сверьте эти данные с Job: ошибка в имени PVC или mountPath приведёт к очистке не того хранилища либо к падению Job.

Безопасный чек-лист перед очисткой

  • Остановите или ограничьте трафик к очищаемому экземпляру Nginx. Для общего кэша заранее согласуйте окно работ, чтобы запросы не записывали файлы одновременно с удалением.
  • Проверьте proxy_cache_path, фактический путь монтирования, имя volume или PVC и namespace.
  • Сохраните текущую конфигурацию Nginx перед изменением:
docker exec <container_name> nginx -T > nginx-config-before-cleanup.txt
  • Проверьте команду на staging-окружении, особенно если используется bind mount, общий PVC или нестандартный пользователь контейнера.
  • Убедитесь, что после очистки бэкенд выдержит временный рост cache miss и повторную генерацию ответов.

Очистка кэша Nginx в Docker

Docker-контейнер с Nginx изолирован, но кэш лежит внутри его файловой системы или подключённого хранилища. Доступ к нему возможен двумя путями: выполнение команды внутри контейнера или управление volume. Первый способ быстрый, второй удобен для повторяемой эксплуатации.

Использование docker exec для удаления файлов кэша

Команда docker exec запускает процесс внутри работающего контейнера. Для очистки кэша Nginx используйте оболочку, чтобы символ * раскрылся внутри контейнера:

docker exec <container_name> /bin/sh -c 'rm -rf /var/cache/nginx/*'

Вариант без /bin/sh -c может не сработать ожидаемым образом: Docker передаст шаблон /var/cache/nginx/* непосредственно программе rm, не выполнив подстановку содержимого каталога.

Путь /var/cache/nginx часто используется в конфигурациях Nginx, но в кастомных сборках он может отличаться. Перед удалением проверьте каталог:

docker exec <container_name> /bin/sh -c 'ls -la /var/cache/nginx'

Если директория пуста или отсутствует, найдите её через конфигурацию Nginx:

docker exec <container_name> nginx -T | grep proxy_cache_path

Вывод покажет точный путь, заданный директивой proxy_cache_path. Ошибка в пути при rm -rf опасна: можно удалить не те файлы. Перед выполнением всегда проверяйте содержимое целевой директории и права пользователя, под которым выполняется команда.

Anonymous volume, named volume и bind mount

Способ очистки зависит от типа хранения кэша. Само подключение volume не включает кэширование: путь в хранилище должен совпадать с путём, который использует proxy_cache_path.

Anonymous volume. Docker создаёт volume автоматически, если указать только путь назначения:

docker run -d \
  --name nginx-cache-anonymous \
  -v /var/cache/nginx \
  nginx:latest

Найти созданный anonymous volume можно через inspection контейнера:

docker inspect nginx-cache-anonymous --format '{{range .Mounts}}{{println .Name .Source .Destination}}{{end}}'

Очищайте его через контейнер, предварительно проверив Destination:

docker exec nginx-cache-anonymous /bin/sh -c 'rm -rf /var/cache/nginx/*'

Named volume. Такой вариант удобен, когда кэш нужно сохранять между пересозданиями контейнера и явно подключать к другим процессам.

docker run -d \
  --name nginx-cache \
  -v nginx-cache-volume:/var/cache/nginx \
  nginx:latest

Очистить кэш можно через тот же docker exec, но данные физически находятся на volume:

docker exec nginx-cache /bin/sh -c 'rm -rf /var/cache/nginx/*'

Второй вариант - удалить содержимое volume с хоста. Сначала найдите точку монтирования:

docker volume inspect nginx-cache-volume --format '{{ .Mountpoint }}'

После проверки пути и остановки записи в volume очистите только его содержимое:

MOUNTPOINT=$(docker volume inspect nginx-cache-volume --format '{{ .Mountpoint }}')
sudo rm -rf "$MOUNTPOINT"/*

Не используйте docker volume rm, если требуется только очистить кэш: эта команда удаляет сам объект volume и может привести к потере других данных.

Bind mount. Кэш можно хранить в заранее выбранной директории хоста:

mkdir -p ./nginx-cache
docker run -d \
  --name nginx-cache-bind \
  -v "$PWD/nginx-cache:/var/cache/nginx" \
  nginx:latest

После проверки пути очистите данные непосредственно на хосте:

rm -rf ./nginx-cache/*

Для продакшена храните кэш на быстром хранилище, например на SSD-дисках от Timeweb Cloud, чтобы повторное заполнение кэша не создавало узкое место.

Пост-проверка после очистки в Docker

Сразу после удаления проверьте, что в каталоге не осталось файлов кэша:

docker exec <container_name> /bin/sh -c 'find /var/cache/nginx -type f -print'
docker exec <container_name> /bin/sh -c 'ls -la /var/cache/nginx'

Пустой вывод find означает, что файлы удалены. Затем выполните запрос к известному cacheable-ресурсу и повторите проверку. После успешного кэширования в каталоге должны появиться новые файлы или подкаталоги. Если этого не произошло, проверьте proxy_cache_path, условия обхода кэша и access log Nginx.

Очистка кэша Nginx в Kubernetes

В Kubernetes поды эфемерны. Кэш, хранящийся внутри контейнера, теряется при рестарте или пересоздании Pod. Для сохранения данных используется Persistent Volume, а для очистки - Job или CronJob. При этом Job не останавливает основной Deployment и не защищает от параллельной записи, поэтому момент запуска нужно согласовать с трафиком и режимом монтирования PVC.

Создание Job для разовой очистки кэша

Job запускает под, который выполняет команду и завершается. Это правильный способ разовой очистки кэша в Kubernetes, если Job подключает тот же PVC и имеет необходимые права:

apiVersion: batch/v1
kind: Job
metadata:
  name: nginx-cache-cleaner
spec:
  backoffLimit: 1
  template:
    spec:
      containers:
      - name: nginx-cache-cleaner
        image: nginx:latest
        command: ["/bin/sh", "-c", "rm -rf /var/cache/nginx/*"]
        volumeMounts:
        - name: cache-volume
          mountPath: /var/cache/nginx
      volumes:
      - name: cache-volume
        persistentVolumeClaim:
          claimName: nginx-cache-pvc
      restartPolicy: Never

Если основной Pod продолжает обслуживать запросы, он может создать новые файлы во время работы Job. Для полной очистки сначала остановите или выведите из трафика основной экземпляр, а затем запускайте Job. Для PVC с режимом ReadWriteOnce это особенно важно: Job может не подключиться, пока volume используется Pod на другом узле.

Примените манифест и проверьте статус:

kubectl apply -f nginx-cache-cleaner-job.yaml
kubectl get jobs
kubectl logs job/nginx-cache-cleaner

Job должен завершиться со статусом Completed. Если под падает с ошибкой, проверьте права доступа к Persistent Volume, корректность пути монтирования и события Pod. В продакшене закрепляйте проверенный тег образа вместо безусловного использования latest. Подробнее об управлении кэшем в Kubernetes читайте в руководстве по кэшированию в Docker и Kubernetes.

Пост-проверка после очистки в Kubernetes

Проверяйте каталог в рабочем Pod Nginx, а не только в Job: именно он должен использовать тот же PVC:

kubectl -n <namespace> exec <pod_name> -- /bin/sh -c 'find /var/cache/nginx -type f -print'
kubectl -n <namespace> get job nginx-cache-cleaner

Если после Job вывод find пуст, файлы кэша удалены. Выполните запрос к cacheable-ресурсу через Service или Ingress и повторите команду. Новые файлы подтвердят, что Nginx снова записывает кэш. Если каталог остаётся пустым, проверьте фактический proxy_cache_path, обход кэша для этого запроса и соответствие PVC в Deployment и Job.

Настройка ReadinessProbe для проверки состояния сервиса

ReadinessProbe не должна проверять отсутствие произвольного файла cache_file: это не подтверждает, что Nginx принимает запросы, а после следующей очистки условие может вести себя неоднозначно. Заполнение кэша также не является обязательным условием готовности сервиса: cache miss - нормальный результат сразу после очистки.

Для Nginx используйте проверку реально настроенного endpoint состояния:

readinessProbe:
  httpGet:
    path: /healthz
    port: 80
  initialDelaySeconds: 5
  periodSeconds: 10
  failureThreshold: 3

Путь /healthz должен существовать в конфигурации Nginx и возвращать успешный HTTP-статус. Если готовность нужно связать именно с завершением очистки, используйте отдельный маркер, например /var/run/nginx-ready, и создавайте его после очистки в initContainers или другом процессе того же Pod. Probe не сможет увидеть файл в локальной файловой системе другого Pod, созданного Job.

Использование Persistent Volumes для отказоустойчивости

Persistent Volume хранит кэш вне жизненного цикла пода. При пересоздании пода данные сохраняются, и Nginx не начинает с холодного кэша. Это критично для высоконагруженных сервисов, где повторное заполнение кэша создаёт пиковую нагрузку на бэкенд. Если сохранение кэша не требуется, для Pod может быть достаточно временного хранилища, но его содержимое будет потеряно при пересоздании.

Пример PersistentVolumeClaim для одного Pod:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: nginx-cache-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi

ReadWriteOnce подходит для сценария, в котором PVC используется одним Pod или одной нодой согласно возможностям конкретного storage class. Если несколько реплик Nginx на разных узлах должны подключать общий PVC, может потребоваться ReadWriteMany, но этот режим доступен не у каждого storage class. Он также не решает автоматически вопросы согласованности общего кэша.

При очистке через Job подключите тот же PVC, что и у основного Deployment. Если используется ReadWriteOnce, запланируйте очистку так, чтобы основной Pod не удерживал volume, либо учитывайте ограничения планировщика и storage class. Убедитесь, что у Job есть права на запись в эту директорию.

Автоматизация очистки кэша с помощью CronJob

Регулярная очистка предотвращает накопление устаревших данных и неконтролируемый рост кэш-директории. CronJob запускает Job по расписанию, но его следует применять только после проверки влияния полного удаления кэша на бэкенд. Пример ежедневной очистки в 03:00:

apiVersion: batch/v1
kind: CronJob
metadata:
  name: nginx-cache-cleanup
spec:
  schedule: "0 3 * * *"
  concurrencyPolicy: Forbid
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: nginx-cache-cleaner
            image: nginx:latest
            command: ["/bin/sh", "-c", "rm -rf /var/cache/nginx/*"]
            volumeMounts:
            - name: cache-volume
              mountPath: /var/cache/nginx
          volumes:
          - name: cache-volume
            persistentVolumeClaim:
              claimName: nginx-cache-pvc
          restartPolicy: Never

Параметр concurrencyPolicy: Forbid запрещает параллельный запуск нескольких Job. Это защищает от наложения очисток, если предыдущая ещё не завершилась. Если PVC имеет режим ReadWriteOnce и основной Pod уже использует volume, CronJob может завершиться с ошибкой монтирования. Выбирайте время с минимальной нагрузкой на сервис и учитывайте запас производительности бэкенда. Для CI/CD-пайплайнов запускайте очистку как отдельный контролируемый шаг, о чём рассказано в FAQ по администрированию динамического контента.

Типовые ошибки при очистке кэша Nginx

Неверный путь к кэшу

Команда отрабатывает без явной ошибки, но старые ответы продолжают выдаваться, если удалён не тот каталог. Сверьте proxy_cache_path через nginx -T и проверьте фактический путь монтирования через docker inspect, describe pod или PVC.

Недостаточно прав

Сообщение Permission denied означает, что пользователь процесса не может удалить файлы. В Docker проверьте пользователя контейнера и права bind mount. В Kubernetes проверьте securityContext, fsGroup и владельца каталога. При необходимости используйте initContainers для подготовки прав, но предварительно проверьте требования политики безопасности кластера.

Volume занят или PVC не монтируется

Состояния Pending, FailedMount и похожие ошибки часто связаны с несовместимым режимом доступа, другим узлом или отсутствующим storage class. Проверьте события:

kubectl -n <namespace> describe pod <pod_name>
kubectl -n <namespace> get events --sort-by=.lastTimestamp

Job завершается с ошибкой

Проверьте описание Job, Pod, логи и причину завершения контейнера:

kubectl -n <namespace> describe job nginx-cache-cleaner
kubectl -n <namespace> get pods -l job-name=nginx-cache-cleaner
kubectl -n <namespace> logs job/nginx-cache-cleaner

Наиболее частые причины - неверный claimName, отсутствующий каталог, недостаточные права и невозможность подключить PVC. Не запускайте повторную очистку вслепую, пока причина не установлена.

Риски и предостережения при очистке кэша

Очистка кэша не проходит бесследно. Сразу после удаления Nginx начинает заново запрашивать данные у бэкенда. Если трафик высокий, бэкенд может получить резкий всплеск нагрузки. Очищайте кэш в непиковые часы или используйте механизм stale-кэша, чтобы Nginx отдавал устаревшие данные, пока бэкенд не ответит.

Если требуется убрать только отдельные устаревшие ответы, полная очистка может быть избыточной. Для таких сценариев используйте точечную инвалидацию, версионирование ресурсов или настройки обхода кэша, описанные в руководстве по инвалидации.

Неправильный путь в команде rm -rf - самая опасная ошибка. Удаление не той директории приводит к потере данных или поломке контейнера. Всегда проверяйте путь через ls или nginx -T. Тестируйте очистку на staging-окружении перед запуском в продакшене.

При использовании Persistent Volumes учитывайте права доступа и конкурентную запись. Job, запущенный под другим пользователем, может не иметь прав на запись в директорию кэша. Настройте securityContext с правильным fsGroup или используйте initContainers для подготовки прав.

FAQ: очистка кэша Nginx в Docker и Kubernetes

Как удалить кэш Nginx без перезапуска контейнера?

В Docker используйте docker exec с /bin/sh -c и командой rm -rf /var/cache/nginx/*. В Kubernetes применяйте Job с тем же PVC или выполняйте команду в рабочем Pod после проверки пути и влияния на трафик.

Почему команда rm -rf не удаляет файлы?

В Docker символ * должен раскрываться внутри контейнера, поэтому используйте /bin/sh -c. Также проверьте, что путь соответствует proxy_cache_path, а пользователь имеет права на удаление.

Можно ли удалить Docker volume целиком?

Технически это возможно, если volume не используется, но команда docker volume rm удаляет сам объект хранения. Для обычной очистки кэша безопаснее удалить содержимое нужного каталога и сохранить volume.

Можно ли чистить PVC через CronJob?

Да, если storage class поддерживает нужный режим доступа, Job может подключить PVC, а расписание не конфликтует с основным Pod. Для ReadWriteOnce заранее учитывайте, что volume может быть занят Pod на другой ноде.

Заключение

В Docker очистка кэша Nginx выполняется через docker exec с командой rm -rf или через управление volume, смонтированным в директорию кэша. Учитывайте различия между anonymous volume, named volume и bind mount. В Kubernetes используйте Job для разовой очистки, CronJob для регулярной, ReadinessProbe для контроля состояния сервиса и Persistent Volumes для сохранности данных. Выбор метода зависит от того, насколько часто нужно очищать кэш и какие требования к отказоустойчивости предъявляет сервис.

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

Поделиться:
Сохранить гайд? В закладки браузера