Перейти на PRO

Какие контроллеры Kubernetes используются для управления жизненным циклом подов (Pods)?

Тип вопроса: DevOps Вероятность: 10% Категория: Golang Разработчик

Ответ

Жизненным циклом подов (Pods) в Kubernetes управляют рабочие нагрузки (Workloads), которые представлены контроллерами. Они реализуют декларативный подход: вы описываете желаемое состояние системы (например, «должно быть запущено 3 экземпляра моего приложения»), а контроллер приводит систему в это состояние и поддерживает его.

Основные контроллеры для управления подами:

  1. Deployment

    • Назначение: Основной контроллер для stateless-приложений (веб-серверы, API-сервисы).
    • Функции: Обеспечивает декларативное обновление подов (Rolling Update), масштабирование (увеличение/уменьшение количества реплик) и возможность отката к предыдущей версии.

  2. StatefulSet

    • Назначение: Для stateful-приложений, которым важна стабильность и порядок (например, базы данных, брокеры сообщений).
    • Функции: Гарантирует стабильные сетевые идентификаторы (например, pod-0, pod-1), порядок развертывания и масштабирования, а также уникальное и постоянное хранилище (Persistent Volumes) для каждого пода.

  3. DaemonSet

    • Назначение: Обеспечивает запуск одного экземпляра пода на каждом (или на выбранных) узле кластера.
    • Примеры использования: Сборщики логов (Fluentd), агенты мониторинга (Prometheus Node Exporter), сетевые плагины.

  4. Job / CronJob

    • Job: Создает один или несколько подов и гарантирует, что заданное их количество успешно завершит свою работу. Используется для разовых задач (миграция БД, обработка данных).
    • CronJob: Управляет объектами Job, запуская их по расписанию (как в cron).

Пример манифеста для Deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3 # Желаемое состояние: 3 пода
  selector:
    matchLabels:
      app: nginx
  template: # Шаблон для создания подов
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.21.6
        ports:
        - containerPort: 80

Ответ 18+ 🔞

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

Вот эти офицеры, блядь:

  1. Deployment

    • Задача: Главный по бесстатусным приложениям. Веб-сервера, апишки — вся эта шелупонь, которой похуй, кто она и где была.
    • Что умеет: Менять версии приложений плавно, без пиздеца (Rolling Update). Хочешь 10 реплик? Хуяк — будет 10. Откатиться на прошлую версию? Да без проблем, ёпта. Главный инструмент для 95% всего.

  2. StatefulSet

    • Задача: Для важных пацанов с состоянием. Базы данных, всякие кафки-редисы. Тем, кому важны порядковый номер, стабильное имя и своя личная, неприкосновенная жопа (хранилище).
    • Что умеет: Гарантирует, что под будет зваться mysql-0, mysql-1 и так далее, и что его диск не отвалят при переезде. Запускает и убивает их по порядку, без паники. Без этого — овердохуища проблем.

  3. DaemonSet

    • Задача: Посадить по одному своему агенту на каждую ноду в кластере. Как политрук в каждом взводе.
    • Где юзают: Сборщики логов (типа Fluentd), шпионы для мониторинга. Чтобы с каждой машины в кластере стекалась инфа, блядь.

  4. Job / CronJob

    • Job: Разовая работёнка. Надо миграцию базы прогнать или файлы обработать? Создаёшь Job — он запустит под(ы), дождётся, пока они благополучно сдохнут (завершатся), и успокоится.
    • CronJob: Тот же Job, но по расписанию. Каждый день в 5 утра делать бэкап? Вот это он, ёперный театр. По сути, крон в мире куберов.

А вот, смотри, как выглядит приказ (манифест) для главного офицера — Deployment. Всё чётко, по уставу:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3 # Желаемое состояние, блядь: чтоб три клона болталось!
  selector:
    matchLabels:
      app: nginx
  template: # А это шаблон, по которому этих клонов штамповать
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.21.6
        ports:
        - containerPort: 80

Короче, суть в чём: ты не говоришь «запусти под, потом ещё один, ой, этот сдох — запусти новый». Ты, как царь и бог, заявляешь: «Должно быть три инстанса nginx версии 1.21.6». А система уже сама, ебушки-воробушки, бегает и делает так, чтобы реальность соответствовала твоей хотелке. Если один подавлен — она создаст новый. Хитро, да?

© ХакСобесов, 2026
support@hacksobesov.com