ReplicaSet: зачем нужны реплики
Один под — это одна точка отказа; ReplicaSet держит нужное число одинаковых подов живыми.
ReplicaSet — контроллер, который гарантирует, что в кластере всегда запущено заданное число одинаковых подов.
Голый под не переживёт падение узла. Решение — держать несколько одинаковых копий. Этим занимается ReplicaSet: его задача — поддерживать счётчик. Сказали «хочу 3» — он следит, чтобы всегда было ровно 3. Удалили один под — ReplicaSet тут же создаст замену.
Манифест ReplicaSet
apiVersion: apps/v1
kind: ReplicaSet
metadata:
name: web-rs
spec:
replicas: 3 # хотим 3 копии
selector:
matchLabels:
app: web # какими подами управлять
template: # шаблон пода
metadata:
labels:
app: web # метка должна совпасть с selector
spec:
containers:
- name: nginx
image: nginx:1.27Ключевая связка: selector.matchLabels должен совпадать с метками в template. По меткам ReplicaSet «узнаёт свои» поды.
Самовосстановление в действии
Создадим и убьём один под, чтобы увидеть восстановление:
kubectl apply -f web-rs.yaml
kubectl get pods
kubectl delete pod web-rs-abc12
kubectl get podsВывод:
# было 3 пода web-rs-abc12 1/1 Running web-rs-de34f 1/1 Running web-rs-gh56k 1/1 Running # удалили один — мгновенно появился новый web-rs-de34f 1/1 Running web-rs-gh56k 1/1 Running web-rs-xy78z 1/1 Running # ← замена
Вы удалили под, а кластер тут же создал новый: фактическое число (2) разошлось с желаемым (3), и контроллер устранил расхождение. Это и есть reconciliation loop вживую.
Почему ReplicaSet не используют напрямую
ReplicaSet умеет держать число подов, но не умеет аккуратно обновлять их версию. Для этого есть Deployment — обёртка над ReplicaSet, которая добавляет управляемые обновления и откаты. На практике вы пишете Deployment, а ReplicaSet он создаёт под капотом. Понимать ReplicaSet важно, чтобы видеть, как устроен Deployment.
Итог
- ReplicaSet поддерживает заданное число одинаковых подов.
- Свои поды он находит по меткам через selector.
- Напрямую его почти не пишут — используют Deployment поверх него.