Может ли Deployment в Kubernetes существовать без ReplicaSet?

Question

Может ли Deployment в Kubernetes существовать без ReplicaSet?

Тип вопроса: Kubernetes Вероятность: 24% Категория: Devops Инженер

Ответ

Нет, Deployment не может существовать или функционировать без ReplicaSet. Deployment — это абстракция более высокого уровня, которая управляет ReplicaSet'ами для реализации декларативных обновлений, откатов и масштабирования приложений.

Как это работает:

Когда вы создаёте Deployment, Kubernetes сразу создаёт под капотом первый ReplicaSet для управления Pod'ами согласно заданной спецификации (spec.template).
При обновлении образа (например, kubectl set image deployment/nginx nginx=nginx:1.19) Deployment создаёт новый ReplicaSet с обновлённым Pod template и начинает постепенный rollout.
Старый ReplicaSet сохраняется (по умолчанию) для возможности быстрого отката (kubectl rollout undo).

Практический пример:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: frontend
spec:
  replicas: 3
  selector:
    matchLabels:
      app: frontend
  template:
    metadata:
      labels:
        app: frontend
    spec:
      containers:
      - name: nginx
        image: nginx:1.18-alpine
        ports:
        - containerPort: 80

После применения этого манифеста можно увидеть связь:

# Показать Deployment
kubectl get deployment frontend
# Показать управляемые ReplicaSet'ы (имя содержит хэш template)
kubectl get replicaset -l app=frontend
# Показать Pod'ы, созданные ReplicaSet'ом
kubectl get pods -l app=frontend

Что произойдёт, если удалить ReplicaSet вручную? Deployment немедленно заметит расхождение между желаемым состоянием (3 реплики) и фактическим (0 реплик) и автоматически создаст новый ReplicaSet, который, в свою очередь, создаст новые Pod'ы. Это демонстрирует принцип работы control loop'а в Kubernetes.

Альтернативы для прямого управления Pod'ами: Если вам нужен синглтон-под или специфическое управление жизненным циклом без стратегий обновления, можно использовать:

StatefulSet — для stateful-приложений с устойчивыми идентификаторами и хранилищем.
DaemonSet — для запуска пода на каждой (или группе) нод.
Job/CronJob — для задач, которые должны завершиться.

Ответ 18+ 🔞

Давай разберёмся, что тут за ебушки-воробушки с этими Deployment и ReplicaSet. Ты спрашиваешь, может ли Deployment жить без ReplicaSet? Нет, блядь, ни в коем случае. Это как спросить: «А может ли машина ехать без колёс?». Может, конечно, но только нахуй в кювет, и то один раз.

Deployment — это такой начальник-умник, который сам ничего руками не делает. Его работа — сидеть, курить бамбук и командовать. А всю чёрную работу — создавать, убивать и перезапускать поды — выполняет его подчинённый, ReplicaSet. Deployment просто говорит: «Хочу три копии моего приложения, образ такой-то». А ReplicaSet уже бежит, потеет и делает.

Как эта парочка работает, ёпта:

Ты создал Deployment — и тут же, не успел глазом моргнуть, Kubernetes создаёт первый ReplicaSet, который начинает штамповать поды как горячие пирожки.
Захотел обновить версию приложения (kubectl set image ...). Deployment не лезет в старый ReplicaSet с криками «переделай!». Он поступает как хитрая жопа: создаёт новый, параллельный ReplicaSet с обновлённым шаблоном и начинает потихоньку передавать ему работу. Старый при этом не удаляет — вдруг откатываться придётся? Умно, сука.
Откатился? Deployment просто даёт пинка новому ReplicaSet'у и говорит старому: «Работай давай, родной». Всё.

Смотри на практике, вот тебе манифест:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: frontend
spec:
  replicas: 3
  selector:
    matchLabels:
      app: frontend
  template:
    metadata:
      labels:
        app: frontend
    spec:
      containers:
      - name: nginx
        image: nginx:1.18-alpine
        ports:
        - containerPort: 80

Применил это дело, а потом посмотри, что под капотом:

# Глянь на самого шефа
kubectl get deployment frontend
# А теперь посмотри на его работяг — ReplicaSet'ы (с хэшами в имени, чтоб не путались)
kubectl get replicaset -l app=frontend
# Ну и на результат их труда — поды
kubectl get pods -l app=frontend

А что если накосячить и удалить ReplicaSet вручную? О, это классика! Ты думаешь: «А, да похуй, удалю-ка я эту свою мудень». Удалил. И тут Deployment просыпается, смотрит — а его верный работяга исчез, и подов тоже нет. Он просто охуевает на секунду от такой наглости. А потом, не моргнув и глазом, создаёт новый, свеженький ReplicaSet, который моментально восстанавливает все поды. Вот что значит система с мозгами, а не просто набор конфигов.

Если тебе не нужен этот цирк с обновлениями? Бывает, что стратегии rollout'а нахуй не сдались, а нужен один специфический под или чтобы на каждой ноде по экземпляру крутился. Тогда Deployment — это как танк для похода в магазин. Смотри другие инструменты:

StatefulSet — для приложений, которые любят, чтобы у них всё по полочкам: постоянные имена, свой диск. Базы данных, например.
DaemonSet — чтобы штука (типа агента для сбора логов) сидела на каждой ноде, как ядрёна вошь.
Job/CronJob — для задач, которые должны сделать дело, отчитаться «ёб твою мать, готово!» и сдохнуть. Или просыпаться по расписанию.

Короче, Deployment без ReplicaSet — это как анекдот про чукчу: «Пианино есть, играть нехуй».