В обсуждении Kubernetes полезно начать с очереди к инфраструктурной команде. Что именно в ней стоит: выдача доступа, создание окружения, выпуск новой версии, ручной перенос приложения после сбоя? Если ожидание связано с согласованием договора или отсутствием тестов, кластер его не устранит. Если инженеры снова и снова выполняют одинаковые операции запуска, появляется предмет для автоматизации.
Допустим, компания развивает несколько внутренних сервисов: заявки сотрудников, каталог оборудования и обработку документов. Команды выпускаются независимо, но каждый релиз требует особых действий администратора. Kubernetes может дать им общий способ описывать запуск. Дальше предстоит решить, кто превратит этот механизм в удобную рабочую услугу.
Платформа поддерживает заданное состояние
Команда указывает, какой образ запускать, сколько экземпляров требуется, какие ресурсы и настройки им нужны. Контроллеры сравнивают желаемое состояние с фактическим и пытаются убрать расхождение. Если экземпляр потерян, соответствующий контроллер создаёт замену, а планировщик ищет место для неё.
Важное слово — «пытается». При отсутствии свободной мощности, доступного образа или подходящего хранилища замена не станет готовой. Платформа умеет действовать по правилам, но не обещает ресурс, которого нет. Её возможности и границы перечислены в официальном обзоре Kubernetes.
Приложение всё равно кто-то собирает и проверяет. Сам Kubernetes не создаёт корректный код из исходников и не определяет, правильно ли сотрудник оформил заявку. Кластер также не обязан быть первым местом для базы данных: приложение в нём может пользоваться отдельной управляемой базой.
Работающий экземпляр ещё нужно принять в обслуживание
Сервис документов запустился, но ещё загружает шаблоны. Если немедленно отправить ему запросы, пользователи получат ошибки. Проверка готовности должна отражать возможность принимать работу. Проверка жизнеспособности отвечает на другой вопрос: поможет ли процессу перезапуск. Их смешивание способно создать цикл бесполезных перезапусков при сбое внешней базы.
Это правила самого приложения, которые платформа исполняет. Отдельный разбор есть в статье о Health Checks. Для обновления также нужно корректно закончить активные операции: перестать брать новые документы, сохранить прогресс или оставить задания для безопасного повторения.
Постепенный выпуск не гарантирует совместимость версий. Пока старая и новая копии работают вместе, они должны понимать общие данные и интерфейсы. Обратный выпуск старого образа не отменяет уже выполненную миграцию базы. Механизм Deployment управляет заменой экземпляров; бизнес-последствия замены остаются задачей команды.
Сколько ресурсов получит приложение на самом деле
В Kubernetes запрос ресурсов, request, помогает планировщику выбрать узел. Ограничение, limit, задаёт границу использования соответствующего ресурса. Это не одно и то же. Слишком скромные запросы могут привести к размещению рядом приложений, которые при реальной нагрузке мешают друг другу. Завышенные — оставить мощности плохо использованными.
Предел CPU может ограничивать доступное процессорное время. Превышение доступной памяти может закончиться остановкой процесса, а не просто замедлением. Поэтому значения нужно проверять на характерной работе, включая запуск и тяжёлые документы. Детали описаны в руководстве по управлению ресурсами.
Увеличение числа экземпляров требует отдельной политики автомасштабирования и доступной инфраструктуры. База или внешний обработчик могут не выдержать выросшего числа вызовов. Для руководителя важна пропускная способность всего рабочего процесса, а не количество зелёных экземпляров приложения.
Один общий кластер может стать общей аварией
Упаковка разных продуктов в один кластер упрощает некоторые операции, но создаёт общие зависимости: сеть, хранилище, настройки доступа, дополнительные компоненты платформы. Разделение по пространствам имён, namespaces, само по себе не даёт полной изоляции. Нужны подходящие права, квоты и сетевые ограничения, а иногда отдельные кластеры.
Размещение нескольких копий тоже должно соответствовать угрозе. Если все они зависят от одного узла или одной зоны отказа, само число реплик не защищает от её потери. Проверяют и достаточность оставшейся мощности, и доступность данных после переноса.
При обслуживании узлов можно ограничивать допустимое число добровольно выводимых экземпляров. Но такой бюджет, PodDisruptionBudget, не предотвращает аппаратный отказ и не подменяет правила обновления приложения. Эти ограничения поясняет документация по нарушениям работы Pod. Полезнее знать конкретную защиту, чем считать любой настроенный бюджет гарантией доступности.
Управляемый кластер тоже требует владельца
Провайдер может обслуживать управляющую часть и другие элементы — точная граница зависит от предложения. У компании остаются приложения, их данные, разрешения и настройки. Также кто-то должен проверять совместимость обновлений платформы, наблюдать за расходами и разбирать неудачные размещения.
Эта работа должна иметь ресурс и понятный результат для продуктовых команд. Иначе бывшая очередь на ручной запуск превратится в очередь к единственному специалисту, который понимает кластер. Руководителю стоит спросить, что разработчик сможет сделать самостоятельно и какие действия по-прежнему потребуют помощи.
Нет универсального количества сервисов, после которого Kubernetes становится выгодным. Значение имеют частота изменений, повторяемость операций, требования к размещению и готовность сопровождать платформу. Иногда управляемый запуск контейнеров решает задачу с меньшим объёмом собственной эксплуатации.
Поэтому пилот должен включать повседневную работу разработки. Может ли команда получить тестовое окружение, найти журналы, изменить лимит и выпустить исправление по понятной процедуре? Если на каждом шаге нужен отдельный специалист по платформе, ожидаемая экономия будет совсем другой.
Как сравнить варианты до большого переезда
Возьмите один типичный сервис и пройдите полный цикл: выпуск, увеличение нагрузки, остановка экземпляра, обновление узла, возврат версии. Для хранящего данные приложения добавьте восстановление. Зафиксируйте вмешательства инженеров, ожидание команды и последствия для пользователя, включая неудачные попытки.
Затем сравните результат с нынешней схемой и более простой управляемой платформой. Стоимость должна включать дежурство, обновления и сопровождение стандартного пути разработки. Принимать решение стоит по этому сравнению. Демонстрация, где удалённый контейнер красиво появляется заново, проверяет слишком маленькую часть будущей работы.