В этой статье
Небольшой сервис с дорогой платформой
Одна команда обслуживает веб-приложение, worker и БД. Выпуски редки, но кластер и CI-контроллер отнимают дни. Начните обсуждение с этого дисбаланса. Удовлетворит ли управляемая среда реальным требованиям доступности, сети и выпуска? Какая возможность исчезнет при упрощении?
Изменим сценарий: несколько команд с разными графиками выпусков, различными ресурсами нагрузок и общими обязательными правилами. Оркестрация может стать полезной. Критерий — эксплуатационная потребность, а не число пользователей. Kubernetes управляет контейнерными нагрузками, но его внедрение не создаёт дежурства, план восстановления и знание приложения.
Начните с критериев перехода
Kubernetes — не знак зрелости. Назовите ограничения простого развёртывания: изоляция, независимое масштабирование, планирование, контроль правил, ответственность нескольких команд или восстановление.
Jenkins тоже требует эксплуатации. Существующий CI уже может обеспечивать сборку, согласование, артефакты и выпуск без отдельного контроллера и набора плагинов.
Оцените весь объём эксплуатации
Учтите обновления кластера и контроллера, идентификацию, сетевые правила, секреты, наблюдаемость, ёмкость, копии, реагирование на инциденты и ответственных. Одной стоимости инфраструктуры недостаточно.
Если нет ответственного, способного отрепетировать восстановление, сменить ключи и диагностировать неудачный выпуск, платформа опережает готовность организации.
Чем обосновать потребность в платформе?
Сравните эксплуатационные обязанности до добавления инфраструктуры.
Простая исходная схема
Меньше развёртываний и компонентов, за которые нужно отвечать.
Вложения в платформу
Новые возможности планирования и выпуска, а также обновления, инциденты и ответственность.
Основания для решения
Реальное ограничение нагрузки, ответственный оператор и план восстановления.
Сделайте переход обратимым
Задайте измеримые условия и простую базовую схему. Переносите только нуждающиеся нагрузки, сохраняйте откат артефактов и проверяйте, снял ли новый слой исходное ограничение.
В записи решения укажите также условия возврата к управляемому сервису или более простой среде.
Разделите выбор CI и среды выполнения
Конвейер сборки создаёт и проверяет артефакт. Среда выполнения запускает и обслуживает его. Kubernetes не требует Jenkins, а Jenkins не требует Kubernetes. Оценивайте каждый по своим ограничениям: частной сети, существующим конвейерам, согласованиям, изоляции сборок и навыкам сопровождения.
В пробной миграции оставьте образ приложения неизменным и разверните новым путём. Отрепетируйте провал health check, недоступную зависимость и ошибку конфигурации. Запишите команды и решения восстановления. Платформа, ускоряющая успешный выпуск, но скрывающая диагностику от команды продукта, может лишь переместить узкое место.
Проверка, повторяемая после миграции
Ведите краткий журнал платформенной работы: обновления, доступы, инциденты выпуска и помощь командам. Сравнивайте с прежним подходом, временем восстановления приложения и сложностью выпусков. Изучайте выбросы, не только средние: редкий провал восстановления может быть важнее ежедневного ускорения деплоя.
Назначьте владельца плана платформы и дату пересмотра решения. Если большинство нагрузок не используют возможности, объедините их. Если общие меры доказуемо сокращают повторы работы, развивайте документацию и поддерживаемые шаблоны. Так платформа становится внутренним сервисом с клиентами и расходами, а не инфраструктурой, оправдывающей себя существованием.
Источники и дополнительное чтение
Документация проверена .
ВОПРОСЫ / РЕШЕНИЯ
Частые вопросы
Микросервисам обязательно нужен Kubernetes?+
Нет. Топология развёртывания и границы приложения — разные решения. Выбирайте оркестрацию только ради возможностей, которые сможете сопровождать.