Ответ
Объект Service в Kubernetes решает фундаментальную проблему сетевого доступа к динамическому набору подов. Поскольку поды непостоянны (их IP меняются при рестарте, масштабировании или обновлении), Service предоставляет стабильную конечную точку.
Что он реализует:
- Стабильный DNS-имя и IP (ClusterIP) – Внутри кластера приложения могут обращаться друг к другу по DNS-имени вида
my-service.my-namespace.svc.cluster.local. Это избавляет от хардкода IP-адресов. - Балансировку нагрузки – Service автоматически распределяет трафик между всеми здоровыми подами, соответствующими селектору.
- Абстракцию от подов – Потребляющим сервисам не нужно знать, сколько подов работает "за кулисами".
Типы Service, которые я использовал:
- ClusterIP (по умолчанию): Для внутренней коммуникации между микросервисами.
- NodePort: Для доступа извне кластера через статический порт на каждой ноде. Часто используется для тестирования или когда нет внешнего балансировщика.
- LoadBalancer: В облачных провайдерах (AWS, GCP) автоматически создает внешний балансировщик нагрузки.
- Headless (без ClusterIP): Когда нужен прямой DNS-доступ к IP каждого пода, например, для StatefulSet (Cassandra, Elasticsearch).
Пример Service для внутреннего API:
apiVersion: v1
kind: Service
metadata:
name: api-service
spec:
selector:
app: backend-api # Находит все поды с этим лейблом
tier: production
ports:
- name: http
port: 80 # Порт, на котором Service доступен внутри кластера
targetPort: 3000 # Порт контейнера в поде
type: ClusterIPНа практике я комбинирую Service с Ingress-контроллером (nginx-ingress) для маршрутизации внешнего HTTP/HTTPS трафика на нужные сервисы.