21 июля 2015 года Google объявил о выпуске Kubernetes 1.0 и одновременно передал проект под управление Cloud Native Computing Foundation – нового фонда под крылом Linux Foundation. Это два события в одном анонсе, и второе важнее первого. Релиз 1.0 фиксирует стабильный API. Создание CNCF снимает главный вопрос, который останавливал корпоративных заказчиков: «А что будет с проектом, если Google потеряет к нему интерес?»
Контейнеры Docker за два года решили задачу упаковки приложения. Но как только сервисов становится десятки, а узлов – сотни, ручное управление контейнерами превращается в отдельную работу. Кто перезапустит упавший контейнер? Куда поставить новый при отказе узла? Как обновить сервис без простоя? Именно эти вопросы закрывает оркестратор, и Kubernetes 1.0 – первая версия, которую вендор официально называет готовой к продакшену.
Что именно стабилизировалось в версии 1.0
Kubernetes вырос из внутренней системы Google Borg, которая управляет их инфраструктурой больше десяти лет. В релизе 1.0 закреплены ключевые абстракции: pod как минимальная единица развёртывания, сервисы с собственными виртуальными адресами, репликационные контроллеры для поддержания заданного числа экземпляров. Декларативная модель – вы описываете желаемое состояние в YAML, а планировщик сам приводит кластер к нему – снимает с инженеров рутину императивного управления.
Для нас как интегратора это означает предсказуемость. API версии 1.0 несёт обязательство по обратной совместимости, и на нём уже можно строить production-системы, не опасаясь, что следующий релиз перепишет половину манифестов. Это тот порог зрелости, после которого технологию имеет смысл предлагать заказчику, а не держать в лаборатории.
Почему CNCF меняет правила игры
Технология без устойчивого управления – риск для любого долгого контракта, особенно в госсекторе, где система живёт пять-семь лет. CNCF переводит Kubernetes из «проекта одной компании» в нейтральный отраслевой стандарт. Под фонд уже подписались Google, Red Hat, IBM, Intel, Docker, VMware и другие. Вендорная независимость на уровне фонда – это гарантия, что выбранный сегодня оркестратор не окажется заброшенным через два года.
Открытый код и нейтральное управление отвечают и на требования импортозамещения. Кластер Kubernetes одинаково разворачивается на любой Linux-инфраструктуре – на железе в собственном дата-центре или на мощностях российского провайдера. Это прямо стыкуется с задачей размещения персональных данных в РФ, которую закон требует решить до сентября, и с практикой локализации систем под 242-ФЗ, где мы переносим прикладной стек без привязки к зарубежным облакам.
Что это даёт заказчику
Оркестрация снижает стоимость эксплуатации: одна команда обслуживает в разы больше сервисов, обновления выкатываются без простоя, отказ узла не роняет приложение. При этом Kubernetes не отменяет требований к безопасности данных – секреты в кластере, доступ к API и хранилища по-прежнему нужно защищать, и подходы вроде шифрования данных на диске остаются обязательными независимо от слоя оркестрации.
Кластеры под реальные нагрузки разворачиваются не сами по себе, а в рамках проектирования и сопровождения отказоустойчивой инфраструктуры для бизнеса и государственных заказчиков.
Kubernetes 1.0 – не финал, а старт зрелого этапа. Версия для продакшена и нейтральный фонд за спиной снимают два главных возражения против ставки на контейнерную оркестрацию. Тем, кто планирует инфраструктуру на годы вперёд, стоит закладывать эту технологию в архитектуру уже сейчас.
