OpenShift в продакшене: платформа как продукт для команд разработки

Кластер — это не «место, куда складывают контейнеры». Это внутренний продукт, у которого есть пользователи (команды разработки), договор об уровне сервиса и цена владения. Как только на платформу заходит больше десятка приложений, разница становится критичной.

Платформа как продукт

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

Что нужно стандартизировать в первую очередь

1. Проекты и квоты. Каждая команда получает изолированное пространство с лимитами по процессору, памяти и хранилищу. Без квот один эксперимент кладёт соседей.
2. Шаблоны развёртывания. Готовые манифесты с probes, лимитами, политиками перезапуска и метриками — чтобы правильный вариант был самым простым.
3. Пайплайны. Единый путь от коммита до продакшена со сборкой образа, сканированием на уязвимости и подписью артефакта.
4. Наблюдаемость по умолчанию. Логи, метрики и трассировки подключаются самим фактом деплоя, а не отдельным проектом полгода спустя.

Хороший показатель зрелости платформы — время вывода новой команды на неё. Если это две недели переписки, платформа существует только на бумаге.

Три частые ошибки

Тащить в контейнеры всё подряд. Стабильный монолит с релизом раз в полгода в контейнерах не станет лучше — он станет сложнее в эксплуатации. Контейнеры выигрывают там, где часто меняется код и нужна горизонтальная масштабируемость.

Экономить на лимитах. Приложение без описанных requests/limits планировщик размещает вслепую. Результат — вытеснение соседей и загадочные перезапуски по ночам.

Забыть про состояние. Базы данных в кластере требуют отдельного разговора про хранилище, резервные копии и восстановление. Это возможно, но никогда не «само собой».

Эксплуатация: что делать каждый месяц

• Обновление версии платформы по графику, а не «когда-нибудь».
• Пересмотр квот по факту потребления — освобождение мёртвых проектов.
• Проверка восстановления кластера и приложений из резервных копий.
• Отчёт командам: сколько ресурсов потреблено и сколько это стоит компании.

Итог

Сотни приложений в одном кластере живут мирно ровно до тех пор, пока есть правила и человек, который отвечает за платформу целиком. Технологии здесь вторичны: тот же результат достигается и на чистом Kubernetes, вопрос только в том, сколько вы готовы построить сами.