Как поведет себя сервис, если будет несколько реплик Pod

При наличии нескольких реплик Pod, управляемых одним контроллером (например, Deployment), сервис Kubernetes обеспечивает отказоустойчивость и балансировку нагрузки. Я настраиваю это так:

Как это работает:

1. Создание реплик: Deployment создает N идентичных Pods, распределяя их по нодам кластера (с учетом ограничений ресурсов и anti-affinity правил).
2. Единая точка входа: Сервис (Service) типа ClusterIP с селектором, совпадающим с лейблами Pods, создает виртуальный IP-адрес и DNS-имя внутри кластера.
3. Балансировка: kube-proxy на каждой ноде настраивает правила iptables или IPVS, которые перенаправляют трафик, отправленный на ClusterIP сервиса, на один из IP-адресов бэкенд-Pods. Алгоритм по умолчанию — random с равномерным распределением.

Пример манифеста Deployment и Service:

# Deployment с 3 репликами
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web-app
  template:
    metadata:
      labels:
        app: web-app
    spec:
      containers:
      - name: app
        image: myapp:latest
        ports:
        - containerPort: 8080
        livenessProbe:          # Критично для здоровья
          httpGet:
            path: /health
            port: 8080
        readinessProbe:         # Критично для балансировки
          httpGet:
            path: /ready
            port: 8080
---
# Сервис, балансирующий трафик между Pods
apiVersion: v1
kind: Service
metadata:
  name: web-app-service
spec:
  selector:
    app: web-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
  type: ClusterIP

Поведение при сбоях:

• Если Pod падает (и его livenessProbe fails), kubelet перезапускает его.
• Если Pod становится неготовым (его readinessProbe fails), Service немедленно исключает его из списка эндпоинтов для балансировки. Новые запросы на него не идут.
• Контроллер Deployment постоянно следит за желаемым количеством реплик. Если Pod уничтожен и не перезапускается, Deployment создаст новый Pod на другой ноде, чтобы восстановить счетчик, и Service автоматически добавит его в балансировку после успешной readinessProbe.

Для stateful приложений (например, БД) вместо Deployment используется StatefulSet, который обеспечивает стабильные идентификаторы Pod и томов, но базовый принцип балансировки через Service остается.