PrepBro
← Назад к вопросам

Что должно произойти в Kubernetes, чтобы сервис начал отправлять запросы

1.7 Middle🔥 121 комментариев
#Kubernetes

Комментарии (1)

🐱
deepseek-v3.2PrepBro AI6 апр. 2026 г.(ред.)

Ответ сгенерирован нейросетью и может содержать ошибки

Для начала ответ на вопрос: сервис в Kubernetes начинает отправлять запросы после успешного прохождения нескольких ключевых этапов в конвейере управления жизненным циклом Pod и Service. Эти этапы гарантируют, что Pod готов принимать и отправлять трафик, а Service (как абстракция) правильно направляет этот трафик.

Вот последовательность событий, которые приводят к тому, что сервис начинает отправлять запросы:

1. Создание и планирование Pod

Когда создается Pod (например, через kubectl apply или из манифеста), планировщик Kubernetes (kube-scheduler) должен найти подходящий узлов (Node) для размещения Pod. Это происходит на основе:

  • Ресурсов (CPU, memory).
  • Топологии и ограничений (tolerations, node selectors).
  • Приоритетов.

После планирования Pod получает статус Pending.

apiVersion: v1
kind: Pod
metadata:
  name: my-app
spec:
  containers:
    - name: app
      image: nginx:latest

2. Подготовка и запуск контейнера на узле

После планирования Pod отправляется на целевой Node. На узле происходит:

  • Pull образов (Image Pull) из Container Registry (может требовать секреты для авторизации).
  • Создание контейнера и его сети (обычно через CNI-плагин, например Calico или Flannel).
  • Настройка сети: Pod получает уникальный IP адрес из диапазона сети Pod (обычно из CIDR узла).
  • Запуск контейнера.

Pod переходит в состояние Running.

3. Проверка готовности (Readiness Probe)

Если в Pod определена Readiness Probe, она начинает проверять готовность контейнера к приему трафика. Пока проверка не успешна, Pod не будет добавлен в Endpoint-объекты соответствующего Service.

spec:
  containers:
    - name: app
      image: nginx
      readinessProbe:
        httpGet:
          path: /health
          port: 80
        initialDelaySeconds: 5
        periodSeconds: 10

Процесс проверки:

  1. После initialDelaySeconds первая проверка.
  2. Если проверка успешна, Pod считается готовым.
  3. Если неуспешна, Pod остается неготовым до следующей попытки (periodSeconds).

4. Создание или обновление Endpoints

Service в Kubernetes — это абстракция, которая определяет логический набор Pod и политику доступа к ним. Каждому Service соответствует Endpoints (или EndpointSlice в современных версиях) — объект, который содержит список IP адресов Pod, готовых принимать трафик для этого Service.

Контроллер Endpoints (kube-controller-manager) постоянно отслеживает Pod и их статус Readiness. Когда Pod становится готовым (Readiness Probe успешна), его IP адрес добавляется в Endpoints.

# Проверить Endpoints для Service
kubectl get endpoints my-service

Пример Endpoints:

apiVersion: v1
kind: Endpoints
metadata:
  name: my-service
subsets:
  - addresses:
      - ip: 10.244.1.2
      - ip: 10.244.2.3
    ports:
      - port: 80

5. Настройка сетевой маршрутизации (Service Network)

Сеть Service реализуется через kube-proxy или CNI-плагины (например, через iptables, ipvs или сетевые политики сторонних плагинов).

Для kube-proxy (iptables режим):

  • Когда Endpoints обновляются, kube-proxy на каждом узле обновляет правила iptables.
  • Создаются правила для DNAT (Destination NAT) для Service IP (ClusterIP) на IP адресы Pod из Endpoints.
  • Также реализуется балансировка нагрузки (обычно случайная или round-robin через веса правил).

Пример правила iptables:

# Примерный вывод iptables-save
-A KUBE-SERVICES -d 10.96.0.1/32 -p tcp -m tcp --dport 80 -j KUBE-SVC-MYSERVICE
-A KUBE-SVC-MYSERVICE -j KUBE-SEP-1 -m statistic --mode random --probability 0.5
-A KUBE-SVC-MYSERVICE -j KUBE-SEP-2

6. DNS Resolution (CoreDNS)

Для внутреннего DNS в кластере (CoreDNS) также важно:

  • Service получает DNS имя (например, my-service.default.svc.cluster.local).
  • CoreDNS обновляет свои записи на основе Service и Endpoints.
  • Когда Pod отправляет запрос по DNS имени Service, CoreDNS возвращает ClusterIP Service (или напрямую IP Pod для Headless Service).
# Проверка DNS из Pod
kubectl exec -it my-app -- nslookup my-service.default.svc.cluster.local

7. Инициация запроса от Pod

Когда Pod готов и все вышеперечисленные компоненты настроены:

  • Приложение в Pod может отправить запрос на адрес Service (ClusterIP или DNS имя).
  • Трафик перехватывается kube-proxy на узле (или на узле источника, если используется CNI с прямой маршрутизацией).
  • Происходит DNAT на один из IP адресов Pod из Endpoints.
  • Трафик поступает на целевой Pod.

Краткий итог процесса

Чтобы сервис начал отправлять запросы, требуется:

  1. Pod должен быть запущен и готов (Readiness Probe успешна).
  2. Endpoints объект должен содержать IP этого Pod.
  3. kube-proxy (или альтернативный механизм) настроил правила маршрутизации для Service.
  4. DNS (если используется) должен разрешать имя Service.

Если все эти условия выполнены, трафик может начать отправляться от Pod к Service (и далее к другим Pod), а также от внешних клиентов через Ingress или LoadBalancer. Отсутствие любого из этих шагов приведет к невозможности отправки запросов или их неуспешной доставке.