Можете ли вы запустить кластер kubernetes внутри кластера kubernetes?

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

• Как мы управляем Kubernetes в Kubernetes aka Kubeception

Kubernetes поставляется с собственным растущим набором функций для сценариев использования с несколькими арендаторами. Однако мы стремились предложить нашим пользователям полностью управляемые Kubernetes без каких-либо ограничений функциональности, которую они получат, используя любую ванильную среду Kubernetes, включая привилегированный доступ к узлам. Кроме того, в крупных корпоративных сценариях одного кластера Kubernetes с его встроенными механизмами изоляции часто недостаточно для удовлетворения требований соответствия и безопасности. Более продвинутые (огненные) концепции зонирования или многоуровневой безопасности трудно воспроизвести с помощью одной установки. С изоляцией пространства имен вряд ли можно реализовать как привилегированный доступ, так и зоны, защищенные брандмауэром, без обхода мер безопасности.

Теперь вы можете пойти и установить несколько совершенно отдельных (и федеративных) установок Kubernetes. Однако для автоматизации развертывания и управления этими кластерами потребуются дополнительные инструменты и сложные настройки мониторинга. Кроме того, мы хотели иметь возможность раскручивать кластеры вверх и вниз по требованию, масштабировать их, обновлять их, отслеживать, какие кластеры доступны, и иметь возможность гибко назначать их организациям и группам. Фактически эту настройку можно объединить с плоскостью управления федерацией для объединения развертываний в кластеры через одну конечную точку API.

Основываясь на вышеуказанных требованиях, мы собираемся создать то, что мы называем Giantnetes - или, если вы любите кино, Kubeception. В самой основной абстракции это внешний кластер Kubernetes (настоящий Giantnetes), который используется для запуска и управления несколькими полностью изолированными пользовательскими кластерами Kubernetes.

Физические машины загружаются с помощью нашего средства начальной загрузки CoreOS Container Linux, Mayu. Сами компоненты Giantnetes размещаются самостоятельно, т.е. кублет отвечает за автоматическую загрузку компонентов, находящихся в папке манифестов. Вы могли бы назвать это первым уровнем Kubeception.

После запуска кластера Giantnetes мы используем его для планирования пользовательских кластеров Kubernetes, а также наших инструментов для управления ими и их защиты.

Мы выбрали Calico в качестве сетевого плагина Giantnetes, чтобы обеспечить безопасность, изоляцию и правильную производительность для всех приложений, работающих поверх Giantnetes.

Затем для создания внутренних кластеров Kubernetes мы инициируем несколько модулей, которые настраивают сетевой мост, создают сертификаты и токены и запускают виртуальные машины для будущего кластера. Для этого мы используем легкие технологии, такие как KVM и qemu, для предоставления виртуальных машин CoreOS Container Linux, которые становятся узлами внутреннего кластера Kubernetes. Вы могли бы назвать это вторым уровнем Kubeception.

В настоящее время это означает, что мы запускаем Pod с контейнерами Docker, которые, в свою очередь, запускают виртуальные машины с KVM и qemu. Однако, мы собираемся сделать это с помощью rkt qemu-kvm, что приведет к использованию установки rktnetes для наших Giantnetes.

Пятница, 20 января 2017 года, Гектор Фернандес, инженер-программист и Пуджа Аббасси, адвокат разработчика, Giant Swarm

• Запуск Кубернетес в Кубернетес

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

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

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

Затем, чтобы запустить внутренние кластеры, мы создаем пространство имен, генерируем сертификаты, токены и ключи SSH и разворачиваем главные компоненты. Впоследствии мы добавляем вход, чтобы сделать сервер API и т. Д. Доступным извне. Наконец, мы устанавливаем базовые плагины, такие как Heapster, kube-proxy, Kube-dns и панель инструментов.

15 марта 2017 9:49, Себастьян Шееле

Проект Checkout Gardener, который пытается это сделать.

Короче говоря, у вас есть кластер kubernetes, который управляет плоскостью управления других кластеров, как обычные поды. Кубернеты внутри кубернетов.

Невозможно запустить производственные кластеры Kubernetes внутри контейнеров.

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

Вам также следует взглянуть на OpenShift, который является форком Kubernetes с дополнительными функциями для мультитенантности.