На прошлой неделе Google открыл исходный код Kubernetes – системы управления контейнерами, выросшей из внутренней платформы Borg. Новость закрывает разрыв, о котором мы писали в материале про выход Docker 1.0 в продакшн: сам контейнер – это упаковка одного процесса, но эксплуатация в дата-центре требует управлять сотнями контейнеров на десятках машин. Kubernetes берёт эту задачу на себя.

Что решает оркестратор

Docker даёт воспроизводимую сборку и быстрый запуск. Но в реальной инсталляции возникают вопросы, на которые сам Docker не отвечает: на какой узел поставить контейнер, что делать при падении машины, как обновить версию без простоя, как контейнерам найти друг друга. Раньше это закрывали скриптами, cron и ручными процедурами дежурных. Скрипты не масштабируются и плохо переживают смену инженера.

Kubernetes описывает желаемое состояние декларативно. Вы говорите «нужно пять реплик сервиса вот с этим образом», а планировщик сам распределяет их по узлам, перезапускает упавшие и держит заданное число копий. Контейнеры объединяются в pod – минимальную единицу размещения, которая делит сеть и тома. Это сдвиг от управления отдельными серверами к управлению сервисом как целым.

Почему это важно для корпоративной и госинфраструктуры

Для крупного заказчика ценность не в моде, а в трёх вещах. Первое – плотность. Контейнеры на общем ядре дают в разы лучшую утилизацию железа, чем виртуальные машины под каждый сервис, а планировщик упаковывает нагрузку без ручного учёта. Второе – предсказуемое восстановление. Отказ узла перестаёт быть инцидентом с ночным звонком: реплики переезжают автоматически, по описанному регламенту, а не по памяти администратора. Третье – единый контракт на эксплуатацию. Команды разработки и сопровождения работают с одним и тем же манифестом от тестового стенда до промышленной среды.

Архитектурно оркестрация продолжает ту же линию, что и переход от точечных интеграций к шине, который мы разбирали в статье про ESB против связей точка-точка: вместо жёстко зашитых связей между конкретными хостами появляется слой, который сам находит и связывает сервисы. Контейнеру не нужно знать IP соседа – он обращается к имени сервиса, а маршрутизацию обеспечивает платформа.

Чего ждать и где осторожность

Kubernetes – ранний проект. Версии 1.0 нет, API будет меняться, экосистема хранилищ и сетей ещё формируется. Запускать на нём ядро АБС или биллинг прямо сейчас рано. Но направление выбрано верно, и за стандартом стоит компания с опытом эксплуатации миллионов контейнеров. Для отечественного заказчика это ещё и вопрос технологической независимости: открытый код можно держать в собственном контуре, без привязки к внешнему облаку, что критично для систем под регулирование персональных данных.

Разумная тактика на этот год – пилот на некритичных сервисах. Контейнеризуйте сначала то, что легко переносится: stateless-сервисы приложений. Базы данных пока оставляйте на проверенной схеме – как мы показывали в разборе миграции на PostgreSQL, для хранилища данных важнее зрелость и предсказуемость, чем гибкость размещения.

Вывод

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