Модуль 3.7: CNI та мережа кластера

Складність: [MEDIUM] — Розуміння мережевої інфраструктури

Час на виконання: 40–50 хвилин

Передумови: Модуль 1.2 (Інтерфейси розширення), Модуль 3.1 (Сервіси)

---

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

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

• Пояснити, як CNI-плагіни призначають IP-адреси та налаштовують маршрути для подів
• Порівняти Calico, Cilium та Flannel за функціоналом, продуктивністю та підтримкою NetworkPolicy
• Діагностувати збої CNI, перевіряючи мережу подів, конфігураційні файли CNI та логи плагінів
• Простежити трафік pod-to-pod через overlay або native routing шлях CNI

---

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

Container Network Interface (CNI) — це система плагінів, яка забезпечує мережеве зʼєднання Подів. Без CNI Поди не можуть спілкуватися. Розуміння CNI допомагає діагностувати мережеві проблеми, обирати правильний мережевий плагін і розуміти, чому Поди можуть (або не можуть) спілкуватися один з одним.

Іспит CKA очікує, що ви розумієте основи мережі Подів, вмієте діагностувати мережеві проблеми та знаєте, як різні плагіни CNI впливають на поведінку кластера (особливо підтримка мережевих політик).

Аналогія з міською інфраструктурою

Уявіть CNI як управління міського планування. Воно вирішує, як прокладаються вулиці (мережі), як призначаються адреси (IP) будівлям (Подам) та які райони (вузли) зʼєднуються між собою. Різні плагіни CNI — це як різні проєкти міст: деякі мають автомагістралі (висока продуктивність), деякі — контрольно-пропускні пункти (мережеві політики).

---

Що ви вивчите

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

• Розуміти мережеву модель Kubernetes
• Знати, як працюють плагіни CNI
• Порівнювати популярні варіанти CNI
• Діагностувати проблеми мережі Подів
• Розуміти, як kube-proxy керує трафіком сервісів

---

Чи знали ви?

• Вбудованої мережі немає: Kubernetes не постачається з мережею. Ви повинні встановити плагін CNI, щоб Поди могли спілкуватися.

• Flannel = без NetworkPolicy: Популярний CNI Flannel не підтримує мережеві політики. Якщо вам потрібні політики, використовуйте Calico, Cilium або Weave.

• Pod CIDR — на кожен вузол: Кожен вузол зазвичай отримує свій діапазон IP (наприклад, 10.244.1.0/24), і Поди на цьому вузлі отримують IP з цього діапазону.

---

Частина 1: Мережева модель Kubernetes

1.1 Чотири вимоги

Мережа Kubernetes має чотири фундаментальні вимоги:

┌────────────────────────────────────────────────────────────────┐
│                Вимоги до мережі Kubernetes                       │
│                                                                 │
│   1. Під-до-Поду: Усі Поди можуть спілкуватися з усіма Подами │
│      без NAT                                                    │
│      ┌─────┐      ┌─────┐                                      │
│      │Під A│◄────►│Під B│  (прямий IP, без NAT)               │
│      └─────┘      └─────┘                                      │
│                                                                 │
│   2. Вузол-до-Поду: Вузли можуть спілкуватися з усіма Подами  │
│      без NAT                                                    │
│      ┌─────┐      ┌─────┐                                      │
│      │Вузол│◄────►│ Під │  (прямий доступ)                    │
│      └─────┘      └─────┘                                      │
│                                                                 │
│   3. IP Поду = Видимий IP: IP, який Під бачить — той самий,    │
│      що бачать інші                                             │
│      Під думає: "Мій IP — 10.244.1.5"                          │
│      Інші бачать: "IP Поду — 10.244.1.5"                       │
│                                                                 │
│   4. Під-до-Сервісу: Поди можуть звертатися до Сервісів       │
│      за ClusterIP                                               │
│      ┌─────┐      ┌───────────┐      ┌─────┐                  │
│      │ Під │─────►│  Сервіс  │─────►│ Під │                  │
│      └─────┘      └───────────┘      └─────┘                  │
│                                                                 │
└────────────────────────────────────────────────────────────────┘

1.2 Що забезпечує CNI

Відповідальність	Компонент
Виділення IP для Подів	Плагін CNI (IPAM)
Маршрутизація Під-до-Поду	Плагін CNI
Міжвузлова мережа	Плагін CNI
Застосування мережевих політик	Плагін CNI (якщо підтримується)
Маршрутизація ClusterIP Сервісів	kube-proxy

1.3 Мережеві простори імен

┌────────────────────────────────────────────────────────────────┐
│                   Мережеві простори імен                         │
│                                                                 │
│   Вузол                                                         │
│   ┌────────────────────────────────────────────────────────┐   │
│   │  Мережевий простір імен хоста                           │   │
│   │  eth0: 192.168.1.10                                    │   │
│   │                                                         │   │
│   │     ┌─────────────────┐     ┌─────────────────┐        │   │
│   │     │ Під A           │     │ Під B           │        │   │
│   │     │ Мережевий ПІ    │     │ Мережевий ПІ    │        │   │
│   │     │                 │     │                 │        │   │
│   │     │ eth0:10.244.1.5 │     │ eth0:10.244.1.6 │        │   │
│   │     │                 │     │                 │        │   │
│   │     └────────┬────────┘     └────────┬────────┘        │   │
│   │              │                       │                  │   │
│   │              └───────────┬───────────┘                  │   │
│   │                          │                              │   │
│   │                    ┌─────┴─────┐                        │   │
│   │                    │   Міст   │                        │   │
│   │                    │  (cni0)   │                        │   │
│   │                    └─────┬─────┘                        │   │
│   │                          │                              │   │
│   └──────────────────────────┼──────────────────────────────┘   │
│                              │                                   │
│                         До інших вузлів                          │
│                                                                 │
└────────────────────────────────────────────────────────────────┘

---

Частина 2: Плагіни CNI

2.1 Популярні плагіни CNI

Плагін	Мережеві політики	Продуктивність	Сценарій використання
Calico	Так	Висока	Підприємства, фокус на безпеці
Cilium	Так (розширені)	Дуже висока	eBPF, спостережуваність
Flannel	Ні	Середня	Прості кластери
Weave	Так	Середня	Мультихмарність
Canal	Так	Середня	Політики Calico + мережа Flannel
AWS VPC CNI	Через Calico	Висока	Нативний для EKS

2.2 Як працює CNI

┌────────────────────────────────────────────────────────────────┐
│                   Потік роботи плагіна CNI                       │
│                                                                 │
│   1. Під створено                                               │
│      │                                                          │
│      ▼                                                          │
│   2. Kubelet викликає плагін CNI (ADD)                          │
│      │                                                          │
│      ▼                                                          │
│   3. CNI створює мережевий простір імен                         │
│      │                                                          │
│      ▼                                                          │
│   4. CNI призначає IP-адресу (IPAM)                            │
│      │                                                          │
│      ▼                                                          │
│   5. CNI налаштовує пару veth                                   │
│      │                                                          │
│      ▼                                                          │
│   6. CNI налаштовує маршрутизацію                               │
│      │                                                          │
│      ▼                                                          │
│   7. Під готовий до роботи в мережі                             │
│                                                                 │
│   Під видалено:                                                  │
│      Плагін CNI викликається з DEL → Очищення                   │
│                                                                 │
└────────────────────────────────────────────────────────────────┘

2.3 Розташування конфігурації CNI

# Розташування бінарних файлів CNI
ls /opt/cni/bin/

# Розташування конфігурації CNI
ls /etc/cni/net.d/

# Приклад: Перегляд конфігурації CNI
cat /etc/cni/net.d/10-calico.conflist

2.4 Перевірка стану CNI

# Перевірити, який CNI встановлено
ls /etc/cni/net.d/

# Перевірити Поди CNI
k get pods -n kube-system | grep -E "calico|flannel|weave|cilium"

# Перевірити DaemonSet CNI
k get daemonset -n kube-system

# Переглянути конфігурацію CNI
cat /etc/cni/net.d/*.conf* 2>/dev/null

---

Частина 3: Детальний розгляд мережі Подів

3.1 Виділення IP для Подів

┌────────────────────────────────────────────────────────────────┐
│                   Виділення IP                                   │
│                                                                 │
│   CIDR кластера: 10.244.0.0/16                                 │
│                                                                 │
│   Вузол 1: 10.244.0.0/24        Вузол 2: 10.244.1.0/24        │
│   ┌──────────────────────┐     ┌──────────────────────┐        │
│   │ Під: 10.244.0.5      │     │ Під: 10.244.1.3      │        │
│   │ Під: 10.244.0.6      │     │ Під: 10.244.1.4      │        │
│   │ Під: 10.244.0.7      │     │ Під: 10.244.1.5      │        │
│   └──────────────────────┘     └──────────────────────┘        │
│                                                                 │
│   Вузол 3: 10.244.2.0/24                                       │
│   ┌──────────────────────┐                                     │
│   │ Під: 10.244.2.2      │                                     │
│   │ Під: 10.244.2.3      │                                     │
│   └──────────────────────┘                                     │
│                                                                 │
└────────────────────────────────────────────────────────────────┘

3.2 Перегляд мережевої конфігурації Поду

# Отримати IP Поду
k get pod <pod> -o wide
k get pod <pod> -o jsonpath='{.status.podIP}'

# Отримати IP усіх Подів
k get pods -o custom-columns='NAME:.metadata.name,IP:.status.podIP'

# Перевірити, на якому вузлі Під
k get pod <pod> -o jsonpath='{.spec.nodeName}'

# Переглянути мережевий простір імен Поду (з вузла)
# Спочатку отримати ID контейнера
crictl ps | grep <pod-name>
# Потім перевірити мережу
crictl inspect <container-id> | jq '.info.runtimeSpec.linux.namespaces'

3.3 Звʼязок Під-до-Поду (той самий вузол)

┌────────────────────────────────────────────────────────────────┐
│                   Звʼязок на тому ж вузлі                       │
│                                                                 │
│   Вузол                                                         │
│   ┌────────────────────────────────────────────────────────┐   │
│   │                                                         │   │
│   │   Під A                     Під B                      │   │
│   │   10.244.1.5                10.244.1.6                 │   │
│   │   ┌─────────┐               ┌─────────┐                │   │
│   │   │  eth0   │               │  eth0   │                │   │
│   │   └────┬────┘               └────┬────┘                │   │
│   │        │ пара veth               │ пара veth           │   │
│   │        │                         │                      │   │
│   │   ┌────┴────┐               ┌────┴────┐                │   │
│   │   │ veth-a  │               │ veth-b  │                │   │
│   │   └────┬────┘               └────┬────┘                │   │
│   │        │                         │                      │   │
│   │        └───────────┬─────────────┘                      │   │
│   │                    │                                    │   │
│   │              ┌─────┴─────┐                              │   │
│   │              │   Міст   │ (cni0 або cbr0)              │   │
│   │              │10.244.1.1 │                              │   │
│   │              └───────────┘                              │   │
│   │                                                         │   │
│   └────────────────────────────────────────────────────────┘   │
│                                                                 │
│   Трафік: Під A → veth-a → міст → veth-b → Під B              │
│                                                                 │
└────────────────────────────────────────────────────────────────┘

3.4 Звʼязок Під-до-Поду (різні вузли)

┌────────────────────────────────────────────────────────────────┐
│                 Міжвузловий звʼязок                               │
│                                                                 │
│   Вузол 1 (192.168.1.10)          Вузол 2 (192.168.1.11)      │
│   ┌───────────────────────┐      ┌───────────────────────┐    │
│   │                       │      │                       │    │
│   │  Під A: 10.244.1.5    │      │  Під B: 10.244.2.6    │    │
│   │  ┌─────────┐          │      │          ┌─────────┐  │    │
│   │  │  veth   │          │      │          │  veth   │  │    │
│   │  └────┬────┘          │      │          └────┬────┘  │    │
│   │       │               │      │               │       │    │
│   │  ┌────┴────┐          │      │          ┌────┴────┐  │    │
│   │  │  Міст  │          │      │          │  Міст  │  │    │
│   │  └────┬────┘          │      │          └────┬────┘  │    │
│   │       │               │      │               │       │    │
│   │  ┌────┴────┐          │      │          ┌────┴────┐  │    │
│   │  │  eth0   │          │      │          │  eth0   │  │    │
│   │  └────┬────┘          │      │          └────┬────┘  │    │
│   │       │               │      │               │       │    │
│   └───────┼───────────────┘      └───────────────┼───────┘    │
│           │                                      │             │
│           └──────────────────────────────────────┘             │
│                   Оверлей або маршрутизація                     │
│                (VXLAN, IPIP, BGP тощо)                        │
│                                                                 │
└────────────────────────────────────────────────────────────────┘

---

Частина 4: kube-proxy та Сервіси

4.1 Режими kube-proxy

Режим	Опис	Продуктивність	Сценарій використання
iptables	Використовує правила iptables	Добра	За замовчуванням, більшість кластерів
IPVS	Використовує IPVS ядра	Краща	Велика кількість Подів, розширене балансування
userspace	Застарілий, проксі в просторі користувача	Погана	Ніколи не використовуйте (deprecated)

4.2 Як працює kube-proxy

┌────────────────────────────────────────────────────────────────┐
│                   Потік kube-proxy                               │
│                                                                 │
│   Під-клієнт                                                    │
│       │                                                         │
│       │ Запит до IP Сервісу 10.96.45.123:80                    │
│       ▼                                                         │
│   ┌───────────────────────────────────────────────────────┐    │
│   │                  iptables / IPVS                       │    │
│   │                                                        │    │
│   │  Ланцюжок PREROUTING:                                 │    │
│   │  10.96.45.123:80 → DNAT до IP Поду (випадковий вибір)│    │
│   │                                                        │    │
│   │  Обрано: 10.244.1.5:8080                              │    │
│   └───────────────────────────────────────────────────────┘    │
│       │                                                         │
│       ▼                                                         │
│   Під-бекенд (10.244.1.5:8080)                                 │
│                                                                 │
│   kube-proxy спостерігає за API-сервером щодо змін             │
│   Service/Endpoint та оновлює правила iptables/IPVS відповідно │
│                                                                 │
└────────────────────────────────────────────────────────────────┘

4.3 Перевірка kube-proxy

# Перевірити Поди kube-proxy
k get pods -n kube-system -l k8s-app=kube-proxy

# Перевірити режим kube-proxy
k logs -n kube-system -l k8s-app=kube-proxy | grep "Using"

# Переглянути ConfigMap kube-proxy
k get configmap kube-proxy -n kube-system -o yaml

# Перевірити правила iptables (на вузлі)
iptables -t nat -L KUBE-SERVICES -n | head -20

# Перевірити правила IPVS (якщо використовується режим IPVS, на вузлі)
ipvsadm -Ln

---

Частина 5: Діагностика мережевих проблем

5.1 Послідовність діагностики мережі

Проблема з мережею Поду?
    │
    ├── kubectl get pod -o wide (перевірити IP Поду, вузол)
    │
    ├── Під має IP?
    │   ├── Ні → Проблема з CNI
    │   │        Перевірте: Поди CNI, /etc/cni/net.d/, логи CNI
    │   │
    │   └── Так → Продовжуйте
    │
    ├── Можна звʼязатися з іншими Подами на тому ж вузлі?
    │   ├── Ні → Проблема з мостом/veth
    │   │
    │   └── Так → Продовжуйте
    │
    ├── Можна звʼязатися з Подами на інших вузлах?
    │   ├── Ні → Проблема з оверлеєм/маршрутизацією
    │   │        Перевірте: конфігурацію CNI, маршрути вузла, файрвол
    │   │
    │   └── Так → Продовжуйте
    │
    ├── Можна звʼязатися із Сервісами?
    │   ├── Ні → Проблема з kube-proxy або DNS
    │   │        Перевірте: kube-proxy, CoreDNS, iptables
    │   │
    │   └── Так → Мережа в порядку, перевірте застосунок
    │
    └── Перевірте NetworkPolicy
        kubectl get networkpolicy

5.2 Корисні команди діагностики

# Перевірити мережу Поду
k exec <pod> -- ip addr
k exec <pod> -- ip route
k exec <pod> -- cat /etc/resolv.conf

# Перевірити зʼєднання
k exec <pod> -- ping <other-pod-ip>
k exec <pod> -- nc -zv <service> <port>
k exec <pod> -- wget --spider --timeout=1 http://<service>

# Перевірити Поди CNI
k get pods -n kube-system | grep -E "calico|flannel|weave|cilium"
k logs -n kube-system <cni-pod>

# Перевірити kube-proxy
k get pods -n kube-system -l k8s-app=kube-proxy
k logs -n kube-system -l k8s-app=kube-proxy

# Перевірити CoreDNS
k get pods -n kube-system -l k8s-app=kube-dns
k logs -n kube-system -l k8s-app=kube-dns

5.3 Типові мережеві проблеми

Симптом	Причина	Рішення
Під застряг у ContainerCreating	CNI не встановлено або збоїть	Встановіть/виправте плагін CNI
Під не має IP	IPAM вичерпано або помилка CNI	Перевірте логи CNI, розширте CIDR
Не вдається звʼязатися з Подами на інших вузлах	Оверлей неправильно налаштовано	Перевірте конфігурацію мережі CNI
Сервіси недоступні	kube-proxy не працює	Перевірте Поди kube-proxy
DNS не працює	CoreDNS не працює	Перевірте Поди CoreDNS
NetworkPolicy не працює	CNI не підтримує	Використовуйте Calico, Cilium або Weave

---

Частина 6: Конфігурація CIDR кластера

6.1 Розуміння CIDR

Тип CIDR	Опис	Приклад
Pod CIDR	Діапазон IP для всіх Подів	10.244.0.0/16
Service CIDR	Діапазон IP для Сервісів	10.96.0.0/12
Node CIDR	Діапазон Подів на вузол	10.244.1.0/24

6.2 Перевірка конфігурації CIDR

# Перевірити Pod CIDR (з kube-controller-manager)
k get cm kubeadm-config -n kube-system -o yaml | grep -i cidr

# Перевірити з вузлів
k get nodes -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.podCIDR}{"\n"}{end}'

# Перевірити Service CIDR
k cluster-info dump | grep -m 1 service-cluster-ip-range

6.3 Конфігурація CIDR у kubeadm

# Під час ініціалізації кластера
kubeadm init --pod-network-cidr=10.244.0.0/16 --service-cidr=10.96.0.0/12

# Плагін CNI повинен відповідати цьому CIDR
# Приклад: Встановлення Calico з відповідним CIDR

---

Частина 7: Мережа хоста та порти вузла

7.1 Поди з hostNetwork

# Під, що використовує мережу хоста
apiVersion: v1
kind: Pod
metadata:
  name: host-network-pod
spec:
  hostNetwork: true         # Використовує мережевий простір імен вузла
  containers:
  - name: nginx
    image: nginx
    ports:
    - containerPort: 80     # Привʼязується до порту 80 вузла!

Коли використовувати:

• Мережеві інструменти, що потребують прямий доступ
• Деякі компоненти CNI
• Високопродуктивна мережа

7.2 hostPort

# Під з відображенням порту хоста
apiVersion: v1
kind: Pod
metadata:
  name: hostport-pod
spec:
  containers:
  - name: nginx
    image: nginx
    ports:
    - containerPort: 8080
      hostPort: 80           # Порт 80 вузла → контейнер 8080

Відмінності:

• hostNetwork: true — Під використовує весь мережевий стек вузла
• hostPort — Відображає лише конкретний порт, Під все ще має свій IP

---

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

Помилка	Проблема	Рішення
CNI не встановлено	Поди не можуть отримати IP	Встановіть CNI перед розгортанням Подів
Невідповідність CIDR	CNI та kubeadm не узгоджені	Переконайтеся, що pod-network-cidr відповідає конфігурації CNI
Flannel + NetworkPolicy	Політики ігноруються	Використовуйте Calico, Cilium або Weave
hostNetwork без dnsPolicy	DNS не працює	Встановіть dnsPolicy: ClusterFirstWithHostNet
Вичерпання портів	Неможливо розмістити Поди	Перевірте розмір CIDR, очистіть Поди

---

Тест

1. За що відповідає CNI?

   Відповідь

   CNI відповідає за виділення IP для Подів (IPAM), налаштування мережевих просторів імен, маршрутизацію Під-до-Поду та опціонально застосування мережевих політик. kube-proxy обробляє маршрутизацію Сервісів окремо.

2. Чому Flannel не підтримує мережеві політики?

   Відповідь

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

3. Як kube-proxy маршрутизує трафік до Сервісів?

   Відповідь

   kube-proxy спостерігає за API-сервером щодо змін Service та Endpoint, потім програмує правила iptables (або IPVS) на кожному вузлі. Коли трафік потрапляє на IP Сервісу, ці правила виконують DNAT (перенаправлення) на IP Поду-бекенду.

4. Яка різниця між режимами iptables та IPVS?

   Відповідь

   Режим iptables використовує правила ланцюжків (пошук O(n)), добре працює для невеликих кластерів. IPVS використовує балансування навантаження на рівні ядра (пошук O(1)), краще для великих кластерів з багатьма Сервісами/Подами та підтримує більше алгоритмів балансування навантаження.

5. Під застряг у ContainerCreating. Яка мережева проблема може це спричинити?

   Відповідь

   Плагін CNI може бути не встановлено, неправильно налаштовано або він збоїть. Перевірте Поди CNI в kube-system, конфігурацію CNI в /etc/cni/net.d/ та логи CNI.

---

Практична вправа

Завдання: Дослідити конфігурацію мережі кластера.

Кроки:

1. Перевірте встановлений плагін CNI:

# Перевірити Поди CNI
k get pods -n kube-system | grep -E "calico|flannel|weave|cilium|cni"

# Перевірити конфігурацію CNI
ls /etc/cni/net.d/ 2>/dev/null || echo "Run on node"

2. Перевірте CIDR Подів:

# Отримати CIDR вузлів
k get nodes -o jsonpath='{range .items[*]}{.metadata.name}{": "}{.spec.podCIDR}{"\n"}{end}'

3. Створіть тестові Поди:

k run pod1 --image=busybox:1.36 --command -- sleep 3600
k run pod2 --image=busybox:1.36 --command -- sleep 3600

# Зачекайте на готовність
k wait --for=condition=ready pod/pod1 pod/pod2 --timeout=60s

4. Перевірте мережеву конфігурацію Подів:

# Отримати IP Подів
k get pods -o wide

# Перевірити мережевий інтерфейс Поду
k exec pod1 -- ip addr
k exec pod1 -- ip route

# Перевірити конфігурацію DNS
k exec pod1 -- cat /etc/resolv.conf

5. Перевірте зʼєднання Під-до-Поду:

POD2_IP=$(k get pod pod2 -o jsonpath='{.status.podIP}')
k exec pod1 -- ping -c 3 $POD2_IP

6. Перевірте kube-proxy:

# Перевірити Поди kube-proxy
k get pods -n kube-system -l k8s-app=kube-proxy

# Перевірити режим у логах kube-proxy
k logs -n kube-system -l k8s-app=kube-proxy --tail=5 | grep -i mode

7. Перевірте зʼєднання через Сервіс:

# Створити Сервіс
k create deployment web --image=nginx
k expose deployment web --port=80

# Перевірити DNS та зʼєднання
k exec pod1 -- wget --spider --timeout=2 http://web

8. Очищення:

k delete pod pod1 pod2
k delete deployment web
k delete svc web

Критерії успіху:

• Вміння визначити використовуваний плагін CNI
• Розуміння виділення CIDR для Подів
• Вміння перевірити зʼєднання Під-до-Поду
• Знання як перевірити kube-proxy
• Розуміння діагностики мережі

---

Практичні вправи

Вправа 1: Визначити CNI (Ціль: 2 хвилини)

# Перевірити Поди CNI в kube-system
k get pods -n kube-system | grep -E "calico|flannel|weave|cilium|canal"

# Перевірити DaemonSet-и CNI
k get ds -n kube-system

# Перевірити анотації вузла для CNI
k get nodes -o jsonpath='{.items[0].metadata.annotations}' | jq 'keys'

Вправа 2: Перевірити Pod CIDR (Ціль: 2 хвилини)

# Отримати Pod CIDR з вузлів
k get nodes -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.podCIDR}{"\n"}{end}'

# Перевірити з конфігурації kubeadm (якщо доступно)
k get cm kubeadm-config -n kube-system -o yaml 2>/dev/null | grep -i cidr

# Перевірити з controller-manager
k get pods -n kube-system -l component=kube-controller-manager -o yaml | grep cluster-cidr

Вправа 3: Мережева інформація Поду (Ціль: 3 хвилини)

# Створити тестовий Під
k run net-test --image=busybox:1.36 --command -- sleep 3600
k wait --for=condition=ready pod/net-test --timeout=60s

# Перевірити мережеву інформацію
k exec net-test -- ip addr
k exec net-test -- ip route
k exec net-test -- cat /etc/resolv.conf

# Очищення
k delete pod net-test

Вправа 4: Режим kube-proxy (Ціль: 2 хвилини)

# Перевірити ConfigMap kube-proxy
k get configmap kube-proxy -n kube-system -o yaml | grep -A5 "mode:"

# Перевірити з логів
k logs -n kube-system -l k8s-app=kube-proxy --tail=20 | grep -i "using"

# Список Подів kube-proxy
k get pods -n kube-system -l k8s-app=kube-proxy -o wide

Вправа 5: Перевірити зʼєднання Подів (Ціль: 4 хвилини)

# Створити Поди
k run client --image=busybox:1.36 --command -- sleep 3600
k run server --image=nginx
k wait --for=condition=ready pod/client pod/server --timeout=60s

# Отримати IP сервера
SERVER_IP=$(k get pod server -o jsonpath='{.status.podIP}')

# Перевірити зʼєднання
k exec client -- ping -c 2 $SERVER_IP
k exec client -- wget --spider --timeout=2 http://$SERVER_IP

# Очищення
k delete pod client server

Вправа 6: Перевірка маршрутизації Сервісу (Ціль: 3 хвилини)

# Створити Deployment та Сервіс
k create deployment svc-test --image=nginx
k expose deployment svc-test --port=80
k wait --for=condition=available deployment/svc-test --timeout=60s

# Отримати ClusterIP
CLUSTER_IP=$(k get svc svc-test -o jsonpath='{.spec.clusterIP}')

# Перевірити Сервіс
k run test --rm -it --image=busybox:1.36 --restart=Never -- \
  wget --spider --timeout=2 http://$CLUSTER_IP

# Очищення
k delete deployment svc-test
k delete svc svc-test

Вправа 7: Під з hostNetwork (Ціль: 3 хвилини)

# Створити Під з hostNetwork
cat << 'EOF' | k apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: host-net
spec:
  hostNetwork: true
  dnsPolicy: ClusterFirstWithHostNet
  containers:
  - name: test
    image: busybox:1.36
    command: ["sleep", "3600"]
EOF

k wait --for=condition=ready pod/host-net --timeout=60s

# Перевірити — IP має збігатися з IP вузла
k get pod host-net -o wide

# Порівняти з вузлом
k exec host-net -- ip addr

# Перевірити, що все ще можна розвʼязувати Сервіси
k exec host-net -- nslookup kubernetes

# Очищення
k delete pod host-net

Вправа 8: Виклик — Діагностика мережі

Без підглядання у рішення:

1. Створіть два Поди: client та server (nginx)
2. Отримайте IP обох Подів
3. Перевірте ping від client до server
4. Створіть Сервіс для server
5. Перевірте розвʼязання DNS Сервісу від client
6. Перевірте HTTP-зʼєднання до Сервісу від client
7. Перевірте, який CNI працює
8. Очистіть все

# ВАШЕ ЗАВДАННЯ: Виконайте менше ніж за 5 хвилин

Рішення

# 1. Створити Поди
k run client --image=busybox:1.36 --command -- sleep 3600
k run server --image=nginx
k wait --for=condition=ready pod/client pod/server --timeout=60s

# 2. Отримати IP
k get pods -o wide

# 3. Перевірити ping
SERVER_IP=$(k get pod server -o jsonpath='{.status.podIP}')
k exec client -- ping -c 2 $SERVER_IP

# 4. Створити Сервіс
k expose pod server --port=80 --name=server-svc

# 5. Перевірити DNS
k exec client -- nslookup server-svc

# 6. Перевірити HTTP
k exec client -- wget --spider --timeout=2 http://server-svc

# 7. Перевірити CNI
k get pods -n kube-system | grep -E "calico|flannel|weave|cilium"

# 8. Очищення
k delete pod client server
k delete svc server-svc

---

Наступні кроки

Вітаємо із завершенням Частини 3! Тепер ви розумієте:

• Сервіси та як відкривати доступ до застосунків
• Endpoints та як Сервіси відстежують Поди
• DNS та виявлення сервісів
• Ingress для HTTP-маршрутизації
• Gateway API для маршрутизації нового покоління
• Мережеві політики для безпеки
• CNI та мережу кластера

Пройдіть Кумулятивний тест Частини 3, щоб перевірити свої знання.