Які типи Service існують (ClusterIP, NodePort, LoadBalancer)?

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

Працює у два етапи:

Трафік приходить на порт Node (30000-32767)
Переспрямовується на ClusterIP Service
ClusterIP балансує на Pod’и

Мінуси:

Потрібно знати IP вузлів
Незручно керувати великою кількістю портів
Немає SSL термінації

LoadBalancer

В хмарних середовищах:

K8s створює Service типу NodePort
Запитує у хмари створення Load Balancer
Хмара направляє трафік на NodePort

Use Case: Основна точка входу для зовнішніх клієнтів.

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

ExternalName

Працює на рівні DNS — повертає CNAME запис. Не використовує селектори і проксування.

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

Що обрати?

Сучасна архітектура:

Внутрішні зв’язки → ClusterIP
Зовнішній HTTP/HTTPS → ClusterIP + Ingress (один LB на всі сервіси)
Не-HTTP трафік (БД) → LoadBalancer
Зовнішні ресурси → 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	Інтеграція з 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>     ...

Причини:

Немає Cloud Controller Manager
Ліміт квоти хмари
Неправильні 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 і навіщо він потрібен]] — загальна архітектура