Ответ
ReplicaSet — это контроллер, который гарантирует, что в любой момент времени работает заданное (spec.replicas) количество идентичных подов (Pods). Его основная и единственная ответственность — поддержание желаемого количества реплик.
Как это работает на практике:
Допустим, я создал ReplicaSet с replicas: 3 для приложения-воркера.
apiVersion: apps/v1
kind: ReplicaSet
metadata:
name: message-processor-rs
spec:
replicas: 3
selector: # Критичное поле: ReplicaSet ищет поды по этим лейблам
matchLabels: # для управления.
app: message-processor
template:
metadata:
labels: # Лейблы в шаблоне пода ДОЛЖНЫ совпадать с селектором.
app: message-processor
spec:
containers:
- name: worker
image: myapp/worker:v1
Сценарии, которые ReplicaSet отслеживает и исправляет автоматически:
- Под падает (CrashLoopBackOff): Kubelet на узле сообщает о смерти контейнера. ReplicaSet видит, что текущих подов стало 2, и немедленно создает новый (pod-4), чтобы вернуть общее количество к 3.
- Узел (Node) становится недоступным: Поды на этом узле переходят в состояние
Unknown/NodeLost. Control Plane, в конечном счете, удаляет их. ReplicaSet создает новые поды на других рабочих узлах. - Я вручную удаляю под:
kubectl delete pod message-processor-abcde. ReplicaSet интерпретирует это как сокращение количества и создает замену.
Что ReplicaSet НЕ делает (в отличие от Deployment):
- Не управляет обновлениями образов. Если я изменю
imageв шаблоне пода существующего ReplicaSet, он не обновит работающие поды. Для этого используетсяDeployment, который управляет ReplicaSet'ами и обеспечивает стратегические обновления (rolling update, blue-green). - Не отслеживает "здоровье" пода за пределами его простого существования. За проверку готовности пода отвечают
readinessProbeиlivenessProbe, определенные в спецификации контейнера.
В реальных сценариях я почти всегда работаю с Deployment, который внутри создает и управляет ReplicaSet'ами, добавляя возможности обновления и отката.