ReplicaSet — это контроллер в Kubernetes, цель которого — поддерживать заданное количество копий одинаковых Pod-ов. Он следит за тем, чтобы в кластере всегда было именно столько Pod-ов, сколько указано в spec.replicas, и создаёт/удаляет Pod-ы по необходимости.

Основные идеи

• Единица контроля — ReplicaSet оперирует группой Pod-ов, выбранных через селектор (.spec.selector), и поддерживает их количество (.spec.replicas).

• Селектор — шаблон меток (label selector). ReplicaSet управляет только теми Pod-ами, метки которых соответствуют селектору и которые не имеют другого контроллера (ownerReference). Поле .spec.selector становится неизменяемым после создания. ReplicaSet поддерживает наборные селекторы (in, notin), гибче, чем старый ReplicationController.

• Шаблон Pod — .spec.template описывает образ, порты, probes, ресурсы и т.д.; ReplicaSet использует этот шаблон для создания новых Pod-ов.

Как он работает (контроллерный цикл)

1. ReplicaSet смотрит текущее состояние (сколько Pod-ов соответствует селектору).

2. Если текущих Pod меньше, чем spec.replicas — он создаёт недостающие Pod-ы по шаблону.

3. Если их больше — удаляет избыточные (по алгоритму удаления).

4. Статус отражается в .status (поля replicas, readyReplicas, availableReplicas, fullyLabeledReplicas, observedGeneration).

Взаимодействие с Deployment

• На практике ReplicaSet почти всегда создаётся Deployment-ом. Deployment управляет ReplicaSet-ами: при обновлении шаблона он создаёт новый ReplicaSet, масштабирует новый вверх и старый вниз (rolling update). ReplicaSet — низкоуровневый объект; для управления версиями/обновлениями используют Deployment.

• ReplicaSet, созданный Deployment-ом, получает ownerReference на этот Deployment; при удалении Deployment (по умолчанию) связанные ReplicaSet и Pod удаляются каскадно.

Примеры команд

• kubectl get rs — список ReplicaSet.

• kubectl describe rs my-rs — подробности, события, какие Pod-ы управляются.

• kubectl scale rs/my-rs --replicas=5 — изменить число реплик (ReplicaSet отзовётся и создаст/удалит Pod-ы).

• Обычно же масштабируют Deployment: kubectl scale deploy/my-app --replicas=10.

Статусы важные для наблюдения

• replicas — текущее число Pod, созданных контроллером.

• readyReplicas — сколько Pod готовы принимать трафик.

• availableReplicas — сколько Pod доступны (по readiness и minReadySeconds).

• fullyLabeledReplicas — сколько Pod имеют все нужные метки.

Практические замечания и best practices

• Не управляйте ReplicaSet напрямую, если вам нужны обновления/история — используйте Deployment. ReplicaSet полезен как понятный контроллер, но Deployment даёт стратегии обновлений и rollback.

• Избегайте перекрывающихся селекторов — если два ReplicaSet имеют селектор, совпадающий с одними и теми же Pod, получится конфликт/неожиданное поведение.

• Не меняйте селектор после создания — он, как правило, неизменяем; чтобы изменить набор Pod, создайте новый ReplicaSet/Deployment.

• Подсмотрите в kubectl describe rs — там видно создание/удаление Pod и события, полезно при отладке.

ReplicaSet vs ReplicationController vs StatefulSet (в одном абзаце)

• ReplicaSet — современный вариант контроля реплик, поддерживает set-based селекторы.

• ReplicationController — старый, с более ограниченными селекторами (в большинстве сценариев заменён ReplicaSet).

• StatefulSet — похож по идее (поддерживает нужное число реплик), но добавляет стабильные имена/персистентные тома для stateful-приложений; применяется для БД, Kafka и т.п.

ReplicaSet — простая и надёжная часть контроллерной логики Kubernetes: она гарантирует, что нужное число Pod-ов живёт и здорово, но для управления жизненным циклом приложения (катки обновлений, история, откаты) обычно используют Deployment поверх ReplicaSet.