Год назад, в июле 2015-го, Google выпустил Kubernetes 1.0 и сразу передал проект под управление Cloud Native Computing Foundation – фонда при Linux Foundation. За двенадцать месяцев оркестратор контейнеров прошёл путь от внутренней разработки одной компании до отраслевого стандарта, который поддерживают Red Hat, CoreOS, IBM, Huawei и десятки других вендоров. Для интегратора это сигнал: технология вышла из стадии эксперимента и её можно закладывать в продакшен-инфраструктуру заказчика.
Почему управление через CNCF важнее версии
Передача Kubernetes нейтральному фонду – не формальность. Она снимает с заказчика главный риск открытого ПО: зависимость от единственного вендора. Проект развивают по прозрачному процессу, спецификации публичны, а конкурирующие компании вкладывают код в общий репозиторий, а не в форки. Это та же логика, по которой государство ведёт реестр отечественного ПО: предсказуемость и контроль над технологическим стеком ценятся выше скорости.
Для госсектора нейтральное управление снимает ещё один вопрос. Kubernetes работает поверх Linux и не требует проприетарной платформы, поэтому его можно развернуть на отечественном железе и в защищённом контуре без лицензионных привязок к зарубежному облаку.
Что изменилось за год в зрелости
Версия 1.2, вышедшая весной, подняла потолок кластера до 1000 узлов и 30 000 контейнеров и добавила объекты Deployment и DaemonSet – мы разбирали это в материале о Kubernetes 1.2 в продакшене. К лету подоспела версия 1.3 с поддержкой StatefulSet в альфе и федерацией кластеров. Появились первые рабочие практики для stateful-нагрузок – баз данных и очередей, которые раньше держали в стороне от оркестрации.
Параллельно созрела экосистема вокруг ядра: Helm для упаковки приложений, Prometheus как штатный инструмент мониторинга, сетевые плагины через интерфейс CNI. Год назад этого набора не было, и каждый внедренец собирал инфраструктуру вручную. Сейчас есть проверенные кирпичи.
Когда Kubernetes оправдан, а когда нет
Оркестратор решает конкретную задачу – управление множеством сервисов, которые нужно масштабировать, обновлять без простоя и автоматически перезапускать при сбое. Если у заказчика три монолитных приложения на выделенных серверах, Kubernetes добавит сложности без отдачи. Если же нагрузка скачет в разы и команда движется к микросервисам – кластер окупается.
Внезапный наплыв пользователей перестаёт быть катастрофой: мы видели это на примере инфраструктурных уроков Pokémon GO, где сервис не справился с реальным спросом. Декларативное описание состояния и горизонтальное автомасштабирование – прямой ответ на такие пики.
Главная цена входа – кадры. Кластер требует инженеров, которые понимают сеть, хранилище и саму модель Kubernetes. Поэтому решающим оказывается проектирование и развёртывание кластера на отечественной или гибридной инфраструктуре с последующей передачей команде заказчика вместе с документацией и регламентами эксплуатации.
Вывод
За год Kubernetes стал тем, на что можно опереться в серьёзном проекте: открытое управление через CNCF, растущая экосистема, поддержка stateful-нагрузок. Но это инструмент под определённый класс задач, а не универсальное решение. Считайте отдачу до внедрения, а не после и закладывайте в смету не только кластер, но и компетенции, которые его обслуживают.
