Что отслеживает ReplicaSet

Что отслеживает ReplicaSet в Kubernetes?

В Kubernetes ReplicaSet — это контроллер, который гарантирует, что в любой момент времени работает заданное количество идентичных подов (реплик). Его главная задача — отслеживать состояние подов, соответствующих определённым селекторам меток, и поддерживать желаемое количество живых экземпляров приложения, указанное в поле .spec.replicas. Если говорить точнее, ReplicaSet непрерывно мониторит (отслеживает) несколько ключевых аспектов:

1. Соответствие подов селекторам меток (Label Selectors)

ReplicaSet использует селектор меток (.spec.selector) для идентификации подов, которыми он управляет. Он отслеживает все поды в кластере, проверяя, есть ли среди них поды с метками, соответствующими его селектору.

• Если под с подходящими метками уже существует и управляется этим ReplicaSet, он считается частью набора реплик.
• Если под с такими метками существует, но не управляется этим ReplicaSet (например, создан вручную), ReplicaSet не будет его трогать, чтобы избежать конфликтов управления.

2. Текущее количество работающих подов (Current Replicas)

ReplicaSet постоянно сравнивает желаемое количество реплик (.spec.replicas) с фактическим количеством подов, соответствующих его селектору.

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: myapp-replicaset
spec:
  replicas: 3  # <- ЖЕЛАЕМОЕ состояние
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp-container
        image: nginx:latest

Он вычисляет разницу: Разница = Желаемое количество - Текущее количество.

3. Состояние (фаза) каждого управляемого пода (Pod Phase)

ReplicaSet отслеживает фазу (Pending, Running, Succeeded, Failed, Unknown) каждого пода в своём наборе. Это критически важно для поддержания доступности:

• Failed или Unknown поды перестают считаться "работающими" и могут быть заменены новыми.
• Удалённые поды (например, из-за сбоя узла или ручного удаления) также выводятся из подсчёта текущего состояния.

Цикл управления ReplicaSet (Control Loop)

На основе отслеживаемых данных срабатывает бесконечный цикл управления:

1. Обнаружение (Observe): ReplicaSet запрашивает API-сервер Kubernetes, чтобы получить список всех подов и отфильтровать те, которые соответствуют его селектору.
2. Сравнение (Diff): Сравнивает текущее количество с желаемым.
3. Действие (Act):

    *   Если **подов меньше, чем нужно** (например, пода удалили или он упал), ReplicaSet создаёт новые поды, используя шаблон (`.spec.template`).
    *   Если **подов больше, чем нужно** (редкий случай, но возможен при изменении селектора), ReplicaSet удаляет "лишние" поды (обычно самые старые).

Пример жизненного цикла в терминалах

Предположим, у нас есть ReplicaSet, который должен поддерживать 3 реплики (replicas: 3).

# Создаём ReplicaSet из манифеста
kubectl apply -f replicaset.yaml

# Проверяем состояние
kubectl get replicaset myapp-replicaset
# NAME                DESIRED   CURRENT   READY
# myapp-replicaset    3         3         3

# Симуляция сбоя: принудительно удаляем один под
kubectl delete pod myapp-replicaset-abc12

# ReplicaSet ОБНАРУЖИВАЕТ, что текущее количество подов (2) меньше желаемого (3).
# Он НЕМЕДЛЕННО создаёт новый под, чтобы восстановить баланс.

kubectl get pods
# NAME                      READY   STATUS    RESTARTS   AGE
# myapp-replicaset-xyz34   1/1     Running   0          5m
# myapp-replicaset-def56   1/1     Running   0          5m
# myapp-replicaset-ghi78   1/1     Running   0          10s <- НОВЫЙ под

Чего ReplicaSet НЕ отслеживает?

Важно понимать ограничения ReplicaSet:

• Обновления приложения: ReplicaSet не отслеживает и не управляет обновлениями образа контейнера или конфигурации. Для этого используются Deployments, которые управляют ReplicaSet'ами и обеспечивают стратегические обновления (rolling update, blue-green).
• Готовность приложения: ReplicaSet проверяет фазу пода (Running), но не проверяет готовность самого приложения внутри контейнера (liveness/readiness probes). Это задача Kubelet и Service.
• Состояние узлов (Nodes): ReplicaSet сам не отслеживает здоровье узлов. Если узел становится недоступным, Node Controller отмечает его, и все поды на нём переходят в состояние Failed или Unknown. ReplicaSet, обнаружив недостачу подов, затем создаст новые на других рабочих узлах.

Итог

ReplicaSet — это фундаментальный механизм обеспечения отказоустойчивости и масштабируемости на уровне подов. Он отслеживает количество и принадлежность подов через селекторы меток и гарантирует, что фактическое состояние кластера всегда соответствует декларативно заданному желаемому состоянию, автоматически исцеляя сбои. Однако для полноценного управления жизненным циклом приложения он используется не напрямую, а как строительный блок внутри более высокоуровневых абстракций, таких как Deployment.