Deckhouse Kubernetes Platform в закрытом окружении

Доступно в редакциях SE, SE+, EE, CSE Lite, CSE Pro.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    • поддержка CgroupsV2;
    • systemd версии 244;
    • поддержка модуля ядра erofs.

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

    • не менее 4 ядер CPU;
    • не менее 8 ГБ RAM;
    • не менее 60 ГБ дискового пространства на быстром диске (400+ IOPS);
    • поддерживаемая ОС;
    • ядро Linux версии 5.8 или новее;
    • уникальный hostname в пределах серверов (виртуальных машин) кластера;
    • наличие одного из пакетных менеджеров (apt/apt-get, yum или rpm).

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

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

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

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

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