Deckhouse Platform в закрытом окружении: Информация об установке

1
Выбор инфраструктуры
2
Информация об установке
3
Подготовка к установке
4
Установка
5
Завершение установки
6
Куда двигаться дальше?
Информация об установке

В Deckhouse Академии доступен для прохождения курс обучения «Установка Deckhouse Platform в закрытом окружении».

Презентация содержит основные этапы установки, которые предстоит пройти.

Схема развертывания

Данное руководство предлагает развертывание кластера Kubernetes с помощью Deckhouse Platform в закрытом окружении, из которого нет прямого доступа к внешнему хранилищу образов контейнеров (registry.deckhouse.ru) или внешним репозиториям deb/rpm-пакетов.

Установка в закрытом окружении в целом аналогична установке на bare metal. Отличие только в некоторых дополнительных параметрах настройки.

Подробнее с установкой и обновлением DP в закрытом окружении можно ознакомиться в руководствах «Установка DP в закрытом окружении» и «Обновление DP в закрытом окружении».

Схема развертывания Deckhouse Platform в закрытом окружении:
Схема развертывания Deckhouse Platform в закрытом окружении

Внутренний репозиторий пакетов ОС необходим для установки curl на узлах будущего кластера (при отсутствии возможности доступа к официальным репозиториям через прокси-сервер).

Что необходимо для установки

  1. Персональный компьютер. Компьютер, с которого будет производиться установка. Он нужен только для запуска инсталлятора Deckhouse Platform и не будет частью кластера.

    Требования...

    • ОС: Windows 10+, macOS 10.15+, Linux (Ubuntu 18.04+, Fedora 35+);
    • установленный docker для запуска инсталлятора Deckhouse Platform (инструкции для Ubuntu, macOS, Windows);
      • на компьютерах с процессорами семейства Apple Silicon включите опцию «Use Rosetta for x86_64/amd64 emulation on Apple Silicon» в настройках Docker Desktop, чтобы избежать возможных проблем с запуском ssh-agent во время установки;
    • доступ до проксирующего registry (настройка стороннего registry) или до частного хранилища образов контейнеров с образами контейнеров Deckhouse Platform;
    • SSH-доступ по ключу до узла, который будет master-узлом будущего кластера.
    • SSH-доступ по ключу до узла, который будет worker-узлом будущего кластера (если кластер будет состоять не из одного master-узла).

  2. Физический сервер или виртуальная машина для master-узла.

    Требования...

    Deckhouse Platform имеет механизм контроля целостности модулей, который защищает их от подмены и изменения. Этот механизм включается автоматически при поддержке операционной системой на узлах, где установлен Deckhouse Platform, модуля ядра erofs. При отсутствии этого модуля ядра Deckhouse Platform продолжит работу без механизма контроля целостности модулей, при этом появится алерт о неработоспособности этой функциональности.

    На следующем шаге данного руководства в качестве container runtime по умолчанию на узлах кластера указан ContainerdV2. Чтобы использовать ContainerdV2 в качестве container runtime на узлах кластера, они должны соответствовать следующим требованиям:

    • поддержка CgroupsV2;
    • systemd версии 244 и новее;
    • поддержка модуля ядра erofs;
    • версия ядра Linux не входит в диапазоны 6.12.0–6.12.28 или 6.14.0–6.14.6 (эти версии подвержены уязвимости CVE-2025-37999 в EROFS).

    Некоторые дистрибутивы (например, Astra Linux 1.7.4) не соответствуют этим требованиям, и ОС на узлах необходимо привести в соответствие требованиям перед установкой Deckhouse Platform. Подробнее — в описании параметра defaultCRI.

    • не менее 4 ядер CPU (рекомендовано 8 ядер CPU);
    • не менее 8 ГБ RAM (рекомендовано 16 ГБ RAM);
    • не менее 60 ГБ дискового пространства на быстром диске (400+ IOPS);
    • поддерживаемая ОС;
    • ядро Linux версии 5.8 или новее;
    • уникальный hostname в пределах серверов (виртуальных машин) кластера;

    • наличие одного из пакетных менеджеров (apt/apt-get, yum или rpm).

      Важно. В РЕД ОС по умолчанию могут отсутствовать yum и which, поэтому установите их заранее;

    • установленный Python;

    • доступ до проксирующего registry или до частного хранилища образов контейнеров с образами контейнеров Deckhouse Platform;
    • при использовании частного хранилища образов необходимо предварительно загрузить образы Deckhouse Platform, БД сканера уязвимостей и модулей в частное хранилище;
    • доступ к стандартным для используемой ОС репозиториям пакетов (через прокси-сервер или до внутреннего сервера-репозитория пакетов);
    • SSH-доступ от персонального компьютера (пункт 1) по ключу;
    • сетевой доступ от персонального компьютера (пункт 1) по порту 22/TCP;
    • на узле не должно быть установлено пакетов container runtime, например containerd или Docker.

  3. Физический сервер или виртуальная машина для worker-узла.

    Требования аналогичны требованиям к master-узлу, но также зависят от характера запускаемой на узлах нагрузки.

В рекомендациях выше приведены минимальные ресурсы, необходимые для начального развёртывания кластера с одним master-узлом и одним worker-узлом. Такой конфигурации достаточно для ознакомительных целей, но для production-окружений она не подходит. Ознакомьтесь с рекомендациями по подготовке к production, рекомендациями по разметке и объёму дисков и инструкцией по выбору типов и количества узлов кластера, а также ресурсов для них, в зависимости от ваших требований к эксплуатации будущего кластера.

Вернуться назад Далее: Подготовка к установке