Java Interview Questions

Головна / Усі відповіді / Docker Kubernetes

Питання 13 · Розділ 14

Що таке ReplicaSet?

На практиці ReplicaSet рідко створюється напряму — його створює Deployment. Deployment керує ReplicaSet, а ReplicaSet керує Pod'ами.

Ukrainian 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 — відповідальність на інженері.

Adoption існуючих 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]] — масштабування реплік