Модуль 1.7: Сервіси

Складність: [СЕРЕДНІЙ] - Основна концепція мережі

Час на виконання: 25-30 хвилин

Передумови: Модулі 1.5, 1.6

Що ви зможете робити

Після завершення цього модуля ви зможете:

Пояснити чому потрібні Service та як вони забезпечують стабільні точки доступу для Pod
Порівняти типи Service: ClusterIP, NodePort, LoadBalancer та ExternalName
Визначити як селектори міток з’єднують Service з відповідними Pod
Простежити як працює DNS-розв’язання для виявлення Service всередині кластера

Чому цей модуль важливий

Поди з’являються та зникають — їх IP постійно змінюються. Services надають стабільні точки доступу до Подів. Розуміння Services критично важливе для KCNA та для розуміння того, як працює мережа Kubernetes.

Проблема, яку вирішують Services

┌─────────────────────────────────────────────────────────────┐
│              ПРОБЛЕМА З IP ПОДІВ                            │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  Без Services:                                             │
│  Час T1:                                                   │
│  Frontend → 10.1.1.5 (под backend)  ✓ Працює               │
│                                                             │
│  Час T2: Под backend падає, новий створюється              │
│  Frontend → 10.1.1.5  ✗ Мертвий                           │
│  Новий под backend має IP: 10.1.1.9                        │
│                                                             │
│  З Services:                                               │
│  Frontend → backend-service (стабільний) → Поди Backend   │
│                                                             │
│  Service забезпечує:                                       │
│  • Стабільну IP та DNS-ім'я                                │
│  • Автоматичне виявлення здорових Подів                    │
│  • Балансування навантаження                               │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Типи Service

1. ClusterIP (За замовчуванням)

Тільки внутрішня IP кластера
Недоступний ззовні кластера
Тип за замовчуванням
Використання: Внутрішні сервіси (бази даних, кеші, API)

2. NodePort

Відкриває Service на IP кожного вузла на статичному порті
Діапазон портів: 30000-32767
Доступний ззовні кластера
Використання: Розробка, тестування, простий зовнішній доступ

3. LoadBalancer

Забезпечує зовнішній балансувальник навантаження (хмарний провайдер)
Отримує зовнішню IP-адресу
Найпоширеніший для продакшн зовнішнього доступу
Використання: Продакшн зовнішній доступ у хмарі

4. ExternalName

Відображає Service на зовнішнє DNS-ім’я
Без проксіювання — повертає CNAME запис
Без селектора (без Подів)
Використання: Доступ до зовнішніх сервісів з внутрішнім ім’ям

Порівняння типів Service

Тип	Внутрішній	Зовнішній	Випадок використання
ClusterIP	✓	✗	Внутрішня комунікація
NodePort	✓	✓ (через IP вузла)	Розробка/тестування
LoadBalancer	✓	✓ (через IP LB)	Продакшн зовнішній
ExternalName	✓	Н/Д	Відображення зовнішнього DNS

Виявлення сервісів

Kubernetes забезпечує два способи виявлення Services:

1. DNS (Рекомендовано)

┌─────────────────────────────────────────────────────────────┐
│              ВИЯВЛЕННЯ НА ОСНОВІ DNS                       │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  Кожен Service отримує DNS-запис:                          │
│                                                             │
│  <service-name>.<namespace>.svc.cluster.local              │
│                                                             │
│  Приклади:                                                 │
│  backend.default.svc.cluster.local                        │
│  database.production.svc.cluster.local                    │
│  redis.cache.svc.cluster.local                            │
│                                                             │
│  Скорочення (в тому ж просторі імен):                     │
│  backend                    (той самий простір імен)       │
│  backend.default            (вказано простір імен)         │
│  backend.default.svc        (додано svc)                  │
│                                                             │
│  Под може просто використовувати: http://backend:80       │
│                                                             │
└─────────────────────────────────────────────────────────────┘

2. Змінні середовища

Kubernetes ін’єктує змінні середовища у Поди. Обмеження: Service повинен існувати ДО створення Пода (DNS не має цього обмеження).

Чи знали ви?

ClusterIP віртуальна - ClusterIP фактично не існує на жодному інтерфейсі. Вона обробляється правилами kube-proxy, які перенаправляють трафік.
LoadBalancer включає NodePort - Коли ви створюєте LoadBalancer Service, ви також автоматично отримуєте ClusterIP та NodePort.
Headless Services - Встановлення clusterIP: None створює headless Service, який повертає IP Подів напряму через DNS (корисно для StatefulSets).
Services обмежені простором імен - Service у просторі імен “dev” може вибирати тільки Поди у просторі імен “dev”.

Типові помилки

Помилка	Чому це шкодить	Правильне розуміння
Використання IP Подів напряму	IP змінюються	Використовуйте Services для стабільного доступу
LoadBalancer скрізь	Дорого, марнотратно	Використовуйте Ingress для HTTP-маршрутизації
Неправильні мітки селектора	Service не знаходить Поди	Мітки повинні точно збігатися
Очікування зовнішньої IP для ClusterIP	Не працює	Використовуйте NodePort або LoadBalancer

Вікторина

Який тип Service за замовчуванням?

Відповідь
ClusterIP. Він забезпечує тільки внутрішній доступ у кластері — без зовнішнього доступу.
Як Service знаходить, до яких Подів маршрутизувати?

Відповідь
Використовуючи селектори міток. Селектор Service збігається з мітками Подів. Kubernetes автоматично створює Endpoints, що містять відповідні IP Подів.
Який формат DNS для Service?

Відповідь
`..svc.cluster.local`. Наприклад, `backend.production.svc.cluster.local`.
Коли використовувати NodePort проти LoadBalancer?

Відповідь
NodePort для розробки/тестування або коли ви керуєте власним балансувальником. LoadBalancer для продакшн зовнішнього доступу у хмарних середовищах (він забезпечує хмарний балансувальник).
Що таке headless Service?

Відповідь
Service з `clusterIP: None`. Замість однієї ClusterIP, DNS повертає IP всіх відповідних Подів. Використовується з StatefulSets для прямого доступу до Подів.

Підсумок

Services забезпечують:

Стабільну IP та DNS-ім’я
Балансування навантаження між Подами
Виявлення сервісів

Типи Service:

Тип	Доступ	Випадок використання
ClusterIP	Тільки внутрішній	Сервіси backend
NodePort	Через IP:порт вузла	Тестування
LoadBalancer	Через хмарний LB	Продакшн зовнішній
ExternalName	DNS-псевдонім	Зовнішні сервіси

Методи виявлення:

DNS: service.namespace.svc.cluster.local (рекомендований)
Змінні середовища (застарілий)

Наступний модуль

Модуль 1.8: Простори імен та мітки - Організація та вибір ресурсів у Kubernetes.