Хранилища (Dynamic Provisioning), Пробы и задачи (Jobs)

From wiki.baghirzade.pro
Jump to navigation Jump to search

1. Повторение и углубление: PV/PVC и NFS

  • emptyDir: Используется для обмена данными между контейнерами в одном поде (например, для sidecar-контейнеров, собирающих логи). Данные удаляются при перезагрузке пода.
  • hostPath: Используется для доступа к файлам хоста (ноды). Применяется редко, в основном в системных подах (DaemonSet), например для сбора системных логов.
  • NFS в K8s: Самое простое сетевое хранилище.
    • Проблема лимитов: В NFS сложно ограничить размер диска для конкретного пользователя на уровне протокола. Если один под запишет терабайт данных, он может забить всё общее хранилище.

2. Динамическое создание томов (Dynamic Provisioning)

Вместо того чтобы вручную создавать каждый PV (Static Provisioning), используется механизм автоматизации:

  • NFS Provisioner: Специальный под (контроллер), который следит за появлением новых PVC. Как только разработчик запрашивает диск через PVC, контроллер сам создает папку на NFS-сервере и генерирует соответствующий PV.
  • StorageClass (SC): Это шаблон (чертеж) для создания диска.
    • В PVC указывается storageClassName.
    • Если установить аннотацию is-default-class: true, то все PVC без указания класса будут использовать именно этот SC.
  • Reclaim Policy: * Delete: При удалении PVC автоматически удаляется и PV, и данные.
    • Retain: При удалении PVC данные сохраняются, но PV переходит в статус Released (нужна ручная очистка для повторного использования).

3. Проверки состояния (Health Checks): Liveness и Readiness

Без этих настроек K8s считает под "здоровым", как только запустился процесс в контейнере. Это может привести к потере трафика при обновлении.

A. Readiness Probe (Готовность к трафику)

  • Зачем: Определяет, когда приложение полностью загрузилось и готово принимать запросы.
  • Действие: Если проверка не проходит, под исключается из балансировщика (Service Endpoint), но не перезагружается.

B. Liveness Probe (Жизнеспособность)

  • Зачем: Определяет, не зависло ли приложение ("deadlock").
  • Действие: Если проверка провалена (по умолчанию 3 раза), Kubelet перезапускает контейнер.

C. Startup Probe (Для медленных приложений)

  • Зачем: Для тяжелых legacy-приложений, которые могут запускаться по 5-10 минут. Пока Startup Probe не пройдет успешно, Liveness и Readiness проверки не начинаются, чтобы не убить приложение раньше времени.

Способы проверки:

  1. HTTP Get: Запрос на определенный URL (например, /health). Код 200-399 — успех.
  2. TCP Socket: Проверка открытия порта (например, 8080).
  3. Exec: Выполнение команды внутри контейнера (код выхода 0 — успех).

4. Задачи: Jobs и CronJobs

Используются для разовых или периодических действий (бэкапы, очистка БД, отправка отчетов).

  • Job: Одноразовая задача. Под запускается, выполняет работу и переходит в статус Completed.
    • Важно: В Job restartPolicy должна быть OnFailure или Never (нельзя ставить Always).
  • CronJob: Запуск задач по расписанию (аналог Linux Crontab).
    • Формат расписания: * * * * * (минуты, часы, дни и т.д.).
    • На каждый цикл расписания CronJob создает объект Job, который в свою очередь запускает Pod.

Термины и нюансы для запоминания:

  • InitialDelaySeconds: Время ожидания перед первой проверкой (чтобы приложение успело "проснуться").
  • PeriodSeconds: Как часто проводить проверку.
  • Success/FailureThreshold: Сколько раз проверка должна пройти/провалиться подряд для смены статуса.
  • Velero: Основной инструмент для бэкапа и восстановления ресурсов кластера (ConfigMaps, Secrets, PVs) во внешнее хранилище (S3/MinIO).
Retrieved from "https://wiki.baghirzade.pro/index.php?title=Хранилища_(Dynamic_Provisioning),_Пробы_и_задачи_(Jobs)&oldid=195"