Чем управляется pod в Kubernetes?

Управление Pod в Kubernetes

В Kubernetes Pod — это наименьшая и самая простая единица развертывания, представляющая собой один или несколько контейнеров, которые разделяют сетевые пространства и хранилище. Управление Pod осуществляется не напрямую, а через контроллеры (Controllers) — высокоуровневые абстракции, которые обеспечивают декларативное управление состоянием приложений. Основная идея: вы описываете желаемое состояние (например, "должно работать 3 реплики приложения"), а контроллеры автоматически приводят текущее состояние к этому желаемому.

Основные контроллеры, управляющие Pod

Вот ключевые контроллеры, отвечающие за жизненный цикл Pod:

1. Deployment — самый распространенный контроллер для статутных приложений. Он управляет реплицируемыми наборами Pod, обеспечивает:

   • Обновление приложений (rolling updates, rollback).
   • Масштабирование (изменение количества реплик).
   • Самовосстановление (перезапуск Pod при сбоях).

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: my-app
   spec:
     replicas: 3
     selector:
       matchLabels:
         app: my-app
     template:
       metadata:
         labels:
           app: my-app
       spec:
         containers:
         - name: nginx
           image: nginx:1.21
   

2. StatefulSet — управляет stateful-приложениями, где важны:

   • Устойчивые идентификаторы Pod (имена вида app-0, app-1).
   • Устойчивое хранилище (PersistentVolume для каждого Pod).
   • Упорядоченное развертывание и масштабирование. Используется для баз данных (например, MySQL, MongoDB) и распределенных систем.

3. DaemonSet — обеспечивает запуск одного Pod на каждом узле (или на подмножестве узлов). Типичные сценарии:

   • Логирование (например, Fluentd).
   • Мониторинг (например, Node Exporter).
   • Сетевые плагины (например, Calico).

   apiVersion: apps/v1
   kind: DaemonSet
   metadata:
     name: fluentd-logging
   spec:
     selector:
       matchLabels:
         name: fluentd
     template:
       spec:
         containers:
         - name: fluentd
           image: fluent/fluentd-kubernetes-daemonset:v1-debian
   

4. Job — создает Pod для выполнения одноразовой задачи, которая завершается успешно. Управляет:

   • Запуском до успешного завершения.
   • Параллельным выполнением нескольких Pod (через parallelism). Пример: батч-обработка данных, миграции БД.

5. CronJob — управляет периодическими задачами по расписанию (как cron в Linux). Запускает Job по заданному расписанию.

6. ReplicaSet — низкоуровневый контроллер, обеспечивающий поддержание заданного числа идентичных Pod. Обычно не используется напрямую, а через Deployment, который управляет ReplicaSet.

Как происходит управление Pod?

Контроллеры взаимодействуют с API-сервером Kubernetes, который является "мозгом" кластера. Механизм управления основан на цикле контроля (control loop):

1. Наблюдение (Observe): Контроллер через API-сервер наблюдает за текущим состоянием Pod (например, сколько Pod работает с меткой app=my-app).
2. Анализ (Diff): Сравнивает текущее состояние с желаемым (declared state), указанным в манифесте (например, replicas: 3).
3. Действие (Act): Если состояния отличаются, контроллер выполняет действия:
   • Создает новые Pod (если реплик меньше).
   • Удаляет лишние Pod (если реплик больше).
   • Заменяет Pod (при обновлении образа или сбое).

Роль Scheduler и Kubelet

Хотя контроллеры управляют жизненным циклом Pod, их размещение и выполнение обеспечивают другие компоненты:

• Scheduler (Планировщик): Назначает Pod на конкретные узлы (Nodes) на основе политик, ресурсов и ограничений. Контроллер создает Pod в состоянии Pending, а Scheduler выбирает узел и привязывает Pod к нему.
• Kubelet: Агент на каждом узле, который непосредственно управляет контейнерами внутри Pod:
  • Получает спецификацию Pod от API-сервера.
  • Запускает контейнеры через container runtime (например, containerd).
  • Отслеживает состояние и отправляет отчеты обратно.
  • Выполняет пробы жизнеспособности (liveness/readiness probes).

Пример потока управления

Допустим, вы создаете Deployment с 3 репликами:

1. Вы применяете манифест Deployment через kubectl apply.
2. Deployment-контроллер создает ReplicaSet.
3. ReplicaSet обнаруживает, что нужно 3 Pod, и создает 3 объекта Pod через API-сервер.
4. Scheduler видит Pod в состоянии Pending и назначает их на доступные узлы.
5. Kubelet на каждом назначенном узле запускает контейнеры согласно спецификации Pod.
6. ReplicaSet продолжает мониторить состояние: если один Pod падает, он создает новый.

Важность декларативного подхода

Kubernetes использует декларативную модель: вы описываете что хотите (желаемое состояние), а система решает как этого достичь. Это отличает его от императивных систем, где вы даете команды ("запусти 3 контейнера"). Контроллеры — это механизм реализации этой парадигмы, обеспечивающий автоматическое самовосстановление (self-healing) и высокую доступность приложений.

Таким образом, Pod никогда не управляются вручную в production-средах. Вместо этого вы работаете с контроллерами, которые гарантируют, что фактическое состояние кластера всегда соответствует вашим намерениям, выраженным в YAML-манифестах или через инструменты вроде Helm. Это делает Kubernetes надежной платформой для оркестрации контейнерных workloads в масштабе.