Service

Поды в Kubernetes постоянно создаются и удаляются заново (при rolling update, при сбое — см. тему «Pod, Deployment»), и каждый раз получают новый IP-адрес. Service — стабильный, постоянный адрес, через который можно достучаться до подов, не зная их реальных меняющихся IP.

apiVersion: v1
kind: Service
metadata:
  name: my-app-service
spec:
  selector:
    app: my-app             # выбирает все поды с этой меткой
  ports:
    - port: 80
      targetPort: 8080

Другие сервисы обращаются по стабильному имени my-app-service, а Kubernetes сам направляет запрос на один из живых подов с меткой app: my-app, какой бы IP у них сейчас ни был.

Копнуть глубже

Service автоматически балансирует нагрузку между всеми подами, попадающими под selector — запросы распределяются между всеми живыми копиями, не нужно настраивать отдельный балансировщик нагрузки вручную для базового сценария.

Типы Service по доступности:

Тип	Доступность
`ClusterIP` (по умолчанию)	только внутри кластера, для общения сервисов друг с другом
`NodePort`	открывает порт на каждой ноде кластера, доступен снаружи
`LoadBalancer`	создаёт внешний балансировщик нагрузки (у облачного провайдера)

Это та же идея Service Discovery, что у Eureka в Spring Cloud (см. тему «Config, Gateway, Eureka») — только реализованная на уровне самого Kubernetes, а не отдельной Java-библиотекой. В Kubernetes-окружении часто не нужен Eureka отдельно — встроенный Service уже решает ту же задачу обнаружения сервисов по стабильному имени.

🎤 Закрыл тему, если можешь объяснить:

• зачем нужен Service, если у подов и так есть IP;
• разницу ClusterIP, NodePort, LoadBalancer и как Service связан с Eureka по идее (если дошёл до 2-го слоя).