Kubernetes часто продають як щось, що саме зробить систему стійкою. Мовляв, поставив кластер — і воно саме перезапустить, саме розкладе, саме витримає навантаження. Це небезпечна ілюзія. Kubernetes не робить систему стійкою. Він лише дуже чесно показує, наскільки стійким ти зробив свій застосунок.
Простий приклад. Оркестратор може будь-коли вбити твій под — під час деплою, при перерозподілі навантаження, при виході ноди з ладу. Це не збій, це нормальна робота. Але якщо твій сервіс не вміє чисто завершуватись, не обробляє SIGTERM, кидає клієнтів посеред запиту — Kubernetes просто зробить цю проблему регулярною. Раніше під падав раз на місяць, і ти цього не помічав. Тепер він рухається щодня, і кожен рух — це обірвані запити.
Те саме з probes. Ліміти, readiness, liveness — це не бюрократія з ямл-файлів. Це спосіб сказати кластеру, коли под справді готовий приймати трафік, а коли його треба лишити в спокої. Неправильний liveness-probe перетворює тимчасове гальмування на нескінченний цикл перезапусків. Я бачив системи, які самі себе клали під навантаженням саме через це: сервіс тупив, probe вважав його мертвим, кластер убивав под, навантаження йшло на сусідні — і вони теж падали по черзі.
Мій підхід простий. Kubernetes — це не страховка, а контракт. Він каже: я готовий пересувати, перезапускати й масштабувати твій застосунок будь-коли, але за це ти маєш зробити його таким, що переживає ці рухи. Graceful shutdown. Ідемпотентні операції. Стан не в памʼяті поду, а зовні. Чесні probes. Ліміти ресурсів, щоб один сервіс не зʼїв ноду цілком.
Коли контракт виконано, кластер справді дає стійкість — под падає, а користувач нічого не помічає. Коли контракт порушено, ти отримуєш дорогий і складний спосіб робити ті самі старі помилки, тільки частіше й помітніше. Тому перед тим як хвалити Kubernetes за стійкість, я завжди питаю: а мій застосунок узагалі готовий до того, що його будь-коли переставлять?
– Sergey Shinder
