Какие знаешь сущности для управления Pod в Kubernetes?

Сущности Kubernetes для управления Pod'ами

В Kubernetes существует несколько ключевых API-ресурсов (сущностей), которые используются для управления Pod'ами на разных уровнях абстракции. Pod является атомарной единицей развёртывания, но напрямую создавать Pod'ы в продакшене не рекомендуется. Вот основные сущности:

Основные контроллеры работы (Workload Controllers)

1. Deployment

Наиболее часто используемый ресурс для управления stateless-приложениями. Обеспечивает declarative-обновления, rollback, scaling и высокую доступность ReplicaSet'ов.

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.19
        ports:
        - containerPort: 80

2. StatefulSet

Используется для stateful-приложений (базы данных, очереди), где важны:

• Устойчивые идентификаторы (pod-0, pod-1)
• Устойчивое сетевое имя (DNS)
• Устойчивое хранилище (PersistentVolume)
• Упорядоченное развёртывание и масштабирование

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: mysql
spec:
  serviceName: "mysql"
  replicas: 3
  selector:
    matchLabels:
      app: mysql
  template:
    metadata:
      labels:
        app: mysql
    spec:
      containers:
      - name: mysql
        image: mysql:8.0
        volumeMounts:
        - name: data
          mountPath: /var/lib/mysql
  volumeClaimTemplates:
  - metadata:
      name: data
    spec:
      accessModes: ["ReadWriteOnce"]
      resources:
        requests:
          storage: 10Gi

3. DaemonSet

Гарантирует, что Pod будет запущен на всех (или выбранных) узлах кластера. Используется для:

• Системных демонов (логирование, мониторинг)
• Сетевых плагинов (CNI)
• Агентов хранения

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluentd-logging
spec:
  selector:
    matchLabels:
      name: fluentd
  template:
    metadata:
      labels:
        name: fluentd
    spec:
      containers:
      - name: fluentd
        image: fluentd:latest

4. Job и CronJob

• Job создаёт один или несколько Pod'ов для выполнения задачи до успешного завершения
• CronJob создаёт Job'ы по расписанию (cron-формат)

apiVersion: batch/v1
kind: CronJob
metadata:
  name: backup-job
spec:
  schedule: "0 2 * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: backup
            image: backup-tool:latest
          restartPolicy: OnFailure

5. ReplicaSet

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

Дополнительные сущности управления

PodDisruptionBudget (PDB)

Ограничивает количество добровольных нарушений работы Pod'ов во время maintenance операций (обновление узлов, масштабирование).

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: app-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: critical-app

PodTemplate

Шаблон Pod'а, который используется другими ресурсами (Deployment, StatefulSet и т.д.). Не является самостоятельным объектом API.

PodSecurityPolicy (PSP) (устаревшее в v1.21, удалено в v1.25)

Контролировал security-sensitive аспекты спецификации Pod'ов. Заменён на Pod Security Standards и Pod Security Admission.

Современные альтернативы и best practices

1. Pod Security Admission - встроенный admission controller для enforcing Pod Security Standards
2. VerticalPodAutoscaler (VPA) и HorizontalPodAutoscaler (HPA) для автоматического масштабирования
3. ResourceQuotas и LimitRanges для управления ресурсами на уровне namespace
4. Init Containers и Sidecar Containers внутри Pod спецификации
5. Pod Affinity/Anti-Affinity и Node Affinity для управления размещением

Ключевые принципы выбора:

• Stateless веб-приложения → Deployment
• Базы данных, очереди → StatefulSet
• Системные демоны на всех узлах → DaemonSet
• Периодические задачи → CronJob
• Одноразовые задачи → Job

На практике 90% использования приходится на Deployment, так как большинство современных приложений проектируются как stateless. StatefulSet требует тщательного проектирования и понимания особенностей stateful-приложений в распределённых системах.