Что отслеживает и гарантирует ReplicaSet в Kubernetes?

«Что отслеживает и гарантирует ReplicaSet в Kubernetes?» — вопрос из категории Kubernetes, который задают на 23% собеседований Devops Инженер. Ниже — развёрнутый ответ с разбором ключевых моментов.

Ответ

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 отслеживает и исправляет автоматически:

  1. Под падает (CrashLoopBackOff): Kubelet на узле сообщает о смерти контейнера. ReplicaSet видит, что текущих подов стало 2, и немедленно создает новый (pod-4), чтобы вернуть общее количество к 3.
  2. Узел (Node) становится недоступным: Поды на этом узле переходят в состояние Unknown/NodeLost. Control Plane, в конечном счете, удаляет их. ReplicaSet создает новые поды на других рабочих узлах.
  3. Я вручную удаляю под: kubectl delete pod message-processor-abcde. ReplicaSet интерпретирует это как сокращение количества и создает замену.

Что ReplicaSet НЕ делает (в отличие от Deployment):

  • Не управляет обновлениями образов. Если я изменю image в шаблоне пода существующего ReplicaSet, он не обновит работающие поды. Для этого используется Deployment, который управляет ReplicaSet'ами и обеспечивает стратегические обновления (rolling update, blue-green).
  • Не отслеживает "здоровье" пода за пределами его простого существования. За проверку готовности пода отвечают readinessProbe и livenessProbe, определенные в спецификации контейнера.

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