Чтобы попробовать Kubernetes-платформу Deckhouse в деле, придется найти мощный сервер, пространство у облачного провайдера или несколько машин и прокси-сервер. Но что делать, если хочется просто потестировать Deckhouse, а технических возможностей для этого нет? Конечно же, установить Deckhouse в kind (kubernetes in docker) — инструмент для запуска локальных K8s-кластеров, который использует в качестве узлов Docker-контейнеры. Вообще, утилита создана для тестирования Kubernetes разработчиками, но ее можно задействовать и для локальной разработки или CI.   Почему kind? Потому что тогда для наших задач сгодится даже ноутбук, а на выходе мы получим работающую инсталляцию Deckhouse, правда, с некоторыми ограничениями. Например, в kind не получится включить модули управления control-plane и узлами (хотя сам kind и поддерживает конфигурацию с несколькими узлами). Кроме того, есть сложности и по подключению внешних CNI, например того же Cilium. Встроенный в kind CNI можно отключить и поставить что-то другое (а для Cilium есть даже официальная инструкция), однако работоспособность в этом случае не гарантируется. Итак, в этой статье мы установим Open Source-версию Deckhouse с помощью kind и попробуем платформу в деле — задеплоим небольшое приложение.  В прошлых статьях мы рассматривали, как развернуть Kubernetes-кластер под управлением Deckhouse в Yandex Cloud, на bare-metal-сервере с виртуализацией и в закрытом контуре с отключенным доступом наружу. Требований к компьютеру не так много: не менее 4 ГБ оперативной памяти; macOS или Linux (Windows не поддерживается); установленный container runtime (Docker или containerd); доступ в интернет (к хранилищу образов registry.deckhouse.io). Весь процесс установки займет около 15 минут. Напомним, что Deckhouse будет развернут в минимальной конфигурации с включенным мониторингом на базе Grafana. При этом управление узлами или control-plane работать не будут. Убедитесь, что на вашем компьютере установлен container runtime: Docker (инструкция по установке) или containerd, — а также Docker-клиент. В GitHub платформы есть заранее подготовленный скрипт — он установит все зависимости, включая сам kind, а затем развернет в нем кластер под управлением Deckhouse. Запустим скрипт, взяв его напрямую с GitHub: С помощью этой команды мы устанавливаем Community-версию Deckhouse (CE). Если у вас есть лицензионный ключ для Enterprise-версии, воспользуйтесь другой командой: <LICENSE_KEY> — это как раз лицензионный ключ. Сразу после запуска скрипт проверит, установлены ли нужные утилиты: Если в системе не установлены зависимости (Docker или kubectl), скрипт завершится ошибкой, а в сообщении об ошибке вам порекомендуют установить необходимые зависимости. Если в системе еще нет kind, скрипт предложит установить его в автоматическом режиме. Соглашаемся с ним, указав y: Установка в домашний каталог пользователя — стандартный подход, поэтому ничего не меняем и просто нажимаем Enter. Теперь необходимо указать имя будущего кластера. Оставим вариант по умолчанию (d8) и просто еще раз нажмем Enter. Кластер развернулся, теперь начнется установка Deckhouse — пройдет она автоматически.   Deckhouse установлен. Теперь разберем, что у нас выводится в нижней части лога: адрес кластера на базе сервиса sslip.io; имя пользователя и пароль, с помощью которых можно зайти в Grafana. Откроем адрес из нижней части лога в браузере. Обратите внимание, что этот адрес локальный и работать будет только на вашем компьютере. Теперь введем имя пользователя и пароль от Grafana и попадем на главную страницу с дашбордами: Здесь отображается состояние кластера и включенных модулей, а также указаны версии компонентов. Например, сейчас мы установили актуальную на момент создания статьи Stable-версию Deckhouse 1.50.6 CE. Кластер полностью рабочий, убедиться в этом можно с помощью kubectl, контекст для которой также был автоматически настроен на работу с kind: Команда показала нам набор узлов в кластере — правда, сейчас у нас только один узел с установленным Deckhouse. Ура! Мы можем управлять модулями и пользоваться всеми возможностями платформы, чтобы ознакомиться с ней, — начать можно с официальной документации. Кроме того, можно задеплоить в кластер простое приложение из нашего самоучителя по Kubernetes — так мы убедимся, что кластер способен выполнять базовые функции, и посмотрим на Deckhouse в деле. Итак, приступим.  Для начала склонируем репозиторий с приложением, скопируем его в отдельный каталог и подготовим к развертыванию. Напомним, что мы будем брать уже готовое приложение из нашего самоучителя. Мы создали каталог ~/werf-guide/app, инициировали в нем Git-репозиторий и скопировали туда исходные файлы приложения. Это простое приложение на базе эхо-сервера, реализованного в виде bash-скрипта (start.sh): Собирать и развертывать приложение мы будем с помощью Open Source-утилиты werf, поэтому в корне проекта находится конфигурационный файл werf.yaml, в котором описано, как собирать образ будущего контейнера (там сразу указан нужный Dockerfile): Dockerfile, в котором описаны инструкции для сборки Docker-контейнера, также расположен в корне проекта и выглядит вот так: Осталось подготовить Helm-чарты, описывающие ресурсы в кластере. Их будет три, и расположены они будут в каталоге ./helm/templates. Первый — Deployment, в котором описано само приложение (deployment.yaml): В разделе image указан образ, собираемый werf. Чтобы контейнер был доступен внутри кластера, используется ресурс Service, описанный в service.yaml: А для внешнего доступа (снаружи кластера) настроен Ingress (ingress.yaml): Здесь указано, что наше приложение доступно по адресу http://werf-guide-app.127.0.0.1.sslip.io/. Не забудьте поменять адрес в исходном файле Ingress, загруженном из репозитория, и закоммитить изменения в локальный Git-репозиторий, созданный в ~/werf-guide/app. Для хранения собранных образов воспользуемся Dockеr Hub. В нем необходимо создать приватный репозиторий с именем werf-guide-app. Войдем в Docker Hub на компьютере: Теперь создадим новое пространство имен в кластере, в котором будет разворачиваться приложение: Переключим контекст kubectl на кластер kind с использованием созданного пространства имен по умолчанию: Создадим Secret с параметрами доступа в container registry: Все готово для развертывания! Как всегда при работе с werf, развертывание приложения производится одной командой: Спустя пару минут увидим следующее сообщение: Ура! Приложение развернуто в кластере! Проверим, что оно работает: Висящий в фоне кластер kind постоянно потребляет ресурсы компьютера, пусть и небольшие. Также он занимает 80-й порт, что может помешать работе с другими сервисами. Так что после тестирования Deckhouse необходимо будет удалить наш кластер. Делается это просто: Теперь на компьютере не осталось ничего лишнего. В статье мы рассмотрели, как познакомиться с Deckhouse, установив его на рабочий компьютер в среде kind. После всех действий мы получили работоспособный кластер под управлением Deckhouse, в который можно деплоить свои приложения и выполнять различные действия с модулями кластера в соответствии с официальной документацией. С любыми вопросами и предложениями ждем вас в комментариях к статье, а также в Telegram-чате deckhouse_ru, где разработчики платформы всегда готовы помочь и ответить на вопросы. Будем рады issues (и, конечно, звездам) в GitHub-репозитории Deckhouse. Полезные ссылки: Чаты по Deckhouse и werf, в которых на вопросы пользователей отвечают разработчики — если вдруг что-то пойдет не так или не получится.  Самоучитель по Kubernetes от команды werf для DevOps-инженеров и разработчиков с уроками по CI/CD созданию приложений и разворачиванию окружения с примерами для node.js, Spring, django, Python, Go, Ruby on Rails, Laravel. Читайте также в нашем блоге: Устанавливаем Kubernetes-платформу Deckhouse в закрытом окружении. Пошаговая инструкция Разворачиваем Kubernetes-кластер на bare metal под управлением Deckhouse и создаем в нем виртуальные машины Запуск одноразовых задач и отладка образов прямо в Kubernetes-кластере с помощью werf  Technical writer, Linux-user