За счет чего реплика находит поды, которыми нужно управлять

Механизм обнаружения Pod'ов контроллером ReplicaSet

Реплика (имеется в виду объект ReplicaSet) находит поды, которыми ей нужно управлять, за счет системы меток (Labels) и селекторов (Selectors), которая является фундаментальным паттерном декларативного управления в Kubernetes. Этот механизм обеспечивает слабую связность между управляющим объектом (контроллером) и управляемыми объектами (подами).

Ключевые компоненты механизма

1. Селектор (Selector) в манифесте ReplicaSet

    В спецификации ReplicaSet явно определяется `selector`, который содержит критерии для выбора подов. Это правило, по которому контроллер ищет поды в пространстве имен (namespace).

```yaml
apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: my-app-rs
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
      tier: backend
  template:
    metadata:
      labels:
        app: my-app
        tier: backend
    spec:
      containers:
      - name: nginx
        image: nginx:1.21
```

    В этом примере ReplicaSet будет управлять всеми подами, у которых есть метки `app=my-app` И `tier=backend`.

1. Метки (Labels) на Pod'ах

    Это ключевые пары "ключ-значение", присвоенные объектам. Pod'ы, созданные самим ReplicaSet из поля `template`, автоматически получают указанные метки. Однако механизм селектора работает для **всех подов в namespace**, соответствующих критериям, независимо от того, кто их создал.

1. Цикл согласования (Reconciliation Loop)

    Контроллер ReplicaSet работает по принципу бесконечного цикла:
    *   **Наблюдение (Watch):** Он подписывается на события API Kubernetes, связанные с подами в его namespace (создание, удаление, изменение меток).
    *   **Сравнение (Diff):** Он подсчитывает количество **активных подов**, соответствующих его селектору.
    *   **Действие (Action):** Сравнивает текущее количество с желаемым (`spec.replicas`).
        *   Если подов меньше -> создает новые из шаблона `template`.
        *   Если подов больше -> удаляет "лишние" (обычно самые старые).
        *   Если под не соответствует селектору (метки изменились) -> перестает им управлять.

Важные технические детали и гарантии

• Неизменяемость селектора: Ключевое поле spec.selector у ReplicaSet является иммутабельным (неизменяемым после создания). Это предотвращает ситуации, когда контроллер внезапно "отпустит" все текущие поды и создаст новые из-за изменения критериев выбора.
• Уникальность управления: Kubernetes гарантирует, что один Pod может управляться только одним ReplicaSet (или другим workload-контроллером, например, Deployment). Эта связь устанавливается через поле metadata.ownerReferences в объекте Pod. Когда ReplicaSet создает Pod, он записывает себя как его владельца (owner). Если другой контроллер попытается выбрать этот Pod своим селектором, он увидит ownerReferences и не станет им управлять, чтобы избежать конфликта.
• Работа с метками: Если вручную изменить метки у Pod, созданного ReplicaSet, так что он перестанет соответствовать селектору, ReplicaSet "потеряет" этот Pod (перестанет считать его в целевое количество) и создаст новый ему на замену. Исходный Pod, если он не будет удален другим контроллером, останется висеть в кластере как "сирота" (orphaned).

Пример: Допустим, у нас есть ReplicaSet с селектором app=frontend и replicas: 2. В namespace есть три пода:

1. Pod A: app=frontend, env=prod (соответствует, управляется)
2. Pod B: app=frontend (соответствует, управляется)
3. Pod C: app=backend (не соответствует, игнорируется)

ReplicaSet посчитает только Pod A и Pod B. Их количество (2) равно желаемому, поэтому никаких действий не последует. Если Pod B будет удален, ReplicaSet немедленно обнаружит расхождение (стало 1 из 2) и создаст новый Pod D с метками из своего шаблона.

Итог: ReplicaSet находит поды для управления через декларативный селектор меток, действуя как автономный контроллер, который постоянно приводит фактическое состояние кластера к желаемому, описанному в его спецификации. Этот механизм, основанный на метках, обеспечивает гибкость, модульность и надежность оркестрации в Kubernetes.