Kexa (Open Source) та Kubernetes: Збір і сповіщення про логи Kubernetes - javascript.org.ua

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

У цьому посібнику я покажу, як використовувати Kexa (Open Source) для збору, зберігання та аналізу логів з Kubernetes подів.

Це включає:

Зберігання логів з подів Kubernetes в базі даних.
Виявлення помилок або конкретних шаблонів в реальному часі.
Автоматизація сповіщень на основі результатів аналізу логів.

Хочете побачити, як це виглядає? Перейдіть до розділу "очікувані результати"!

TL;DR

Kexa — це легкий та простий у реалізації Open Source скрипт, який читає YAML правила, що працюють на всіх хмарних платформах, генерує помилки та сповіщає ваші команди через різні канали, такі як SMS, Email, Teams, Jira, webhooks та інші…

У цьому посібнику ми будемо використовувати готовий репозиторій Kexa, який використовує Git Action Kexa. Kexa також можна реалізувати іншим способом, наприклад, через хмарні функції або локальний запуск.

Ми також використаємо методи сповіщення в Teams, щоб попередити вас і вашу команду про ці помилки, щоб ви могли оперативно їх усунути.

1. Налаштування

✔️ Попередні вимоги

Отримайте ваші облікові дані: ваш файл конфігурації ’~/.kube/config’ та шлях до нього. (переконайтеся, що це правильний файл конфігурації, ви також можете відновити цей файл, знову підключившись до Kubernetes через CLI та перезаписавши конфігурацію)
Отримайте вебхук каналу Microsoft Teams: Створіть вхідний вебхук — Teams | Microsoft Learn
Отримайте рядок підключення до бази даних, в яку ви хочете зберігати логи. (MySQL або PostgreSQL)

Ми охопимо всі необхідні кроки для налаштування Kubernetes, Teams та бази даних у цьому посібнику.

📦 Встановлення

Клонуйте готовий репозиторій для запуску: kexa-io/git-action-ready-to-run
Переконайтеся, що видимість репозиторію, який ви щойно скопіювали, є "приватною" на Github.

Весь цей репозиторій (& git action) працює з офіційним скриптом Kexa: kexa-io/kexa: Простір правил Kexa (Open Source)
⭐ Поставте зірочку, якщо вам подобається проект!

🔧 Налаштування облікових даних

Додавання облікових даних Kubernetes

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

Після того, як ви натиснете "New repository secret", вас попросять ввести ім’я та значення секрету.

Для імені секрету встановіть “KUB1KUBECONFIG_”.

А для значення секрету скопіюйте вміст вашого файлу конфігурації Kubernetes.

Додавання рядка підключення до бази даних

Зробіть те саме для вашого рядка підключення до бази даних, зберігши його як секрет репозиторію з ім’ям “DBCONNECTIONSTRING”.

📜 Вибір набору правил

Kexa читає файли правил (.yaml файли) з './rules', щоб виконувати сканування, тому для цього посібника Kexa буде використовувати конфігураційний файл з ім’ям ‘./config/env/kube.json’, усі файли правил, які будуть використовуватись, написані тут у цьому конфігураційному файлі.

{  
 "kubernetes":[  
 {  
 "description": "Унікальний Kubernetes від 4urcloud",  
 "prefix": "KUB1_",  
 "rules": [  
 "kubernetesLogs"  
 ]  
 }  
 ]  
}

Наприклад, тут буде використовуватися файл з ім’ям “kubernetesLogs.yaml”.

Крім того, ми додамо наш додатковий компонент для збереження логів.
Ви повинні встановити таку саму назву бази даних, яку використовує ваш рядок підключення.

{  
 "kubernetes":[  
 {  
 "description": "Унікальний Kubernetes від 4urcloud",  
 "prefix": "KUB1_",  
 "rules": [  
 "kubernetesLogs"  
 ]  
 }  
 ],  
 "save": [  
 {  
 "type": "postgres",  
 "name": "kexa_export_database", // назва вашої бази даних  
 "description": "База даних для збереження даних (docker dev)",  
 "urlName": "DB_CONNECTION_STRING",  
 "logs": true // увімкнути збереження логів в базі даних  
 }  
 ]  
}

2. Методи сповіщень

👨‍💻 Teams

Як було зазначено раніше, ви можете використовувати різні канали для сповіщення ваших команд за допомогою Kexa, у цьому посібнику ми розповімо, як налаштувати сповіщення MS Teams і налагодження логів.

Для кожного набору правил є канали сповіщень, які потрібно налаштувати. Ви можете налаштувати різний канал сповіщень для кожного рівня сповіщення, приклад у файлі “kubernetesLogs.yaml”:

- version: 1.0.0 # Введіть версію вашого файлу правил, якщо потрібно  
 date: 01-01-2025 # Введіть дату створення, якщо потрібно  
 alert:  
 fatal:  
 enabled: true  
 # встановіть false, щоб вимкнути сповіщення про фатальні помилки  
 type:   
 - teams  
 #- log   
 # раскоментуйте це, щоб увімкнути логування для фатальних помилок  
 to:  
 - 'YourTeamsWebhook'  
 error:  
 enabled: true  
 type:   
 - teams  
 #- log  
 to:   
 - 'YourTeamsWebhook'  
 warning:  
 enabled: true  
 type:   
 - teams  
 #- log  
 to:  
 - 'YourTeamsWebhook'  
 info:  
 enabled: true  
 type:   
 - teams  
 #- log  
 to:   
 - 'YourTeamsWebhook'  
 global:  
 enabled: true  
 type:   
 - teams  
 #- log  
 to:   
 - 'YourTeamsWebhook'  
 conditions:  
 - level: 0  
 min: 1  
 - level: 1  
 min: 1  
 - level: 2  
 min: 1  
 - level: 3  
 min: 1  
 # мінімальна кількість сповіщень для відправлення  
 rules:  
 # усі правила тут

Ви можете увімкнути або вимкнути кожен рівень сповіщень, встановивши “enabled” в true або false. Усі правила для сповіщень про логи доступні після цих сповіщень у файлі “kubernetesLogs.yaml”.

Ми також маємо інший посібник на Medium, який охоплює сповіщення MS Teams.

Для додаткової інформації та інших каналів сповіщень зверніться до документації Kexa: kexa-io/kexa(github.com) (⭐ Поставте зірочку, якщо вам подобається цей проект!)

3. Запуск та розклад

Після того як ви склонуєте репозиторій, у розділі “Actions” ви повинні побачити всі готові до запуску робочі процеси.

Є глобальний робочий процес, який може ініціювати всі інші робочі процеси, а також унікальний робочий процес для кожного додатку / постачальника.

▶️ Ручний запуск

Якщо ви хочете відсканувати ваше середовище Azure, наприклад, ви будете працювати з робочим процесом з назвою “Kubernetes Kexa Action”.

Ручний тригер уже налаштовано, тож ви можете запустити сканування ось так:

⏰ Плановий запуск

Як було зазначено раніше, є глобальний робочий процес, який ініціює всі інші: “Schedule Trigger All Providers”, шлях до файлу і його назва “.github/workflows/kexa.yml”.

За замовчуванням він ініціюватиме сканування кожного дня опівдні.

Ви можете змінити cronjob на свій розсуд у файлі “kexa.yml”

Потрібна допомога в редагуванні cronjob? Зверніться до таких сервісів: https://crontab.guru/ або https://crontab-generator.org, які допоможуть вам написати потрібний cronjob.

4.

Очікувані результати

📑 Логи

Перший і найпростіший спосіб переконатися, що Kexa працює, перш ніж спробувати відправити сповіщення через інші канали, як-от Teams, — це спробувати за допомогою простих логів.

Для цього потрібно розкоментувати рядки ‘logs’ у файлі “kubernetesLogs.yaml” і запустити Kexa.