Java Interview Questions

Главная / Все ответы / Docker Kubernetes

Вопрос 13 · Раздел 14

Что такое ReplicaSet?

На практике ReplicaSet редко создаётся напрямую — его создаёт Deployment. Deployment управляет ReplicaSet, а ReplicaSet управляет Pod'ами.

Russian Docker Kubernetes Исходный Markdown
Версии по языкам: English Russian Ukrainian

Junior уровень

Простое объяснение

ReplicaSet (RS) — это контроллер Kubernetes, который гарантирует, что заданное количество копий (реплик) Pod’ов всегда работает. Если Pod упал — ReplicaSet запустит новый.

На практике ReplicaSet редко создаётся напрямую — его создаёт Deployment. Deployment управляет ReplicaSet, а ReplicaSet управляет Pod’ами.

Простая аналогия

ReplicaSet — как менеджер в магазине, который следит, чтобы на кассе всегда работало нужное число кассиров. Если один ушёл на перерыв — менеджер зовёт другого.

Как работает ReplicaSet?

  1. Вы говорите: “Мне нужно 3 копии приложения”
  2. ReplicaSet проверяет: “Сколько сейчас работает?”
  3. Если меньше 3 — запускает новые Pod’ы
  4. Если больше 3 — удаляет лишние
  5. Повторяет постоянно (Reconciliation Loop)

Пример

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: myapp-rs
spec:
  replicas: 3              # Хочу 3 копии
  selector:
    matchLabels:
      app: myapp           # Ищет Pod'ы с этой меткой
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp
        image: myapp:1.0

ReplicaSet vs Deployment

ReplicaSet vs Deployment: ReplicaSet гарантирует N копий Pod. Deployment добавляет rolling updates, rollback, историю ревизий. В 99% случаев используйте Deployment.

В реальности вы почти никогда не создаёте ReplicaSet вручную. Вместо этого используете Deployment — он управляет ReplicaSet’ами за вас.

Deployment добавляет:

  • Rolling updates (обновление без простоя)
  • Rollback (откат к предыдущей версии)
  • Историю версий

Что запомнить Junior-разработчику

  • ReplicaSet поддерживает нужное число Pod’ов
  • Если Pod упал — ReplicaSet создаст новый
  • В продакшене используйте Deployment, не ReplicaSet
  • Deployment управляет ReplicaSet’ами
  • Селекторы меток связывают ReplicaSet с Pod’ами

Middle уровень

Reconciliation Loop (Цикл сверки)

ReplicaSet работает по принципу бесконечного цикла:

1. Прочитать desired replicas из spec.replicas
2. Посчитать текущие Pod'ы по selector
3. Если меньше desired → создать Pod'ы
4. Если больше desired → удалить Pod'ы
5. Подождать и повторить

Этот цикл обеспечивает самовосстановление: сколько бы Pod’ов ни упало, ReplicaSet всегда стремится к desired state.

Связь с Deployment

Deployment
    ↓ управляет
ReplicaSet v1 (image: myapp:1.0, replicas: 0)  ← старая версия
ReplicaSet v2 (image: myapp:2.0, replicas: 3)  ← текущая версия
    ↓ управляет
Pod × 3

При обновлении Deployment:

  1. Создаёт новый ReplicaSet с новым образом
  2. Постепенно переносит Pod’ы из старого RS в новый
  3. Старый RS сохраняется для rollback

Селекторы

ReplicaSet использует set-based selectors:

selector:
  matchLabels:
    app: myapp
    env: production

# Или более сложные:
selector:
  matchExpressions:
  - key: app
    operator: In
    values: [myapp, myapp-v2]
  - key: env
    operator: NotIn
    values: [development]

ownerReference

Каждый Pod имеет ссылку на свой ReplicaSet:

metadata:
  ownerReferences:
  - apiVersion: apps/v1
    kind: ReplicaSet
    name: myapp-rs-abc123
    uid: ...

Это позволяет K8s автоматически удалять Pod’ы при удалении ReplicaSet.

Почему не ReplicationController?

ReplicationController — устаревший (legacy) объект. ReplicaSet отличается поддержкой set-based selectors с операторами In, NotIn, Exists.

Что запомнить Middle-разработчику

  • ReplicaSet = механизм поддержания числа реплик
  • Reconciliation Loop постоянно сверяет desired vs actual
  • Deployment управляет ReplicaSet’ами для rolling updates
  • Set-based selectors мощнее простых matchLabels
  • ownerReference обеспечивает каскадное удаление

Senior уровень

ReplicaSet как примитив обеспечения отказоустойчивости

ReplicaSet — это низкоуровневый контроллер, который реализует фундаментальный паттерн Kubernetes: declarative state reconciliation.

Архитектура ReplicaSet Controller

kube-controller-manager
    └── replicaset-controller
            ├── Watch ReplicaSet changes
            ├── Watch Pod changes
            ├── Sync: compare desired vs actual
            ├── Scale up: create Pods
            └── Scale down: delete Pods

Controller подписан на события:

  • Создание/изменение ReplicaSet
  • Удаление Pod’ов (чтобы заменить их)
  • Изменение Pod’ов, подходящих под selector

Pod Disruption и ReplicaSet

При kubectl drain или node eviction:

  1. Pod’ы помечаются для удаления
  2. ReplicaSet видит уменьшение числа Pod’ов
  3. Создаёт новые Pod’ы на других Node
  4. drain завершается, старые Pod’ы удалены

Overlapping Selectors: опасность

# ReplicaSet A
selector:
  matchLabels:
    app: myapp
    tier: frontend

# ReplicaSet B
selector:
  matchLabels:
    app: myapp

Если Pod имеет метки app: myapp, tier: frontend, оба RS могут пытаться им управлять. Это приводит к неопределённому поведению.

Защита: Kubernetes не запрещает overlapping selectors — ответственность на инженере.

Adoptsion существующих Pod’ов

ReplicaSet может “захватить” уже существующие Pod’ы:

# Pod создан вручную
kubectl run myapp --image=myapp:1.0 --labels=app=myapp

# Создаём RS с тем же selector
# RS "видит" существующий Pod и adopts его

Это используется при миграции с manual Pod на Deployment.

Масштабирование ReplicaSet

# Imperative
kubectl scale rs myapp-rs --replicas=5

# Через kubectl edit
kubectl edit rs myapp-rs

# Через patch
kubectl patch rs myapp-rs -p '{"spec":{"replicas":5}}'

Когда создавать ReplicaSet напрямую?

Практически никогда. Единственные сценарии:

  1. Обучение/понимание K8s internals
  2. Кастомные контроллеры (на базе ReplicaSet логики)
  3. Специфические use cases, где Deployment не подходит

Troubleshooting

Pod’ы не создаются:

kubectl describe rs myapp-rs
# Events: Normal  SuccessfulCreate  pod/myapp-xyz created
# Warning FailedCreate      error creating pods

Слишком много Pod’ов:

  • Проверьте overlapping selectors
  • Проверьте, не создаёт ли Pod’ы другой контроллер

Pod’ы не удаляются:

  • Проверьте PodDisruptionBudget
  • Проверьте finalizers на Pod’ах

Резюме для Senior

  • ReplicaSet гарантирует N копий приложения.
  • Это низкоуровневый механизм, которым управляет Deployment.
  • Reconciliation Loop — фундаментальный паттерн K8s.
  • RS не умеет обновлять образы — это логика Deployment.
  • Overlapping selectors → неопределённое поведение.
  • ownerReference обеспечивает каскадное удаление.
  • Используйте метки с осторожностью, чтобы RS случайно не удалил чужие Pod’ы.

🎯 Шпаргалка для интервью

Обязательно знать:

  • ReplicaSet гарантирует заданное число реплик Pod’ов (reconciliation loop)
  • В 99% случаев используйте Deployment, не ReplicaSet напрямую
  • Deployment управляет ReplicaSet’ами для rolling updates и rollback
  • Reconciliation Loop: desired vs actual → создать/удалить Pod’ы → повторить
  • ownerReference обеспечивает каскадное удаление Pod’ов при удалении RS
  • Overlapping selectors → неопределённое поведение (два RS конкурируют)
  • ReplicationController — устаревший (legacy); ReplicaSet поддерживает set-based selectors

Частые уточняющие вопросы:

  • «Зачем ReplicaSet если есть Deployment?» — Deployment — высокоуровневая абстракция; RS — механизм под капотом
  • «Что будет если удалить ReplicaSet?» — Все Pod’ы удаляются (ownerReference каскад)
  • «ReplicaSet умеет обновлять образы?» — Нет, это логика Deployment
  • «Может ли RS захватить существующие Pod’ы?» — Да, если Pod подходит под selector (adoption)

Красные флаги (НЕ говорить):

  • «Создаю ReplicaSet напрямую в продакшене» (используйте Deployment)
  • «ReplicaSet делает rolling updates» (это Deployment)
  • «Overlapping selectors — не проблема» (приводит к race conditions)
  • «ReplicationController — современный стандарт» (устарел, используйте ReplicaSet)

Связанные темы:

  • [[Что такое Kubernetes и зачем он нужен]] — контроллеры K8s
  • [[Как организовать rolling update в Kubernetes]] — Deployment + RS
  • [[Как происходит масштабирование в Kubernetes]] — масштабирование реплик