Кумулятивний тест Частини 3: Сервіси та мережа

Lab Progress 0/8 completed

Обмеження часу: 45 хвилин

Прохідний бал: 80% (24/30 питань)

Формат: Множинний вибір та короткі відповіді

Цей тест охоплює всі модулі Частини 3:

Модуль 3.1: Сервіси
Модуль 3.2: Endpoints та EndpointSlices
Модуль 3.3: DNS та CoreDNS
Модуль 3.4: Ingress
Модуль 3.5: Gateway API
Модуль 3.6: Мережеві політики
Модуль 3.7: CNI та мережа кластера

Розділ 1: Сервіси (7 питань)

П1: Типи Сервісів

Який тип Сервісу ви б використали, щоб відкрити застосунок зовні з автоматичним створенням хмарного балансувальника навантаження?

Відповідь

LoadBalancer

Тип Сервісу LoadBalancer створює зовнішній балансувальник навантаження (на підтримуваних хмарних провайдерах), який маршрутизує трафік до NodePort-ів на вузлах кластера.

П2: Конфігурація портів

Сервіс має port: 80 та targetPort: 8080. Що це означає?

Відповідь

Сервіс слухає на порті 80, але пересилає трафік на порт 8080 Подів. Клієнти зʼєднуються із Сервісом на порті 80, а трафік маршрутизується до порту 8080 контейнера.

П3: Створення Сервісів

Напишіть команду для відкриття Deployment з іменем web як Сервісу NodePort на порті 80:

Відповідь

kubectl expose deployment web --port=80 --type=NodePort

П4: Селектори Сервісів

Сервіс показує <none> для ENDPOINTS. Яка найімовірніша причина?

Відповідь

Селектор Сервісу не збігається з мітками жодного працюючого Поду. Перевірте селектор за допомогою kubectl describe svc <name> та переконайтеся, що Поди мають відповідні мітки за допомогою kubectl get pods --show-labels.

П5: Сервіс ExternalName

Який тип DNS-запису створює Сервіс ExternalName?

Відповідь

Запис CNAME

Сервіс ExternalName повертає запис CNAME, який створює аліас імені Сервісу на вказане зовнішнє DNS-імʼя. Проксіювання не відбувається.

П6: Привʼязка сесій

Як налаштувати Сервіс, щоб маршрутизувати запити від одного клієнта до одного й того ж Поду?

Відповідь

Встановіть sessionAffinity: ClientIP у специфікації Сервісу:

spec:
  sessionAffinity: ClientIP
  sessionAffinityConfig:
    clientIP:
      timeoutSeconds: 10800

П7: Діапазон NodePort

Який стандартний діапазон NodePort у Kubernetes?

Відповідь

30000–32767

Цей діапазон можна налаштувати через прапорець --service-node-port-range на API-сервері.

Розділ 2: Endpoints та EndpointSlices (4 питання)

П8: Призначення Endpoints

Який звʼязок між Сервісами та Endpoints?

Відповідь

Endpoints відстежують IP Подів, що стоять за Сервісом. Коли Поди відповідають селектору Сервісу, їхні IP додаються до обʼєкта Endpoints. Контролер endpoint автоматично створює та оновлює Endpoints на основі збігу міток Подів та їхньої готовності.

П9: Ручні Endpoints

Коли ви б створили Сервіс без селектора та з ручними Endpoints?

Відповідь

Коли потрібно вказати на:

Зовнішні бази даних або сервіси за межами кластера
Сервіси в інших кластерах
Будь-який ресурс на основі IP, який не є Подом Kubernetes

Створіть Сервіс без селектора, потім створіть обʼєкт Endpoints з тим самим іменем, що містить зовнішні IP.

П10: EndpointSlices

Чому було введено EndpointSlices?

Відповідь

Для покращення масштабованості. Єдиний обʼєкт Endpoints для Сервісів з тисячами Подів ставав вузьким місцем продуктивності. EndpointSlices розбивають endpoints на фрагменти до 100, тому оновлення впливають лише на один фрагмент замість усього обʼєкта.

П11: Адреси NotReady

В обʼєкті Endpoints, яка різниця між addresses та notReadyAddresses?

Відповідь

addresses: IP Подів, які готові та отримуватимуть трафік
notReadyAddresses: IP Подів, які не проходять проби готовності та не отримуватимуть трафік

Трафік маршрутизується лише до адрес у списку addresses.

Розділ 3: DNS та CoreDNS (5 питань)

П12: Формат DNS-імені

Який FQDN для Сервісу з іменем api у просторі імен production?

Відповідь

api.production.svc.cluster.local

Формат: <service>.<namespace>.svc.<cluster-domain>

П13: Міжпросторове розвʼязання

Поду в просторі імен dev потрібно звʼязатися із Сервісом cache у просторі імен prod. Яке DNS-імʼя слід використовувати?

Відповідь

cache.prod або cache.prod.svc.cluster.local

Скорочене імʼя cache саме по собі не спрацює з іншого простору імен.

П14: Конфігурація CoreDNS

Де зберігається конфігурація CoreDNS?

Відповідь

У ConfigMap з іменем coredns у просторі імен kube-system. Конфігурація знаходиться в ключі Corefile.

kubectl get configmap coredns -n kube-system -o yaml

П15: Налаштування ndots

Що означає ndots:5 у /etc/resolv.conf?

Відповідь

Якщо запит містить менше 5 крапок, спочатку спробувати додати пошукові домени, перш ніж робити запит як абсолютне імʼя. Це оптимізує розвʼязання для імен Kubernetes, таких як web-svc.default.svc.cluster.local (4 крапки) — вони спочатку пробуються з пошуковими доменами.

П16: DNS headless-Сервісу

Як відрізняється поведінка DNS для headless-Сервісу?

Відповідь

Звичайні Сервіси повертають один A-запис (ClusterIP). Headless-Сервіси (з clusterIP: None) повертають кілька A-записів — по одному для кожного IP Поду. Клієнти отримують усі IP Подів і можуть реалізувати власне балансування навантаження або зʼєднуватися з конкретними Подами.

Розділ 4: Ingress (4 питання)

П17: Ingress проти LoadBalancer

Яка головна перевага Ingress перед Сервісами LoadBalancer?

Відповідь

Ingress забезпечує маршрутизацію на рівні 7 (HTTP/HTTPS) з:

Маршрутизацією на основі шляху (кілька Сервісів за одним IP)
Віртуальними хостами (маршрутизація на основі хоста)
Термінацією TLS
Перезаписом URL

LoadBalancer працює на рівні 4 і вимагає одного хмарного балансувальника на Сервіс. Ingress обʼєднує кілька Сервісів за одним зовнішнім IP.

П18: Адреса Ingress

Ingress не показує ADDRESS. Яка ймовірна причина?

Відповідь

Не встановлено контролер Ingress, або ingressClassName не відповідає жодному встановленому контролеру.

Виправлення: Встановіть контролер Ingress та/або перевірте конфігурацію IngressClass.

П19: Типи шляхів

Яка різниця між pathType: Prefix та pathType: Exact?

Відповідь

Prefix: Збігається з будь-яким шляхом, що починається зі значення. /api збігається з /api, /api/users, /api/v1/...
Exact: Збігається лише з точним шляхом. /api збігається лише з /api, не з /api/ або /api/users

П20: Конфігурація TLS

Які дві речі потрібні для налаштування HTTPS на Ingress?

Відповідь

TLS Secret, що містить сертифікат та ключ
Секція tls у специфікації Ingress, що посилається на Secret та вказує, до яких хостів він застосовується

spec:
  tls:
  - hosts:
    - example.com
    secretName: example-tls

Розділ 5: Gateway API (4 питання)

П21: Ресурси Gateway API

Які три основних ресурси Gateway API та хто зазвичай створює кожен?

Відповідь

GatewayClass — Створюється провайдером інфраструктури (визначає контролер)
Gateway — Створюється оператором кластера (налаштовує слухачі, адреси)
HTTPRoute — Створюється розробником застосунку (визначає правила маршрутизації)

Цей рольовий розподіл є ключовим покращенням порівняно з Ingress.

П22: Розподіл трафіку

Як налаштувати розподіл трафіку 90/10 у Gateway API?

Відповідь

Використовуйте weight у backendRefs:

rules:
- backendRefs:
  - name: stable
    port: 80
    weight: 90
  - name: canary
    port: 80
    weight: 10

П23: Gateway API проти Ingress

Назвіть дві можливості, які має Gateway API, але яких Ingress не має нативно:

Відповідь

Будь-які дві з:

Маршрутизація на основі заголовків (нативна підтримка, без анотацій)
Розподіл трафіку/ваги (нативна підтримка)
Підтримка кількох протоколів (TCP, UDP, TLS, gRPC, не лише HTTP)
Рольоорієнтований дизайн (окремі ресурси за ролями)
Міжпросторова маршрутизація з ReferenceGrant
Модифікація заголовків запиту/відповіді (нативна)

П24: ReferenceGrant

Для чого використовується ReferenceGrant?

Відповідь

ReferenceGrant дозволяє ресурсам в одному просторі імен посилатися на ресурси в іншому просторі імен. Наприклад, дозволяє HTTPRoute у просторі імен frontend маршрутизувати трафік до Сервісу в просторі імен backend.

Без ReferenceGrant міжпросторові посилання заборонені за замовчуванням.

Розділ 6: Мережеві політики (4 питання)

П25: Поведінка за замовчуванням

Яка стандартна мережева поведінка Подів без жодної NetworkPolicy?

Відповідь

Весь трафік дозволений. Поди можуть спілкуватися з будь-яким іншим Подом у кластері без обмежень. Kubernetes має пласку мережеву модель без ізоляції за замовчуванням.

П26: Заборона всього Ingress

Напишіть NetworkPolicy, що забороняє весь вхідний трафік до Подів у поточному просторі імен:

Відповідь

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all-ingress
spec:
  podSelector: {}          # Обирає всі Поди
  policyTypes:
  - Ingress                # Без правил ingress = заборонити все

П27: Логіка селекторів

Яка різниця між цими двома правилами ingress?

# Версія A
ingress:
- from:
  - podSelector: {matchLabels: {app: a}}
  - namespaceSelector: {matchLabels: {name: x}}

# Версія B
ingress:
- from:
  - podSelector: {matchLabels: {app: a}}
    namespaceSelector: {matchLabels: {name: x}}

Відповідь

Версія A: Логіка OR Дозволяє трафік від Подів з app=a АБО від будь-якого Поду в просторі імен з name=x.

Версія B: Логіка AND Дозволяє трафік лише від Подів з app=a, які також знаходяться в просторі імен з name=x.

Різниця в тому, чи селектори знаходяться в одному елементі масиву from (AND) або в окремих елементах (OR).

П28: DNS та Egress

Чому важливо дозволити DNS egress при обмеженні вихідного трафіку?

Відповідь

Подам потрібен DNS (порт 53) для розвʼязання імен Сервісів. Без DNS egress Поди не можуть знайти my-service.default.svc.cluster.local, що порушує виявлення сервісів.

Завжди включайте DNS у політики egress:

egress:
- to:
  - namespaceSelector: {}
  ports:
  - port: 53
    protocol: UDP
  - port: 53
    protocol: TCP

Розділ 7: CNI та мережа кластера (2 питання)

П29: CNI та NetworkPolicy

Який поширений плагін CNI НЕ підтримує NetworkPolicy?

Відповідь

Flannel

Flannel — це проста оверлейна мережа, зосереджена лише на зʼєднанні. Він не реалізує застосування NetworkPolicy. Використовуйте Calico, Cilium або Weave для підтримки NetworkPolicy.

П30: Режими kube-proxy

Які два основних режими kube-proxy та який краще для великих кластерів?

Відповідь

Режим iptables: Використовує правила iptables для маршрутизації Сервісів. Підходить для більшості кластерів.

Режим IPVS: Використовує IPVS ядра (IP Virtual Server) для маршрутизації. Краще для великих кластерів, тому що:

Час пошуку O(1) проти O(n) для iptables
Підтримує більше алгоритмів балансування навантаження
Краща продуктивність з великою кількістю Сервісів/endpoints

Оцінювання

Підрахуйте правильні відповіді:

Бал	Результат
27–30	Відмінно! Готові до Частини 4
24–26	Добре. Повторіть пропущені теми, потім продовжуйте
20–23	Повторіть відповідні модулі перед продовженням
<20	Перечитайте модулі Частини 3

Ресурси для повторення

Якщо ви набрали менше 80%, повторіть ці модулі:

Питання про Сервіси (П1–П7): Модуль 3.1
Питання про Endpoints (П8–П11): Модуль 3.2
Питання про DNS (П12–П16): Модуль 3.3
Питання про Ingress (П17–П20): Модуль 3.4
Питання про Gateway API (П21–П24): Модуль 3.5
Питання про мережеві політики (П25–П28): Модуль 3.6
Питання про CNI (П29–П30): Модуль 3.7

Наступна частина

Переходьте до Частини 4: Зберігання, щоб вивчити PersistentVolumes, StorageClasses та управління даними в Kubernetes.