В чем разница между ReplicaSet и Deployment в Kubernetes?

ReplicaSet и Deployment — это контроллеры, управляющие Pod'ами, но Deployment — это абстракция более высокого уровня, которая инкапсулирует и расширяет функциональность ReplicaSet.

ReplicaSet — базовый контроллер. Его единственная задача — поддерживать заданное количество идентичных реплик Pod'ов (replicas: N). Если Pod падает, ReplicaSet создает новый. Он не умеет управлять обновлениями приложения.

Deployment — основной объект для управления stateless-приложениями. Он управляет ReplicaSet'ами. Когда вы обновляете Pod template (например, образ контейнера), Deployment создает новый ReplicaSet с обновленной спецификацией и начинает контролируемый процесс замены Pod'ов согласно заданной стратегии обновления (strategy).

Пример Deployment с rolling update:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1        # Можно создать на 1 Pod больше желаемого количества
      maxUnavailable: 0  # Нельзя уменьшать количество доступных Pod'ов ниже 3
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: app
        image: myregistry/app:v2.0.0 # Обновление образа здесь
        ports:
        - containerPort: 8080

Ключевые преимущества Deployment:

1. Обновления без простоя: Поддерживает стратегии RollingUpdate (постепенная замена) и Recreate (удалить все, затем создать новые).
2. Откат (rollback): Команда kubectl rollout undo deployment/my-app вернет предыдущую стабильную версию. История ревизий хранится.
3. Контроль состояния: Команды kubectl rollout status/pause/resume.

Практика: В продакшене ReplicaSet почти никогда не создается вручную. Все stateless-ворклоады описываются через Deployment. ReplicaSet'ы, которые вы видите в выводе kubectl get rs, — это внутренние объекты, создаваемые Deployment'ами для управления ревизиями.