Столкнувшись с проблемой создания управляемого сервиса Kubernetes в OVH, полностью основанного на инструментах с открытым исходным кодом, нам пришлось принять несколько жестких проектных решений. Сегодня мы рассмотрим один из них…

Одним из наиболее структурных решений, которые мы сделали при создании сервиса OVH Managed Kubernetes, было развертывание кластеров наших клиентов над нашими собственными. Kubinception действительно…

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

Как работает кластер Kubernetes?

Чтобы полностью понять, почему мы запускаем Kubernetes на Kubernetes, нам нужно хотя бы базовое понимание того, как работает кластер Kubernetes. Полное объяснение по этому вопросу находится вне контекста этого поста, но давайте сделаем краткий обзор:
Рабочий кластер Kubernetes состоит из:

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

Основные компоненты

В этой категории компонентов у нас есть:

• Сервер API: предоставляет API Kubernetes. Это точка входа в плоскость управления Kubernetes.
• Планировщик: наблюдает за вновь созданными модулями и выбирает узел для их запуска, управляя распределением ресурсов.
• Контроллер-менеджер: запускайте контроллеры, контуры управления, которые следят за состоянием кластера и перемещают его в желаемое состояние.
• ETCD: согласованное и высокодоступное хранилище значений ключей, используемое в качестве резервного хранилища Kubernetes для всех данных кластера. Эта тема заслуживает отдельного поста в блоге, поэтому мы поговорим об этом в ближайшие недели.

Компоненты узла

В каждом узле у нас есть:

• Kubelet: агент, который следит за тем, чтобы контейнеры, описанные в PodSpecs, работали и работали. Это связь между узлом и плоскостью управления.
• Kube-proxy: сетевой прокси, работающий на каждом узле, позволяющий абстрагировать сервис Kubernetes, поддерживая сетевые правила и выполняя переадресацию соединений.

Наша цель: быстрое и безболезненное развертывание кластера

Как мы пришли от этой простой архитектуры Kubernetes к Kubernetes вместо Kubernetes? Ответ кроется в одной из наших основных целей при создании сервиса OVH Managed Kubernetes: иметь возможность развертывать кластеры самым простым и автоматизированным способом.

И мы хотели не только развертывать кластеры, мы хотели, чтобы развернутые кластеры были:

• Эластичный
• Изолированные
• Оптимизированный по стоимости

Kubinception: запуск Kubernetes поверх Kubernetes

Идея состоит в том, чтобы использовать кластер Kubernetes, который мы называем административным кластером, для развертывания клиентских кластеров.
Как и каждый кластер Kubernetes, клиентские кластеры имеют набор узлов и плоскость управления, состоящую из нескольких главных компонентов (сервер API, планировщик…).
Что мы делаем, так это развертываем эти главные компоненты клиентского кластера в качестве модулей на узлах административного кластера.




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

А рабочие узлы клиентского кластера? Это обычные узлы Kubernetes: экземпляры общедоступного облака OVH, подключающиеся к серверу API клиентского кластера, работающему в модуле кластера администрирования.



Наша цель — управлять большим количеством кластеров, а не одним, так как же добавить еще один кластер клиентов? Как и следовало ожидать, мы развертываем новую плоскость управления клиентским кластером на узлах административного кластера.



С точки зрения административного кластера, мы просто развернули три новых модуля. Затем мы создаем несколько новых экземпляров узлов и подключаем ETCD, и кластер готов.

Если что-то может выйти из строя, оно сделает это

Теперь у нас есть архитектура, которая позволяет нам быстро развертывать новые кластеры, но если мы вернемся к нашей цели, быстрое развертывание было только половиной, мы хотели, чтобы кластер был устойчивым . Начнем с отказоустойчивости.
Узлы клиентского кластера уже устойчивы, так как они являются обычными узлами Kubernetes , а устойчивость ETCD будет подробно описана в отдельном сообщении в блоге, поэтому давайте посмотрим на устойчивость плоскости управления, поскольку это особая часть нашей архитектуры.
И в этом прелесть архитектуры Kubinception, мы развертываем плоскость управления клиентскими кластерами в виде простых стандартных модулей в нашем административном кластере. А это означает, что они столь же устойчивы, как и любой другой модуль Kubernetes: если один из основных компонентов клиентского кластера выйдет из строя, диспетчер-контроллер административного кластера обнаружит его, и модуль будет перепланирован и повторно развернут без каких-либо ручных действий в нашем сторона.

Какой лучший способ убедиться, что наши Kubernetes достаточно надежны ...

Основание нашего сервиса Managed Kubernetes на Kubernetes заставило нас наткнуться на аспекты Kubernetes, которые мы не видели раньше, чтобы узнать много нового об установке, развертывании и эксплуатации Kubernetes. И все эти знания и инструменты были напрямую применены к нашим кластерам клиентов, что сделало их опыт удобнее для всех.

А как насчет масштабирования

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

Что дальше?

Поскольку этот пост уже достаточно длинный, я оставляю объяснение на ETCD для следующего поста в серии, через две недели. На следующей неделе давайте сосредоточимся на другой теме, мы займемся Apache Flink и тем, как его использовать для обработки предупреждений в масштабе OVH…