Модуль 6.5: Спостережуваність GKE та Fleet Management

Складність: [COMPLEX] | Час на виконання: 3 год | Передумови: Модуль 6.1 (Архітектура GKE)

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

У листопаді 2023 року компанія з надання послуг таксі, що мала 12 кластерів GKE у 4 регіонах, виявила критичну вразливість у своєму платіжному сервісі. Патч був випущений, але виявилося, що лише 3 кластери з 12 оновилися. Решта 9 кластерів “дрейфували”: десь була стара версія образу, десь — змінені вручну налаштування. Команді безпеки знадобилося 11 днів, щоб просто зрозуміти, де яка версія працює, і ще тиждень, щоб синхронізувати всі кластери. Протягом цього часу компанія ризикувала даними клієнтів і отримала штраф за порушення комплаєнсу.

Це реальність мультикластерного Kubernetes: без централізованого управління кожен новий кластер не просто додає потужності, він множить ваші операційні витрати. Вам потрібен єдиний дашборд для моніторингу всіх регіонів, спосіб впроваджувати політики безпеки на весь флот одночасно та можливість сервісам спілкуватися між кластерами.

У цьому модулі ви навчитеся використовувати Cloud Operations Suite для глибокого аналізу логів та метрик, опануєте Managed Prometheus (GMP) для збору даних без управління серверами, навчитеся об’єднувати кластери у Fleets (Флоти) для централізованого управління та впровадите Multi-Cluster Services (MCS) для безшовного зв’язку між вашими кластерами по всьому світу.

Cloud Operations: Єдине вікно спостережуваності

GKE автоматично надсилає дані в Cloud Operations Suite. Вам не потрібно ставити агенти вручну.

Що ви бачите за замовчуванням:

Метрики системи: навантаження на вузли, поди, мережу.
Логи контейнерів: все, що поди пишуть у stdout/stderr.
Логи аудиту: хто, коли і яку команду kubectl запустив.
Контрольна панель: здоров’я API-сервера та планувальника (scheduler).

Порада: Використовуйте Log-based metrics, щоб створювати графіки на основі помилок у тексті логів (напр. кількість помилок “Connection Timeout”).

Managed Prometheus (GMP): Метрики без болю

Prometheus — це стандарт, але тримати власний кластер Prometheus для великих даних — це операційне пекло. GMP від Google дозволяє використовувати PromQL та дашборди Grafana, але зберігає дані у величезній базі Google Monarch.

Переваги GMP:

Безмежне сховище: зберігайте метрики хоч 2 роки.
Multi-cluster: ви можете одним запитом побачити завантаження CPU в усіх кластерах одночасно.
High Availability: Google гарантує доступність ваших метрик.

Fleet Management (Флоти)

Флот — це логічна група ваших кластерів. Коли ви реєструєте кластер у флоті, ви отримуєте доступ до функцій GKE Enterprise:

Config Sync: Ви кладете YAML-файли в Git, а Google сам розкочує їх на всі 50 кластерів флоту.
Policy Controller: Забороняє деплой небезпечних подів (напр. без лімітів CPU) на рівні всього флоту.
Multi-Cluster Ingress: Один балансувальник на всю планету, який направляє юзера в найближчий живий кластер.

Multi-Cluster Services (MCS)

MCS дозволяє подам у кластері “США” бачити сервіси у кластері “Європа” так, ніби вони поруч. Вам не потрібні складні VPN чи Service Mesh типу Istio для простого зв’язку.

Ви робите ServiceExport у першому кластері.
Другий кластер автоматично бачить цей сервіс за адресою ім'я.неймспейс.svc.clusterset.local.

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

Помилка	Чому це стається	Як виправити
Логування всього підряд	Призводить до величезних рахунків	Використовуйте фільтри виключення для неважливих логів
Власний Prometheus у кожному кластері	Звичка з минулого	Використовуйте Managed Prometheus (GMP); це дешевше і надійніше у масштабі
Реєстрація у флоті без Workload Identity	Fleet потребує WIF для роботи	Завжди вмикайте Workload Identity перед реєстрацією кластера у флоті
Ігнорування міжрегіонального трафіку	Трафік між регіонами дорогий	Налаштовуйте MCS так, щоб він надавав перевагу локальним подам

Тест

1. Що таке 'Consumer Lag' і чому це важливо для моніторингу?

Lag — це затримка між появою події (напр. у Kafka) і моментом, коли ваш под у кластері її обробив. Високий Lag означає, що ваші поди не встигають за реальністю, і вам потрібно масштабувати воркери.

2. У чому різниця між PodMonitoring та ClusterPodMonitoring у Managed Prometheus?

PodMonitoring працює тільки в межах одного неймспейсу (для розробників). ClusterPodMonitoring бачить поди в усьому кластері (для адмінів та системних сервісів типу node-exporter).

Практична вправа: Мультикластерний зв’язок

Зареєструйте два кластери в одному флоті.
Увімкніть MCS: gcloud container fleet multi-cluster-services enable.
Експортуйте сервіс frontend із першого кластера.
Спробуйте зробити запит до цього сервісу з другого кластера, використовуючи домен clusterset.local.
Створіть дашборд у Cloud Monitoring, який показує сумарну кількість подів у обох кластерах.

Вітаємо!

Ви завершили повну серію Глибокого занурення в Google Kubernetes Engine (GKE). Тепер ви знаєте, як будувати архітектури, налаштовувати мережі eBPF, керувати ідентичністю без паролів, працювати зі сховищами та керувати величезними флотами кластерів.

Ці знання роблять вас не просто “користувачем Kubernetes”, а хмарним архітектором, здатним будувати системи світового рівня.

Що далі?

Порівняйте GKE з іншими хмарами у Розеттському камені гіперскейлерів.
Перейдіть до треку Платформної інженерії, щоб навчитися будувати IDP на базі GKE.