Java Interview Questions

Головна / Усі відповіді / Docker Kubernetes

Питання 11 · Розділ 14

Що таке Service в Kubernetes?

Service -- це не контейнер і не процес. Це абстрактний мережевий маршрут, який K8s підтримує автоматично. Pod'и вмирають і перестворюються з новими IP, а Service залишається.

Ukrainian 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» (для маленьких кластерів iptables простіший і достатній)
  • «Session Affinity — хороша практика» (порушує stateless принципи)

Пов’язані теми:

  • [[Які типи Service існують (ClusterIP, NodePort, LoadBalancer)]] — типи Service
  • [[Що таке Pod в Kubernetes]] — що стоїть за Service
  • [[Що таке Ingress в Kubernetes]] — L7 маршрутизація