Kubernetes — оркестрація контейнерів для продакшну

Налаштування Kubernetes-кластера

Kubernetes вирішує задачі масштабування й відмовостійкості, але додає власний шар складності. Тому почну з чесного: більшості інтернет-магазинів він не потрібен.

Коли він справді доречний

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

Коли краще обійтись без нього

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

Що входить

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

Про підтримку

Кластер потребує обслуговування: оновлення версій, стеження за ресурсами, розбір збоїв. Це варто врахувати в рішенні — сам по собі він не працює «як поставили».

Суміжне: налаштування Docker як простіший крок, автоматичне розгортання, моніторинг.