Service в Kubernetes решает задачу обнаружения сервисов (service discovery): Pod-ы эфемерны, их IP-адреса меняются при каждом перезапуске. Service создаёт стабильный virtual IP (ClusterIP) и DNS-запись, балансируя трафик по всем Pod-ам, соответствующим label selector.
Типы Service
- ClusterIP (по умолчанию) — доступен только внутри кластера. IP виден только внутри кластерной сети.
- NodePort — открывает порт на каждой ноде кластера (30000–32767). Доступен извне через IP_ноды:порт.
- LoadBalancer — создаёт внешний балансировщик нагрузки облачного провайдера (AWS ELB, GCP LB). Автоматически получает публичный IP.
- ExternalName — маппирует Service на внешнее DNS-имя (CNAME). Используется для обращения к внешним сервисам.
Пример манифеста
apiVersion: v1
kind: Service
metadata:
name: my-nginx
spec:
selector:
app: nginx # выбирает Pod-ы с этим label
ports:
- port: 80 # порт Service
targetPort: 80 # порт Pod
type: ClusterIPkube-proxy
kube-proxy работает на каждой ноде и реализует сетевые правила Service через iptables или IPVS. При создании Service kube-proxy добавляет правила iptables: весь трафик на ClusterIP перенаправляется к одному из Pod-ов через round-robin.
DNS
CoreDNS (компонент Kubernetes) автоматически создаёт DNS-запись для каждого Service: service-name.namespace.svc.cluster.local. Pod-ы обращаются к сервисам по имени: http://my-nginx/ без хардкоженых IP.
История
Service — один из первых объектов Kubernetes, появился в версии 1.0 (июнь 2014). Изначально реализован через userspace kube-proxy. В Kubernetes 1.2 (2016) появился режим iptables, в 1.11 (2018) — IPVS как более производительная альтернатива. EndpointSlices заменили Endpoints в Kubernetes 1.21 (2021) для масштабируемости.
Связь с хостингом
Service типа LoadBalancer — стандартный способ опубликовать приложение из Kubernetes в интернет через балансировщик нагрузки облачного провайдера. В managed Kubernetes (EKS, GKE) создание LoadBalancer Service автоматически провизионирует облачный балансировщик. На bare-metal можно использовать MetalLB для эмуляции LoadBalancer.
Типы Kubernetes Service
| Тип | Доступность | Применение |
|---|---|---|
| ClusterIP | только внутри кластера | внутренние микросервисы |
| NodePort | порт на каждой ноде (30000-32767) | разработка, тестирование |
| LoadBalancer | внешний IP от провайдера | продакшн на облаке |
| ExternalName | CNAME внешнего DNS | внешние сервисы |
| Headless | DNS без ClusterIP | StatefulSets, базы данных |
История Service в Kubernetes
Концепция Service введена в Kubernetes v0.4 (2014). До этого поды адресовались напрямую по IP. kube-proxy реализует Service через iptables (до K8s 1.8) и через IPVS (с K8s 1.11). Селекторы (selector) позволяют динамически добавлять поды без изменения адреса сервиса. Ingress — надстройка над Service для HTTP-роутинга на уровне Layer 7.
Практическое применение
Service на хостинге — абстракция для стабильного DNS-имени внутри кластера. При деплое на VPS с k3s LoadBalancer-сервис создаёт реальный TCP-прокси. Команды: kubectl get services, kubectl expose deployment nginx --port=80 --type=LoadBalancer. Service типа ClusterIP с Ingress-контроллером — стандарт для продакшн-деплоев.
Типичные ошибки
- Использование NodePort в продакшне — нестандартные порты неудобны для пользователей.
- Несовпадение labels и selector — Service не видит поды.
- Использование LoadBalancer на bare-metal без MetalLB — сервис зависает в Pending состоянии.
Для WordPress в Kubernetes: Service типа ClusterIP направляет трафик к подам WordPress, Nginx Ingress распределяет HTTP-запросы. MySQL подключается через Service с типом ClusterIP — приложение обращается по DNS-имени сервиса (mysql-service:3306).