intermediate

Service

Давайте стабильную виртуальную сеть и балансировку для меняющегося набора podов по labels.

Service даёт стабильную виртуальную сеть для меняющегося набора pod'ов по labels. Клиенты обращаются к DNS-имени Service, а не к IP pod'ов.

| Тип | Типичное применение | |-----|---------------------| | ClusterIP | Внутренний app-to-app трафик (по умолчанию) | | NodePort | Порт на каждой ноде (dev/legacy) | | LoadBalancer | Облачный LB перед pod'ами | | Headless | Прямой DNS pod'ов для StatefulSet |

					apiVersion: v1
kind: Service
metadata:
  name: api
spec:
  selector:
    app: api
  ports:
    - port: 80
      targetPort: 3000

Ingress обычно маршрутизирует внешний HTTP к Service — не напрямую к IP pod'ов.

На интервью: типы Service, selectors, `port` vs `targetPort`, headless и связь с Ingress.

Типовые ошибки: неверный selector молча указывает на ноль или чужие pod'ы; LoadBalancer на каждый сервис.

Компромисс — простое exposure (LoadBalancer везде) против least-privilege в сети.

Чеклист:

Точное совпадение selectors.
Тип Service по потребности exposure.
HTTP через Ingress где уместно.
Проверка endpoints через `kubectl get endpoints`.