Kubernetes у продакшені: де платформні рішення непомітно провалюються

Кожен керівник платформи отримує у спадок одну й ту саму пастку: робочий кластер Kubernetes, який хтось колись назвав «готовим». А потім о 3-й ночі настає Sev-1, телеметрія не корелює, і SOC-аналітик запитує, чому сповіщення пройшло чотири переходи, перш ніж надійшло. Саме в цьому розриві між «зеленим» кластером і продакшн-платформою бюджети на розробку тихо зникають.

Нова стаття Алекса Вакулова розбирає, де саме ці платформні рішення руйнуються, коли на них потрапляють реальні навантаження. Діагноз збігається зі шаблонами, які я спостерігаю в iGaming- і fintech-компаніях протягом майже десяти років.

Ключові деталі

Kubernetes прийнято вважати «безкоштовним», і, як пояснює Cloud Native Now, це припущення розсипається в момент, коли ви намагаєтесь запустити на ньому щось продакшн-рівня. Стандартна інсталяція надає базові примітиви оркестрації. Вона не надає платформу.

Перелік того, що командам доводиться додавати, не є екзотикою. Це один і той самий чекліст, з яким зрештою стикається кожен оператор:

• Мережеві плагіни для з'єднання сервісів
• Ingress-контролер для маршрутизації трафіку
• Інтеграція CI/CD для пайплайнів доставки
• Системи моніторингу, логування та трейсингу
• Механізми автентифікації та авторизації

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

Стаття формулює вибір як «будувати чи купити». Внутрішні платформи адаптуються під конкретне середовище. Вендорні дистрибутиви обіцяють швидшу стандартизацію та менше навантаження в перший день. Обидва шляхи натрапляють на ті самі стіни, просто на різних відрізках.

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

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

І незалежно від підходу, в кожному продакшн-кластері з'являються одні й ті самі компоненти: контролери деплойменту, моніторинг, пайплайни логування та трейсингу, застосування політик і розширення кастомних ресурсів. Від цього прихованого шару відмовитися не вийде.

Чому це важливо для інженерних команд

Цифра «двоє інженерів на десятки кластерів» — та, яку я б обвів червоним. У платформній команді з 10 осіб це приблизно 20% фонду оплати праці, витрачених лише на підтримку субстрату, ще до того, як хтось торкнеться developer experience. У компактній інженерній організації з 30 осіб команда з шістьох у стані «стабільно, але без розвитку» — це п'ята частина компанії, що стоїть на місці. Це не вартість інструментів. Це витрати можливостей, виміряні у фічах, які так і не були випущені.

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

Залежність від вендора — друга міна. Коли оновлення та зміни конфігурації залежать від вендорних термінів, ваш CAB-календар вам більше не належить. Коли аналіз першопричин потребує участі вендора, ваш MTTR має нижню межу, яку не можна подолати інженерно. Для fintech- і iGaming-платформ, що працюють цілодобово з жорсткими SLA, ця межа важливіша, ніж маркетинговий слайд про «швидке розгортання в перший день».

Моя думка: вісь «будувати чи купити» — не та вісь. Справжня вісь — чи має ваша команда дисципліну, щоб забезпечити послідовні мітки, ідентифікацію сервісів та теги середовища в кожному сигналі з першого дня. Команди, які правильно налаштовують телеметрію, виживуть на будь-якому шляху. Ті, що ні, у підсумку вручну реконструюють інциденти о 4-й ранку — незалежно від того, хто продав їм control plane.

Вплив на галузь

Для iGaming-операторів кадрова реальність найбільш боляче дається взнаки під час масштабування. Команда з шістьох, стабільна, але без розвитку, не може одночасно поглинути запуск нової юрисдикції, інтеграцію нового платіжного провайдера та онбординг нової ігрової студії в одному кварталі. Щось ламається — як правило, developer experience — і продуктові команди починають обходити платформу стороною. Стаття прямо про це говорить: якщо команди регулярно деплоять поза платформою, вона вже перестала бути стандартом. Цю фразу варто роздрукувати й повісити на стіну кожній платформній команді.

У fintech та сама проблема має гостріший вигляд. Комплаєнс-команди очікують детермінованих аудиторських слідів. Коли телеметрія непослідовна, а логи, метрики та трейси перестають корелювати, зв'язок розривається й інциденти вимагають ручного відновлення. Ручне відновлення ще якось підходить для блог-постмортему. Але не тоді, коли регулятор запитує, чому платіж не пройшов о 02:14:33 UTC. Інвестиції в конвенції, узгоджені з OpenTelemetry, відповідно до специфікації OTel, з самого початку коштують дешевше, ніж їх ретрофіт після першої аудиторської знахідки.

Команди crypto- та DeFi-інфраструктури стикаються з проблемою вендорної залежності в особливо болісній формі. Чейни форкаються, RPC-провайдери змінюють поведінку, і кластер має адаптуватись цього тижня, а не в наступному кварталі за вендорним роадмепом. Внутрішні платформи виграють тут, але лише якщо команда має достатньо людей, щоб реально їх розвивати. Інакше ви побудували специфічний тягар з обслуговування без тієї гнучкості, яка його виправдовувала.

Невтішний висновок: більшість середніх інженерних організацій обирають найгірше з обох світів. Вони купують вендорний дистрибутив, щоб «зекономити» на кадрах, а потім набирають внутрішню команду з шістьох для його інтеграції з SOC, ITSM і CI/CD — і в підсумку платять і за ліцензію, і за роботу.

На що звертати увагу

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

Перший — рівень обходу. Порахуйте сервіси, задеплоєні поза «золотим шляхом» платформи за останні 90 днів. Якщо продуктові команди уникають онбордингу, бо він вимагає глибоких знань безпеки Kubernetes або тривалої ручної конфігурації, платформа вже перестала бути стандартом. Цифра не має дорівнювати нулю, але має мати тенденцію до зниження.

Другий — календар платформної команди. Якщо платформні інженери проводять більшість тижня в тікетах і на бриджах з інцидентів, платформа підтримується, а не розвивається. Це передумова того, що крива зрілості в один-два роки розтягнеться до трьох-чотирьох.

Третій — інциденти, залежні від вендора. Відстежуйте, скільки інцидентів Sev-1 та Sev-2 потребували участі вендора для діагностики. Якщо ця кількість суттєва, ваш MTTR частково аутсорсований, а ваша ротація чергових — фікція.

Референсні архітектури від Google Cloud корисні як перевірка здорового глузду, але вони передбачають базовий рівень зрілості платформи, якого більшість команд ще не досягла. Спершу відкалібруйтеся за власним рівнем обходу.

Ключові висновки

• «Безкоштовний» Kubernetes — це примітиви оркестрації. Платформа навколо нього — мережа, ingress, CI/CD, observability, authn/authz — є реальним центром витрат.
• Кадрова реальність: двоє інженерів можуть керувати десятками кластерів, але не можуть кастомізувати; шестеро можуть підтримувати стабільність, але не можуть розвивати developer experience. Плануйте кадри відповідно.
• Внутрішні платформи досягають зрілості за один-два роки. Вендорні платформи дають можливості раніше, але переносять залежність на терміни оновлень та діагностику інцидентів.
• Послідовні мітки, ідентифікація сервісів та теги середовища в логах, метриках і трейсах з першого дня — не предмет для обговорення. Ретрофіт гігієни телеметрії болючий і помітний при аудиті.
• Якщо продуктові команди регулярно деплоять поза платформою, вона вже втратила свій мандат. Вимірюйте рівень обходу раніше, ніж будь-що інше.