Kubernetes 1.0: Google объявляет оркестрацию production-ready

На OSCON Google объявили Kubernetes 1.0 и одновременно анонсировали передачу проекта в Cloud Native Computing Foundation, создание которого объявили там же. Первый стабильный релиз оркестратора контейнеров, который Google использует внутри для управления собственной инфраструктурой. Анонс крупный - следим за ним с прошлого года, а теперь есть повод разобраться предметно.

Откуда у нас вообще этот вопрос

Когда мы писали про Docker 1.0, честно зафиксировали: сам Docker умеет запускать один контейнер на одном хосте. Всё, что сложнее, - не его зона. Нужен оркестратор: инструмент, который решает где запустить контейнер, что делать при падении хоста, как раскатить обновление без простоя.

С тех пор прошёл год. Контейнеров у нас прибавилось - сейчас Docker 1.6 крутит несколько сервисов на двух хостах. Управляем руками: Ansible-плейбук поднимает контейнеры, systemd-юниты их перезапускают при падении, nginx распределяет трафик. Работает, но каждый новый сервис - это очередной юнит, очередной кусок плейбука, очередное место где можно опечататься. Вопрос «а что дальше после docker run» стал практическим.

Что такое Kubernetes на сегодня

Kubernetes - это система управления кластером контейнеров. Несколько ключевых абстракций, которые важно понимать:

• Pod - минимальная единица развёртывания, один или несколько плотно связанных контейнеров на одном хосте, которые разделяют сеть и тома.
• Service - стабильный сетевой адрес для группы подов. Поды могут перезапускаться и менять IP, Service не меняется - клиенты смотрят на него.
• ReplicationController - следит чтобы всегда бежало ровно N копий пода. Упал хост - контроллер запустит под на другом.
• Scheduler - принимает решение на каком узле запустить под, исходя из доступных ресурсов.

Это не просто «запустить контейнер на нескольких машинах». Kubernetes моделирует инфраструктуру как желаемое состояние: ты описываешь что хочешь, система постоянно reconciliat-ит реальность с описанием. Если что-то разъехалось - исправляет само.

Что нас цепляет, что настораживает

Концепция desired state нам симпатична - мы уже мыслим в этих терминах через Ansible и Fig/Compose. Kubernetes делает то же самое, но для кластера с несколькими хостами, и с петлёй обратной связи которая работает постоянно, а не только в момент раскатки.

Service Abstraction решает реальную боль: сейчас при перезапуске контейнера меняется IP, и нужно обновлять конфиги nginx вручную. Стабильный виртуальный IP для группы подов - это то что нам нужно.

Но есть и то что останавливает.

Сложность развёртывания самого кластера. Kubernetes состоит из нескольких компонентов: etcd как хранилище состояния, API-сервер, scheduler, controller-manager, плюс на каждом узле kubelet и kube-proxy. Поднять это всё вручную и поддерживать - серьёзная инженерная задача. В документации 1.0 есть инструкции для GCE и AWS, для bare metal - заметно скромнее.

Работа с сетью. Kubernetes требует чтобы каждый под имел уникальный IP в пределах кластера, и поды могли общаться напрямую без NAT. Это не тривиально реализовать на обычном хостинге или bare metal. Нужны flannel, Weave или аналогичный overlay. Дополнительный компонент, дополнительная точка отказа.

Объём YAML. Описание одного приложения с сервисом, контроллером репликации и конфигмапой - это уже несколько сотен строк YAML. Хорошо что это код и лежит в git, но порог входа ощутимый.

Чем Kubernetes отличается от конкурентов

Сейчас в пространстве оркестрации несколько игроков. Docker Swarm развивается активно и обещает работать поверх обычного Docker API - минимальная переквалификация. Mesos от Mesosphere - более взрослая система, используется в Twitter и Airbnb, умеет оркестрировать не только контейнеры. CoreOS Fleet проще, но и возможностей меньше.

Kubernetes идёт своим путём: собственные абстракции, собственное API, опыт Google в production-оркестрации за плечами. Это одновременно и аргумент в пользу зрелости концепции, и аргумент в пользу vendor lock-in на специфический способ мышления.

Что делаем прямо сейчас

Разворачиваем тестовый кластер из трёх машин по документации 1.0. Задача простая: взять одно из наших приложений, которое сейчас живёт в двух контейнерах через Compose, описать его в терминах Kubernetes и посмотреть как ведёт себя при имитации падения узла.

Это managed-инфраструктура для части клиентов, поэтому нас особенно интересует сценарий: упал хост - сколько времени прошло до восстановления сервиса. С текущей схемой ответ «пока дежурный не заметит и не запустит вручную». Если Kubernetes решает это автоматически - это уже весомый аргумент.

Пока смотрим. 1.0 - это первая версия с обещанием стабильного API, не более. На стабильность концепции указывает скорее то, что Google использует Kubernetes-идеи внутри несколько лет. Но Kubernetes сам по себе для нас новый, и гарантировать что он не удивит в неожиданный момент - нельзя. Так что для теста - да, для продакшн-клиентов - после того как сами набьём шишки.