Java Interview Questions

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

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

Какие типы Service существуют (ClusterIP, NodePort, LoadBalancer)?

В Kubernetes есть 4 типа Service. Они определяют, откуда можно добраться до вашего приложения:

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

Junior уровень

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

В Kubernetes есть 4 типа Service. Они определяют, откуда можно добраться до вашего приложения:

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

  • Доступ: Только внутри Kubernetes кластера
  • Для чего: Связь между микросервисами
  • Пример: Backend обращается к базе данных
apiVersion: v1
kind: Service
metadata:
  name: backend
spec:
  type: ClusterIP       # Можно не указывать — это по умолчанию
  selector:
    app: backend
  ports:
  - port: 80
    targetPort: 8080

NodePort

  • Доступ: Извне на порту каждого сервера (Node)
  • Порты: 30000–32767
  • Для чего: Быстрый доступ для тестирования
spec:
  type: NodePort
  ports:
  - port: 80
    targetPort: 8080
    nodePort: 30080    # Фиксированный порт (или K8s выберет сам)

Обращение: http://<IP-сервера>:30080

LoadBalancer

  • Доступ: Публичный IP от облачного провайдера
  • Для чего: Продакшен в облаке (AWS, GCP, Azure)
spec:
  type: LoadBalancer
  ports:
  - port: 80
    targetPort: 8080

Облако создаёт балансировщик с публичным IP.

// LoadBalancer – это обёртка над NodePort, который – обёртка над ClusterIP, // который перенаправляет на Pod. Три уровня вложенности.

ExternalName

  • Доступ:DNS-алиас на внешний ресурс
  • Для чего: Обращение к внешней БД или API по локальному имени
spec:
  type: ExternalName
  externalName: mydb.example.com

Сводная таблица

Тип Внешний доступ Когда использовать
ClusterIP Нет Внутренняя связь
NodePort Да (порт Node) Тестирование
LoadBalancer Да (публичный IP) Продакшен в облаке
ExternalName Нет* DNS на внешний ресурс

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

  • ClusterIP — только внутри кластера (микросервисы)
  • NodePort — внешний доступ через порт сервера
  • LoadBalancer — публичный IP от облака
  • ExternalName — DNS-алиас на внешний ресурс
  • Для HTTP/HTTPS с несколькими сервисами – Ingress экономит деньги. Для одного сервиса – LoadBalancer проще.

Middle уровень

Как работает каждый тип

ClusterIP

Создаёт виртуальный IP внутри кластера. kube-proxy на каждом Node настраивает iptables правила для маршрутизации.

Use Case: Связь между микросервисами. Backend → Database, Frontend → API.

NodePort

Работает в два этапа:

  1. Трафик приходит на порт Node (30000-32767)
  2. Перенаправляется на ClusterIP Service
  3. ClusterIP балансирует на Pod’ы

Минусы:

  • Нужно знать IP узлов
  • Неудобно управлять множеством портов
  • Нет SSL терминации

LoadBalancer

В облачных средах:

  1. K8s создаёт Service типа NodePort
  2. Запрашивает у облака создание Load Balancer
  3. Облако направляет трафик на NodePort

Use Case: Основная точка входа для внешних клиентов.

Стоимость: Каждый LoadBalancer – отдельный облачный ресурс (~$18-25/мес в AWS). 10 сервисов = $180-250/мес только за балансировщики.

ExternalName

Работает на уровне DNS — возвращает CNAME запись. Не использует селекторы и проксирование.

Use Case: Миграция с монолита — внешний ресурс выглядит как Service K8s.

Что выбрать?

Современная архитектура:

  1. Внутренние связи → ClusterIP
  2. Внешний HTTP/HTTPS → ClusterIP + Ingress (один LB на все сервисы)
  3. Не-HTTP трафик (БД) → LoadBalancer
  4. Внешние ресурсы → ExternalName

Экономия с Ingress

Вместо:

10 сервисов → 10 LoadBalancer → $$$

Используем:

10 сервисов (ClusterIP) → 1 Ingress → 1 LoadBalancer → $

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

  • NodePort — фундамент для LoadBalancer
  • Для экономии: Ingress поверх ClusterIP
  • LoadBalancer напрямую — только для не-HTTP трафика
  • ExternalName — DNS-алиас, не проксирует трафик
  • Разница: L4 (Service) vs L7 (Ingress) балансировка

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

НЕ используйте NodePort в продакшене (небезопасно, неудобно). НЕ используйте LoadBalancer для внутренних сервисов (дорого). НЕ используйте ExternalName для сервисов внутри кластера (бессмысленно).

Senior уровень

Архитектурный анализ типов Service

Выбор типа Service — это выбор уровня暴露在 сети и модели затрат.

Глубокая техническая детализация

LoadBalancer: облачные реализации

Провайдер Реализация Особенности
AWS NLB/ALB NLB (Network Load Balancer) – балансировщик на уровне TCP/UDP. ALB (Application Load Balancer) – на уровне HTTP.
GCP Cloud LB Поддержка internal LB
Azure Azure LB Integration with AKS
On-premise MetalLB BGP или Layer2 mode

Internal LoadBalancer:

annotations:
  networking.gke.io/load-balancer-type: "Internal"  # GCP
  service.beta.kubernetes.io/aws-load-balancer-internal: "true"  # AWS

Создаёт LB, доступный только внутри VPC.

NodePort: ограничения

  • Диапазон портов: 30000-32767 (настраивается в API server: --service-node-port-range)
  • Один порт на Service — невозможно запустить два NodePort на одном порту
  • Firewall: нужно открыть порты на всех Node

LoadBalancer: мультипорт проблемы

Один LoadBalancer Service может экспортировать несколько портов:

ports:
- name: http
  port: 80
  targetPort: 8080
- name: grpc
  port: 9090
  targetPort: 9090

Но это создаёт один LB с двумя listeners. Стоимость = один LB.

Service Mesh интеграция

В Istio:

  • Все Service — ClusterIP
  • Sidecar перехватывает трафик
  • Gateway (вместо Ingress) управляет внешним трафиком
  • mTLS между всеми сервисами автоматически

Troubleshooting LoadBalancer

Проблема: LoadBalancer в Pending статусе.

kubectl get svc
# NAME         TYPE           EXTERNAL-IP   STATUS
# my-service   LoadBalancer   <pending>     ...

Причины:

  1. Нет Cloud Controller Manager
  2. Лимит квоты облака
  3. Неправильные annotations

Решение:

kubectl describe svc my-service  # Смотрим события
# Events: Ensuring load balancer → Error creating load balancer

MetalLB для On-Premise

# MetalLB конфигурация
apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: default
spec:
  addresses:
  - 192.168.1.240-192.168.1.250

BGP mode: анонсирует IP через BGP роутерам. Layer2 mode: один Node принимает трафик, остальные forwarding.

Gateway API – GA с K8s v1.28, постепенно заменяет Ingress.

Kubernetes Gateway API — новая абстракция для внешнего трафика:

  • Более выразительная, чем Ingress
  • Поддержка TCP/UDP, TLS
  • Role-based (infra vs app teams)
kind: Gateway
spec:
  gatewayClassName: istio
  listeners:
  - name: http
    port: 80
    protocol: HTTP

Резюме для Senior

  • Тип Service определяет “область видимости” и модель затрат.
  • NodePort — фундамент для LoadBalancer.
  • Ingress поверх ClusterIP экономит облачные ресурсы.
  • LoadBalancer напрямую — только для не-HTTP протоколов.
  • On-premise: MetalLB для LoadBalancer эмуляции.
  • Gateway API — будущее внешнего трафика в K8s.
  • Service Mesh (Istio) переопределяет networking модель (L7, mTLS).

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

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

  • ClusterIP — только внутри кластера (микросервисы); по умолчанию
  • NodePort — внешний доступ через порт 30000-32767 на каждом Node; для тестирования
  • LoadBalancer — публичный IP от облачного провайдера; для продакшена
  • ExternalName — DNS CNAME на внешний ресурс; без проксирования
  • LoadBalancer = обёртка над NodePort, который = обёртка над ClusterIP
  • Ingress поверх ClusterIP экономит деньги (один LB на все HTTP-сервисы)
  • On-premise: MetalLB эмулирует LoadBalancer (BGP или Layer2 mode)

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

  • «Почему NodePort не для продакшена?» — Нужно знать IP узлов, нет SSL, неудобно управлять портами
  • «Сколько стоит LoadBalancer в AWS?» — ~$18-25/мес за каждый; 10 сервисов = $180-250/мес
  • «LoadBalancer для внутреннего сервиса?» — Нет, дорого и небезопасно; используйте ClusterIP
  • «Gateway API — это что?» — Новое поколение Ingress (GA с K8s v1.28); поддерживает TCP/UDP, не только HTTP

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

  • «NodePort — стандарт для продакшена» (небезопасно, нет HA, неудобно)
  • «LoadBalancer для каждого микросервиса» (дорого; Ingress экономит)
  • «ExternalName проксирует трафик» (только DNS CNAME, не проксирует)
  • «Ingress заменяет все Service» (Ingress для внешнего HTTP, Service для внутренней L4 связи)

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

  • [[Что такое Service в Kubernetes]] — основы Service
  • [[Что такое Ingress в Kubernetes]] — HTTP маршрутизация
  • [[Что такое Kubernetes и зачем он нужен]] — общая архитектура