Java Interview Questions

Главная / Все ответы / Docker Kubernetes

Вопрос 11 · Раздел 14

Что такое Service в Kubernetes?

Service -- это не контейнер и не процесс. Это абстрактный сетевой маршрут, который K8s поддерживает автоматически. Pod'ы умирают и пересоздаются с новыми IP, а Service остаётся.

Russian Docker Kubernetes Исходный Markdown
Версии по языкам: English Russian Ukrainian

Junior уровень

Простое объяснение

Service (Сервис) – это стабильный адрес для доступа к группе Pod’ов.

Service – это не контейнер и не процесс. Это абстрактный сетевой маршрут, который K8s поддерживает автоматически. Pod’ы умирают и пересоздаются с новыми IP, а Service остаётся.

Простая аналогия

Представьте, что Pod’ы — это сотрудники в офисе, которые могут менять рабочие места. Service — это общий телефон компании, который всегда один и тот же. Кто бы ни отвечал на звонок, callers набирают один номер.

Зачем нужен Service?

Без Service:

  • Pod упал → новый Pod → новый IP → нужно обновлять конфигурацию
  • Как найти нужное приложение среди сотен Pod’ов?

С Service:

  • Service всегда имеет один IP и DNS-имя
  • Kubernetes сам знает, какие Pod’ы за ним стоят
  • Если Pod упал — Service просто перестаёт направлять туда трафик

Простой пример

apiVersion: v1
kind: Service
metadata:
  name: myapp-service
spec:
  selector:
    app: myapp        # Ищет Pod'ы с этой меткой
  ports:
  - port: 80          # Порт, на котором Service принимает трафик
    targetPort: 8080  # Порт, на который трафик перенаправляется в Pod

// port: 80 – порт, на котором Service принимает трафик. // targetPort: 8080 – порт, на который трафик перенаправляется в Pod. // selector: app=my-app – находит Pod’ы с этим label и направляет на них трафик.

Теперь другие приложения обращаются: http://myapp-service:80

Как Service находит Pod’ы?

Через метки (labels):

  1. У Pod’ов есть метки: app: myapp
  2. Service ищет Pod’ы по этим меткам (selector)
  3. Все найденные Pod’ы попадают в список Endpoints
  4. Kubernetes автоматически обновляет список при изменении Pod’ов

Что запомнить Junior-разработчику

  • Service — стабильный адрес для нестабильных Pod’ов
  • Service находит Pod’ы через метки (selectors)
  • Service балансирует нагрузку между Pod’ами
  • DNS-имя Service: имя-сервиса.неймспейс.svc.cluster.local
  • Внутри кластера можно обращаться просто по имени: http://myapp-service

Когда НЕ использовать Service

НЕ используйте Service для: прямой связи Pod-Pod (используйте Headless Service), L7 маршрутизации (используйте Ingress).

Middle уровень

Как работает Service?

Балансировка нагрузки

Service — это внутренний балансировщик. Когда трафик приходит на IP сервиса, он распределяется между здоровыми Pod’ами.

По умолчанию: случайный выбор (через iptables) или Round-Robin (через IPVS). Service работает на уровне L4 (TCP/UDP).

L4 (транспортный уровень) – балансировка по IP:порт. L7 (прикладной уровень) – балансировка по URL, headers, cookies.

kube-proxy

На каждом Node запущен kube-proxy:

  • Следит за изменениями Service и Endpoints в API
  • Настраивает правила маршрутизации (iptables/IPVS)
  • Когда пакет идёт на ClusterIP, ядро Linux перенаправляет его на Pod

Типы Service

Тип Доступ Когда использовать
ClusterIP Только внутри кластера Связь между микросервисами
NodePort Извне на порту Node Тестирование, простые случаи
LoadBalancer Публичный IP от облака Продакшен в облаке
ExternalName DNS-алиас Доступ к внешним ресурсам

ClusterIP (по умолчанию)

apiVersion: v1
kind: Service
metadata:
  name: backend
spec:
  type: ClusterIP
  selector:
    app: backend
  ports:
  - port: 80
    targetPort: 8080

Доступен только внутри кластера. Используется для связи между микросервисами.

Service Discovery

Kubernetes автоматически создаёт DNS записи для Service’ов:

# Внутри кластера
http://backend:80                  # внутри того же namespace
http://backend.default.svc.cluster.local  # полный адрес

Headless Service

Если clusterIP: None, Service не получает IP. Pod’ы доступны напрямую по DNS:

spec:
  clusterIP: None
  selector:
    app: database

DNS возвращает IP всех Pod’ов. Используется с StatefulSet для прямого доступа к конкретным Pod’ам.

Что запомнить Middle-разработчику

  • Service — L4-балансировщик (TCP/UDP)
  • Связь Service → Pod через Labels и Selectors
  • ClusterIP для внутренней связи, LoadBalancer для внешней
  • kube-proxy реализует Service через iptables/IPVS
  • Headless Service (clusterIP: None) для прямого доступа к Pod’ам

Senior уровень

Service как абстракция сетевого фасада

Service — это не просто балансировщик, это стабильный сетевой интерфейс для динамической группы Pod’ов, которая скрывает эфемерность контейнеров от потребителей сервиса.

Глубокая архитектура: kube-proxy modes

iptables mode (по умолчанию)

  • kube-proxy создаёт iptables правила для каждого Service
  • Каждый Endpoint = набор правил
  • Плюс: нет дополнительного hop
  • Минус: O(n) правил, медленное обновление при большом числе Pod’ов

IPVS mode

  • Использует IPVS (IP Virtual Server) — более масштабируемый
  • Плюс: O(1) lookup, поддержка больше алгоритмов балансировки
  • Минус: требует модулей ядра

Алгоритмы балансировки (IPVS)

  • roundrobin
  • leastconn
  • sourcehash
  • weighted

Service и Endpoints

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

Kubernetes автоматически созда Endpoint объект:

apiVersion: v1
kind: Endpoints
metadata:
  name: api
subsets:
- addresses:
  - ip: 10.0.0.5
  - ip: 10.0.0.6
  ports:
  - port: 8080

EndpointSlice (v1.21+): более масштабируемая версия Endpoints для тысяч Pod’ов.

Service без Selector’а

apiVersion: v1
kind: Service
metadata:
  name: external-db
spec:
  ports:
  - port: 5432
---
apiVersion: v1
kind: Endpoints
metadata:
  name: external-db
subsets:
- addresses:
  - ip: 192.168.1.100  # Внешняя БД
  ports:
  - port: 5432

Позволяет включить внешний ресурс в Service Discovery K8s.

Session Affinity

spec:
  sessionAffinity: ClientIP
  sessionAffinityConfig:
    clientIP:
      timeoutSeconds: 3600

Один клиент всегда попадает на один и тот же Pod. Warning: нарушает принципы stateless архитектуры.

Service Mesh и будущее Service

Service Mesh (Istio, Linkerd) заменяет kube-proxy:

  • L7 балансировка (HTTP headers, cookies)
  • mTLS между сервисами
  • Canary routing
  • Observability (tracing, metrics)

В Istio sidecar-контейнер перехватывает весь трафик и реализует advanced routing.

Производительность и масштабирование

Число Pod’ов iptables IPVS
100 Отлично Отлично
1000 Замедление Хорошо
5000+ Проблемы Отлично

Troubleshooting

# Проверить Service
kubectl get svc myapp
kubectl describe svc myapp

# Проверить Endpoints
kubectl get endpoints myapp

# Проверить DNS
kubectl run -it --rm dns-test --image=busybox --restart=Never -- \
  nslookup myapp-service

# Проверить iptables rules (на Node)
iptables-save | grep myapp-service

Резюме для Senior

  • Service — стабильный L4-фасад для нестабильных Pod’ов.
  • kube-proxy реализует балансировку через iptables (default) или IPVS.
  • EndpointSlice — масштабируемая замена Endpoints для больших кластеров.
  • Session Affinity нарушает stateless принципы — используйте с осторожностью.
  • Для L7 балансировки (HTTP routing) используйте Ingress, не Service.
  • Service без selector — мост к внешним ресурсам.
  • Service Mesh — эволюция networking в K8s (L7, mTLS, observability).

🎯 Шпаргалка для интервью

Обязательно знать:

  • Service — стабильный L4-адрес (IP + DNS) для группы эфемерных Pod’ов
  • Service находит Pod’ы через labels/selectors; обновляет Endpoints автоматически
  • kube-proxy реализует балансировку через iptables (default) или IPVS (масштабируемее)
  • ClusterIP — внутренняя связь, NodePort — внешний доступ, LoadBalancer — облачный IP
  • Headless Service (clusterIP: None) — DNS возвращает IP всех Pod’ов (для StatefulSet)
  • Service без selector + manual Endpoints — мост к внешним ресурсам
  • Для L7 балансировки (HTTP routing) используйте Ingress, не Service

Частые уточняющие вопросы:

  • «Что будет если Pod за Service упадёт?» — kubelet обновит Endpoints; трафик больше не идёт на этот Pod
  • «Чем iptables отличается от IPVS?» — iptables: O(n) правил, IPVS: O(1) lookup, лучше для тысяч Pod’ов
  • «Зачем нужен Headless Service?» — Прямой доступ к конкретным Pod’ам (StatefulSet, базы данных)
  • «Service работает на L4 или L7?» — L4 (TCP/UDP). Для L7 (HTTP) — Ingress

Красные флаги (НЕ говорить):

  • «Service = контейнер с приложением» (это абстрактный сетевой маршрут)
  • «Service заменяет Pod’ы» (Service направляет трафик на Pod’ы)
  • «IPVS всегда лучше iptables» (для маленьких кластеров iptiles проще и достаточно)
  • «Session Affinity — хорошая практика» (нарушает stateless принципы)

Связанные темы:

  • [[Какие типы Service существуют (ClusterIP, NodePort, LoadBalancer)]] — типы Service
  • [[Что такое Pod в Kubernetes]] — что стоит за Service
  • [[Что такое Ingress в Kubernetes]] — L7 маршрутизация