Service и Ingress

Почему нельзя обращаться к pod-у напрямую

Первый инстинкт при деплое в Kubernetes — взять IP pod-а и звонить на него напрямую. Именно этот инстинкт и приводит к провалу из хука выше. Вот почему это никогда не будет работать надёжно.

Pod — самая дешёвая и одноразовая вещь в Kubernetes. Планировщик убивает его, перепланирует, масштабирует вверх и вниз, по своей прихоти переносит на другой узел — и каждый раз, возвращаясь, он получает новый IP из сети pod-ов. Нет стабильного адреса, который можно зашить, нет DNS-имени, переживающего раскатку, нет гарантии, что IP, который ты разрезолвил секунду назад, всё ещё принадлежит живому pod-у. Звонить напрямую на IP pod-а — баг, ждущий следующего перепланирования.

Service — это фикс. Это API-объект, дающий набору pod-ов одну стабильную идентичность: виртуальный IP (ClusterIP) и DNS-имя (<service>.<namespace>.svc.cluster.local), которые живут всё время существования Service, независимо от того, какие pod-ы стоят за ним прямо сейчас. Клиенты ходят на Service; Service балансирует каждое соединение по здоровым pod-ам. Pod-ы под ним сменяются; адрес впереди не двигается.

Механизм selector → endpoints

Связь между Service и его pod-ами — это label-ы, а не IP. Service объявляет selector — набор ключей/значений label-ов, — и Kubernetes непрерывно следит за pod-ами, которые (а) совпадают по каждому label из selector и (б) Ready (проходят свой readiness-probe). Для каждого такого pod-а он записывает его IP и порт в EndpointSlice (современный шардированный список точек назначения, пришедший на смену единому объекту Endpoints). Этот EndpointSlice и есть список целей балансировки; kube-proxy (агент уровня ядра на каждом узле) программирует data plane (правила iptables или IPVS) по нему.

apiVersion: v1
kind: Service
metadata:
  name: api
spec:
  selector:
    app: api            # должен точно совпадать с label-ами pod-ов
  ports:
    - name: http
      port: 80          # виртуальный порт Service
      targetPort: 8080  # порт контейнера в pod-е

Из этого следуют две вещи. Во-первых, сопоставление динамическое: масштабируешь Deployment вверх — и новые Ready-pod-ы добавляются в slice за мгновения; pod, проваливший readiness-probe, удаляется, и трафик перестаёт на него идти без всякого удаления вручную. Во-вторых — и это провал, который кусает всех — если selector не находит ни одного Ready-pod-а, EndpointSlice пуст, и Service маршрутизирует в никуда. У него всё ещё есть ClusterIP, он всё ещё резолвится в DNS, всё ещё принимает соединения — а потом отказывает или отваливается по таймауту, потому что нет бэкенда, куда форвардить.

Типы Service: как далеко дотягивается адрес

У каждого Service есть тип, решающий, кто до него дотянется. Они стакаются: каждый строится на предыдущем.

Все эти типы — одно решение: как далеко за пределы кластера должен дотягиваться трафик? Начни с ClusterIP для всего внутреннего; тянись к Ingress — а не к LoadBalancer — как только нужна HTTP-маршрутизация в публичный интернет.

ClusterIP — это дефолт и рабочая лошадка: так твой API ходит к базе, к кэшу — всё по DNS-имени, всё внутри. NodePort открывает один и тот же порт на каждом узле и форвардит его на Service; это грубая ручка, чтобы завести трафик внутрь, полезная в dev или когда ты ставишь впереди свой балансировщик, но сырой URL node-ip:31000 пользователям не отдашь. LoadBalancer просит облачного провайдера поднять настоящий внешний балансировщик, указывающий на Service, — чисто, но ты платишь за и обслуживаешь один LB на Service, что быстро становится дорого и громоздко. headless вообще отказывается от виртуального IP: DNS возвращает индивидуальные IP pod-ов — ровно то, что нужно StatefulSet (база, брокер), чтобы клиенты могли адресовать конкретную реплику.

Ingress: одна парадная дверь для многих Service

Если LoadBalancer даёт один облачный LB на Service, то десять публичных сервисов стоят десяти балансировщиков — и при этом у тебя по-прежнему нет HTTP-осознанной маршрутизации. Ingress решает и то, и другое. Это L7 (HTTP/HTTPS) роутер, который стоит впереди твоих ClusterIP-Service и раскидывает запросы по host и path на нужный Service, централизованно терминирует TLS и делает всё это за одним общим балансировщиком. Одна точка входа, много бэкендов, гораздо дешевле, чем LB на сервис.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: site
spec:
  ingressClassName: nginx
  rules:
    - host: app.example.com
      http:
        paths:
          - path: /api
            pathType: Prefix
            backend:
              service:
                name: api      # маршрутизирует /api -> Service api
                port:
                  number: 80
          - path: /
            pathType: Prefix
            backend:
              service:
                name: web      # всё остальное -> Service web
                port:
                  number: 80

Ключевой подвох: объект Ingress — это лишь правила. Сам по себе он ничего не делает. Ты обязан запустить ingress-контроллер — nginx, Traefik, HAProxy, провайдерский, — который реально следит за объектами Ingress и превращает их в работающий обратный прокси. Нет контроллера — нет маршрутизации; YAML применяется чисто, а трафик всё равно идёт в никуда. Поле ingressClassName говорит Kubernetes, какой контроллер владеет этим Ingress.

Классический провал: ноль endpoint-ов

Вернись к хуку. Сетевой баг Kubernetes №1 — это Service, чей selector не совпадает с label-ами его pod-ов. При apply ничего не падает — Service это валидный YAML, получает ClusterIP, резолвится в DNS. Но его selector не находит ни одного Ready-pod-а, поэтому EndpointSlice пуст, и каждое соединение отказывается или отваливается по таймауту. Тот же симптом пустых endpoint-ов даёт и pod, который совпал по label-ам, но не Ready (провальный или слишком строгий readiness-probe), или targetPort, не совпадающий с реальным портом контейнера.

Диагностика всегда одна и та же команда: kubectl get endpoints <svc> (или kubectl get endpointslices). Если там <none> или нет адресов — Service ни с кем не говорит: перестань отлаживать приложение и иди проверь, что selector у Service ровно равен label-ам pod-ов и что pod-ы Ready.