ReplicaSet
Тема дорожной карты · Kubernetes
ReplicaSet — контроллер рабочих нагрузок Kubernetes, гарантирующий, что указанное количество идентичных реплик Pod'ов работает в любое время; заменяет упавшие или удалённые Pod'ы для поддержания объявленного значения spec.replicas. Контроллер ReplicaSet в kube-controller-manager использует селектор меток — определённый в spec.selector.matchLabels — для идентификации принадлежащих ему Pod'ов и согласует текущее количество с желаемым состоянием, создавая или удаляя Pod'ы через kube-apiserver. На практике ReplicaSet редко создаётся напрямую; вместо этого Deployment управляет ReplicaSet от вашего имени, создавая новые ReplicaSet при rolling-обновлениях и масштабируя старые вниз, сохраняя историю ревизий для kubectl rollout undo. ReplicaSet поддерживает горизонтальное масштабирование через kubectl scale replicaset <name> --replicas=<n> или автоматически через HPA, который корректирует spec.replicas на основе загрузки CPU или пользовательских метрик Prometheus. Понимание модели владения ReplicaSet — отслеживаемой через metadata.ownerReferences — важно для диагностики осиротевших Pod'ов и неожиданного поведения масштабирования в кластерах Kubernetes.
Как это работает
ReplicaSet — один из workload-примитивов Kubernetes. Определяет желаемое состояние набора pods — число реплик, pod template, стратегия обновления — а контроллер непрерывно сводит реальное состояние к желаемому. При падении pod или ноды контроллер планирует замену. При обновлении pod template контроллер оркестрирует rolling update с health-проверками между батчами.
Когда применять
Выбирайте ReplicaSet по характеристикам нагрузки: Deployment для stateless-сервисов (HTTP API, воркеры), StatefulSet для stateful с stable network identity (БД, очереди), DaemonSet для one-pod-per-node инфраструктуры (log-коллекторы, CNI), Job для batch-задач, CronJob для запланированных batch. Смешивание типов без нужды создаёт операционную сложность; выбирайте простейший подходящий примитив.
Типичные ошибки
Workload-ловушки: слишком низкие resource requests (pods scheduled, но выселяются под нагрузкой) или слишком высокие (кластер выглядит полным при малом реальном использовании); отсутствие liveness/readiness-проб (load balancer шлёт трафик на полу-стартанутые pods); использование Deployment для stateful-нагрузок, которым нужна StatefulSet-упорядоченность. Всегда измеряйте реальное использование ресурсов до sizing.