Kubelet и ReplicaSet — управление репликами в Kubernetes

ОБЯЗАТЕЛЬНОДЛЯ НОВИЧКОВ

Разработчику Архитектору Инженеру

Pod как единица запуска

Pod в Kubernetes служит минимальной единицей запуска приложений.

Pod объединяет:

один или несколько контейнеров;
общий IP адрес;
общий сетевой namespace;
общие тома volume;
общий жизненный цикл запуска и остановки.

Практический вывод:

трафик от Service поступает в Pod;
планировщик размещает Pod по нодам;
контроллеры Kubernetes управляют Pod и их количеством.

Реплика и репликация

Реплика служит копией Pod по одному и тому же шаблону.

Репликация решает задачи:

горизонтального масштабирования;
отказоустойчивости приложения;
равномерного распределения нагрузки.

Если число работающих Pod падает ниже целевого, контроллер создает новые копии.

ReplicaSet и Deployment

ReplicaSet поддерживает целевое количество Pod с определенными метками.

Deployment управляет ReplicaSet и добавляет:

плавные обновления версий;
историю ревизий;
откат на рабочую ревизию;
удобное декларативное масштабирование.

В production сценариях основным объектом обычно служит Deployment.

Ключевые термины кластера

Control Plane — управляющий слой Kubernetes;
Node — рабочий сервер, где запускаются Pod;
API Server — центральная API точка;
Scheduler — компонент выбора ноды для Pod;
Controller — процесс поддержки желаемого состояния;
Reconciliation loop — цикл сверки желаемого и фактического состояния;
kubelet — агент на каждой ноде, запускающий контейнеры.

Как Kubernetes доводит YAML до работающих Pod

После команды kubectl apply -f app-deployment.yaml выполняется последовательность:

kubectl отправляет манифест в API Server.
API Server валидирует схему и права доступа.
Конфигурация записывается в etcd.
Контроллер Deployment обнаруживает изменения.
Deployment создает или обновляет ReplicaSet.
ReplicaSet создает недостающие Pod.
Scheduler назначает Pod на ноды.
kubelet на нодах запускает контейнеры через runtime.
Статусы Pod возвращаются в API Server.

Базовый манифест Deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-web-app
  labels:
    app: frontend
spec:
  replicas: 3
  selector:
    matchLabels:
      app: frontend
  template:
    metadata:
      labels:
        app: frontend
    spec:
      containers:
        - name: web
          image: nginx:1.25
          ports:
            - containerPort: 80

Пояснение полей:

metadata.name задает имя ресурса;
spec.replicas задает число Pod;
spec.selector.matchLabels связывает Deployment с Pod;
spec.template определяет шаблон новых Pod;
template.labels совпадают с selector.matchLabels.

Расширенный манифест Deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-web-app
  labels:
    app: frontend
spec:
  replicas: 4
  revisionHistoryLimit: 10
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
  selector:
    matchLabels:
      app: frontend
  template:
    metadata:
      labels:
        app: frontend
    spec:
      terminationGracePeriodSeconds: 30
      containers:
        - name: web
          image: nginx:1.25
          ports:
            - containerPort: 80
          readinessProbe:
            httpGet:
              path: /
              port: 80
            initialDelaySeconds: 5
            periodSeconds: 5
            timeoutSeconds: 2
            failureThreshold: 3
          livenessProbe:
            httpGet:
              path: /
              port: 80
            initialDelaySeconds: 15
            periodSeconds: 10
            timeoutSeconds: 2
            failureThreshold: 3
          resources:
            requests:
              cpu: "100m"
              memory: "128Mi"
            limits:
              cpu: "500m"
              memory: "512Mi"

Практический смысл параметров:

strategy задает правила обновления Pod;
maxSurge и maxUnavailable регулируют скорость rollout;
readinessProbe включает Pod в трафик после успешной проверки;
livenessProbe перезапускает зависший контейнер;
resources управляют потреблением CPU и памяти.

Учебный манифест ReplicaSet

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: web-rs
spec:
  replicas: 2
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: nginx
          image: nginx:1.25
          ports:
            - containerPort: 80

Этот вариант полезен для изучения:

связи selector и labels;
механики поддержания реплик;
поведения контроллера при удалении Pod.

Создание и первичная проверка

kubectl apply -f app-deployment.yaml
kubectl get deployments
kubectl get rs
kubectl get pods -l app=frontend -o wide
kubectl describe deployment my-web-app

Что смотреть в выводе:

READY и AVAILABLE у Deployment;
DESIRED, CURRENT, READY у ReplicaSet;
состояние Pod Running;
число рестартов контейнеров;
события с причинами сбоев.

Масштабирование вверх и вниз

Быстрое увеличение реплик:

kubectl scale deployment my-web-app --replicas=6

Уменьшение реплик:

kubectl scale deployment my-web-app --replicas=2

Декларативный вариант:

Измените replicas в YAML.
Выполните kubectl apply -f app-deployment.yaml.

Проверка:

kubectl get deploy my-web-app
kubectl get rs -l app=frontend
kubectl get pods -l app=frontend -o wide

Перезапуск и пересоздание реплик

Принудительный перезапуск текущих Pod:

kubectl rollout restart deployment my-web-app
kubectl rollout status deployment/my-web-app

Удаление одного Pod с автозаменой:

kubectl delete pod -l app=frontend --field-selector=status.phase=Running

После удаления контроллер создаст новые Pod и вернет нужное количество реплик.

История релизов и откат

Проверка истории rollout:

kubectl rollout history deployment/my-web-app

Откат на предыдущую ревизию:

kubectl rollout undo deployment/my-web-app
kubectl rollout status deployment/my-web-app

Когда это нужно:

новая версия дает ошибки;
probes уходят в сбой;
растут рестарты;
растет доля 5xx.

Роль kubelet на ноде

kubelet работает на каждом рабочем узле и отвечает за запуск Pod на этой ноде.

Задачи kubelet:

получать назначенные Pod из API;
запрашивать загрузку образов;
запускать контейнеры через CRI runtime;
выполнять health checks;
перезапускать контейнеры внутри Pod;
отправлять статусы Pod и ноды.

Важное разделение ответственности:

kubelet управляет жизненным циклом контейнеров на конкретной ноде;
Deployment и ReplicaSet поддерживают количество реплик в масштабе всего кластера.

Probes в деталях

readinessProbe отвечает за готовность Pod к обслуживанию трафика.

livenessProbe отвечает за обнаружение зависшего контейнера.

startupProbe применяется для долгого старта приложения.

Практика настройки:

проверка должна быть быстрой;
endpoint проверки должен отражать текущее состояние;
тайминги должны учитывать реальный startup профиль приложения;
ложные срабатывания уменьшают стабильность сервиса.

Пример блока probes

readinessProbe:
  httpGet:
    path: /healthz/ready
    port: 8080
  initialDelaySeconds: 10
  periodSeconds: 5
  timeoutSeconds: 2
  successThreshold: 1
  failureThreshold: 3

livenessProbe:
  httpGet:
    path: /healthz/live
    port: 8080
  initialDelaySeconds: 30
  periodSeconds: 10
  timeoutSeconds: 2
  failureThreshold: 3

startupProbe:
  httpGet:
    path: /healthz/startup
    port: 8080
  periodSeconds: 5
  failureThreshold: 30

Подсказки:

readinessProbe работает с включением Pod в Service;
livenessProbe корректно настраивается на симптомы зависания;
startupProbe защищает от преждевременных liveness срабатываний.

Graceful shutdown приложения

Перед остановкой Pod Kubernetes отправляет сигнал SIGTERM.

Корректный shutdown включает:

остановку приема новых запросов;
завершение текущих запросов;
закрытие подключений к внешним системам;
выход процесса до окончания terminationGracePeriodSeconds.

Сопутствующие элементы:

preStop hook;
корректные probes;
контроль времени остановки в логах.

Что происходит при сбоях

Сбой контейнера на рабочей ноде:

kubelet фиксирует проблему;
контейнер перезапускается;
Pod сохраняет размещение на ноде.

Сбой ноды:

control plane помечает ноду недоступной;
Pod на этой ноде становятся недоступными;
ReplicaSet создает недостающие Pod на других узлах.

Распределение Pod по нодам

kubectl get pods -l app=frontend -o wide
kubectl get nodes
kubectl top pods -l app=frontend
kubectl top nodes

Проверяйте:

размещение Pod по нескольким нодам;
состояние нод Ready;
пики CPU и памяти;
повторяющиеся рестарты.

Команды kubectl top используют metrics-server.

Частые ошибки и симптомы

Типовые ошибки:

selector не совпадает с labels;
probes настроены слишком агрессивно;
отсутствуют resources requests и limits;
слишком мало реплик для production;
ручные правки в кластере без фиксации в YAML.

Типовые статусы:

ImagePullBackOff при ошибке образа или доступа в registry;
CrashLoopBackOff при циклическом падении процесса;
Pending при нехватке ресурсов или ограничениях scheduler;
OOMKilled при недостатке памяти.

Диагностика проблем по шагам

kubectl get pods -A
kubectl describe pod <pod-name> -n <namespace>
kubectl logs <pod-name> -n <namespace> --tail=200
kubectl logs <pod-name> -n <namespace> --previous
kubectl get events -n <namespace> --sort-by=.metadata.creationTimestamp

Рабочий алгоритм:

Найдите проблемный Pod и статус.
Проверьте события через describe.
Изучите текущие и предыдущие логи.
Проверьте события namespace.
Сверьте состояние Deployment и ReplicaSet.

Сценарий роста нагрузки

Увеличьте число реплик.
Дождитесь rollout status.
Проверьте Ready Pod.
Проверьте распределение по нодам.
Зафиксируйте новое значение в YAML.

kubectl scale deployment my-web-app --replicas=8
kubectl rollout status deployment/my-web-app
kubectl get pods -l app=frontend -o wide
kubectl top pods -l app=frontend

Сценарий аварийного отката

Обнаружьте деградацию по логам и метрикам.
Посмотрите ревизии rollout.
Выполните rollout undo.
Подтвердите восстановление.

kubectl rollout history deployment/my-web-app
kubectl rollout undo deployment/my-web-app
kubectl rollout status deployment/my-web-app
kubectl get rs -l app=frontend

Ежедневный набор команд

# Применить изменения
kubectl apply -f app-deployment.yaml

# Проверить состояние приложения
kubectl get deploy,rs,pods -l app=frontend

# Масштабировать
kubectl scale deployment my-web-app --replicas=5

# Перезапустить текущий релиз
kubectl rollout restart deployment my-web-app

# Проверить ход выката
kubectl rollout status deployment/my-web-app

# Диагностика конкретного Pod
kubectl describe pod <pod-name>
kubectl logs <pod-name> --previous

Kubelet и ReplicaSet — управление репликами в Kubernetes

Pod как единица запуска

Реплика и репликация

ReplicaSet и Deployment

Ключевые термины кластера

Как Kubernetes доводит YAML до работающих Pod

Базовый манифест Deployment

Расширенный манифест Deployment

Учебный манифест ReplicaSet

Создание и первичная проверка

Масштабирование вверх и вниз

Перезапуск и пересоздание реплик

История релизов и откат

Роль kubelet на ноде

Probes в деталях

Пример блока probes

Graceful shutdown приложения

Что происходит при сбоях

Распределение Pod по нодам

Частые ошибки и симптомы

Диагностика проблем по шагам

Сценарий роста нагрузки

Сценарий аварийного отката

Ежедневный набор команд

Дополнительные материалы в разделе

Официальные ссылки Kubernetes

См. также

Контейнеризация

Docker

docker-compose

Объекты Docker

Docker Desktop

DockerHub и реестры образов

Работа с Docker

Сеть в контейнерах

Dockerfile

Docker Swarm и Kubernetes

Реализация Kubernetes

Первые шаги с Docker и Kubernetes

Pod как единица запуска​

Реплика и репликация​

ReplicaSet и Deployment​

Ключевые термины кластера​

Как Kubernetes доводит YAML до работающих Pod​

Базовый манифест Deployment​

Расширенный манифест Deployment​

Учебный манифест ReplicaSet​

Создание и первичная проверка​

Масштабирование вверх и вниз​

Перезапуск и пересоздание реплик​

История релизов и откат​

Роль kubelet на ноде​

Probes в деталях​

Пример блока probes​

Graceful shutdown приложения​

Что происходит при сбоях​

Распределение Pod по нодам​

Частые ошибки и симптомы​

Диагностика проблем по шагам​

Сценарий роста нагрузки​

Сценарий аварийного отката​

Ежедневный набор команд​

Дополнительные материалы в разделе​

Официальные ссылки Kubernetes​

Связанные темы

См. также

Контейнеризация

Docker

docker-compose

Объекты Docker

Docker Desktop

DockerHub и реестры образов

Работа с Docker

Сеть в контейнерах

Dockerfile

Docker Swarm и Kubernetes

Реализация Kubernetes

Первые шаги с Docker и Kubernetes

Pod как единица запуска

Реплика и репликация

ReplicaSet и Deployment

Ключевые термины кластера

Как Kubernetes доводит YAML до работающих Pod

Базовый манифест Deployment

Расширенный манифест Deployment

Учебный манифест ReplicaSet

Создание и первичная проверка

Масштабирование вверх и вниз

Перезапуск и пересоздание реплик

История релизов и откат

Роль kubelet на ноде

Probes в деталях

Пример блока probes

Graceful shutdown приложения

Что происходит при сбоях

Распределение Pod по нодам

Частые ошибки и симптомы

Диагностика проблем по шагам

Сценарий роста нагрузки

Сценарий аварийного отката

Ежедневный набор команд

Дополнительные материалы в разделе

Официальные ссылки Kubernetes