Зелений статус Kubernetes не гарантує справності застосунку

Розрив між станом інфраструктури та коректністю застосунку

Коли розгортання в Kubernetes завершується, kubectl rollout status повідомляє про успіх, а всі поди відображаються як Running та Ready, більшість команд вважають реліз завершеним. Однак, це лише підтверджує, що Kubernetes успішно запустив нове навантаження. Kubernetes чудово підтримує бажаний стан інфраструктури: він може підтвердити, що запущено правильний образ, доступна достатня кількість реплік, і поди відповідають налаштованим умовам здоров'я. Проте, він не розуміє, що таке успішна оплата, завершене замовлення чи схвалений вхід. Це знання знаходиться поза контролером розгортання.

Саме цей розрив між здоров'ям інфраструктури та коректністю застосунку є джерелом несподіваної кількості інцидентів у продакшені. Наприклад, под може бути готовим, але використовувати облікові дані для неправильної бази даних. Сервіс може повертати HTTP 200, але публікувати події в неправильну тему Kafka. Конфігурація може бути синтаксично правильною, але містити неправильну кінцеву точку. API може бути доступним, але повертати поля, які споживачі більше не розуміють. Жодна з цих несправностей не обов'язково призведе до збою пода, але клієнт побачить незавершену транзакцію.

Обмеження Readiness-проб

Readiness-проби, такі як httpGet на /health, підтверджують, що процес застосунку запустився і може відповідати на запити. Цього достатньо для Kubernetes, щоб вирішити, чи повинен под отримувати трафік. Однак, це не підтверджує, що сервіс може дістатися до своєї бази даних, публікувати в Kafka, отримати правильну конфігурацію або завершити бізнес-операцію, для якої він існує. Проблема виникає, коли команди очікують від readiness-проби більшого, ніж вона була розроблена для перевірки.

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

Несправності, які не призводять до збою контейнера

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

• Неправильна конфігурація: Secret вказує на неправильне середовище, але містить дійсні облікові дані.
• Некоректні функції: Прапорець функції увімкнено для неправильного сегмента клієнтів.
• Проблеми сумісності: Міграція бази даних несумісна з іншою версією, що все ще працює.
• Неправильна маршрутизація: Правило service mesh надсилає трафік на неправильний бекенд.
• Проблеми з контрактами: Продюсер публікує подію, яку споживачі більше не можуть десеріалізувати, або новий реліз API змінює поле відповіді, від якого залежать нижчі сервіси.

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

Перехід від реактивного моніторингу до проактивної валідації

Більшість продакшен-систем вже збирають дані про частоту помилок, затримки, логи, трасування, глибину черги та використання ресурсів. Проблема не у відсутності спостережуваності, а в тому, коли вона використовується. Часто команди чекають завершення розгортання, а потім повертаються до звичайного моніторингу. Сповіщення спрацьовує лише після того, як достатньо трафіку пройшло через нову версію, щоб перетнути поріг. До того часу реліз може обробляти весь продакшен-трафік. Валідація розгортання використовує ті ж сигнали раніше в процесі, запитуючи: "Чи достатньо доказів, щоб продовжувати просувати цей реліз?" Це рішення має бути прийнято до того, як розгортання буде вважатися завершеним.

Додавання етапу валідації застосунку

Більш надійний процес розгортання розділяє готовність Kubernetes від валідації застосунку:

1. Розгортання нової версії.
2. Очікування готовності Kubernetes.
3. Виконання перевірок на рівні застосунку.
4. Порівняння зі стабільною версією.
5. Просування, пауза або відкат.

Автоматизація цих перевірок через Kubernetes API може значно скоротити час валідації та підвищити її послідовність. Практичний етап валідації не обов'язково має бути складним.

Типи перевірок для валідації застосунку

• Виконання однієї реальної транзакції (синтетичної): Це корисніше, ніж загальна кінцева точка здоров'я, оскільки вона перевіряє шлях, який сервіс фактично підтримує. Наприклад, для платіжної системи це може бути подання контрольованої тестової транзакції та підтвердження її досягнення очікуваного кінцевого стану. Ці тести мають бути безпечними, з ізольованими та видаляними тестовими даними.
• Порівняння нової версії зі старою: Деякі релізи не провалюються повністю, а просто працюють гірше (збільшується затримка, зростає споживання ресурсів). Порівняння нової версії зі стабільною під час канарейкового розгортання дає кращий контекст. Корисні сигнали включають: показник успішності запитів, показник завершення транзакцій, затримку p95/p99, помилки залежностей, відставання споживачів Kafka, зростання черги, обсяг повторних спроб, використання пулу з'єднань, поведінку CPU та пам'яті.
• Тестування поведінки залежностей, а не лише підключення: Перевірка підключення до порту бази даних не доводить, що застосунок може запитувати правильну схему. Корисна перевірка залежностей повинна імітувати ту саму поведінку, на яку покладається застосунок (наприклад, безпечне читання з бази даних, публікація контрольованої події в Kafka та підтвердження її споживання, валідація відповіді API за очікуваною схемою).
• Перевірки контрактних збоїв: Зміни в полях відповіді API (наприклад, transactionId на transaction_id) можуть зламати споживачів. Тести контрактів, порівняння схем та перевірки зворотної сумісності можуть виявити такі збої до повного просування.

Роль платформної команди

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

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

Що це означає для розробників

Розробникам необхідно усвідомити, що успішний статус розгортання в Kubernetes не гарантує коректної роботи застосунку. Їм слід інтегрувати додаткові перевірки на рівні застосунку, такі як синтетичні транзакції та порівняння метрик, щоб валідувати бізнес-логіку після розгортання, а не покладатися лише на readiness-проби інфраструктури.

Ключові факти

• Успішне розгортання в Kubernetes (поди Running/Ready, зелений дашборд) підтверджує лише стан інфраструктури, а не коректність бізнес-логіки застосунку.

• Kubernetes не розуміє бізнес-операцій, таких як успішна оплата чи завершене замовлення.

• Readiness-проби підтверджують лише запуск процесу та його здатність відповідати на запити, але не перевіряють доступність залежностей чи коректність бізнес-логіки.

• Застосунок може бути несправним (наприклад, неправильні облікові дані, некоректна конфігурація, зміни в контрактах API), тоді як інфраструктура залишається здоровою.

• Реактивний моніторинг часто виявляє проблеми занадто пізно, коли реліз вже обробляє продакшен-трафік.

Джерела

• A Green Kubernetes Deployment Does Not Mean a Healthy Application