Платформу Deckhouse можно устанавливать на виртуальные машины облачных провайдеров, на bare metal-серверы, в закрытый контур и не только. В статье рассмотрим вариант установки Deckhouse в Yandex Cloud. А чтобы убедиться, что все внутренние ресурсы и компоненты работают как надо, заглянем в веб-интерфейсы платформы, в том числе Grafana и Kubernetes Dashboard.

О платформе

Deckhouse — это Open Source-решение для автоматизации обслуживания кластеров Kubernetes. В основе платформы лежат upstream-версия Kubernetes и компоненты с открытым кодом, которые признаны стандартами в cloud native-экосистеме. Платформа связывает их между собой и предоставляет всё необходимое для production-окружений, сводя к минимуму ручные манипуляции.

В Deckhouse включены такие инструменты, как CoreDNS, cert-manager, Ingress NGINX Controller, Prometheus + Grafana, dex, Istio, Cilium. С подробным списком можно ознакомиться в документации. На основе этих проектов подготовлены соответствующие модули платформы, с помощью которых пользователь может подключить и настроить необходимый инструмент. Конфигурации всех модулей интегрированы друг с другом, что позволяет отдавать на откуп Deckhouse многие рутинные задачи по администрированию кластера. Модули обновляются регулярно и автоматически.

Требования к установке

Для установки Deckhouse вам потребуются:

  • ПК с Linux (Ubuntu 18.04+, Fedora 35+), macOS 10.15+ или Windows 10+.

  • Docker (инструкции по установке: Ubuntu, macOS, Windows).

  • HTTPS-доступ к хранилищу контейнеров registry.deckhouse.io.

  • Доступ к API Yandex Cloud.

  • Учетная запись с правами на создание ресурсов.

  • Установленная и настроенная утилита Yandex Cloud (CLI).

Инсталлятор Deckhouse, запущенный на вашей машине, подключится к API Yandex Cloud и создаст один master-узел и один worker-узел. Рекомендованные минимальные характеристики узлов:

  • 4 ядра CPU;

  • 8 Гб RAM;

  • 40 Гб дискового пространства.

Поддерживаемые версии ОС для узлов:

  • РЕД ОС 7.3;

  • AlterOS 7;

  • Astra Linux Special Edition 1.7;

  • CentOS 7, 8, 9;

  • Debian 9, 10, 11;

  • Ubuntu 16.04, 18.04, 20.04, 22.04.

Подготовка Yandex Cloud и настройка Yandex Cloud CLI

Перед тем, как устанавливать Deckhouse в облако, нужно подготовить ваш аккаунт.

Если вы уже работали с облаком, и у вас есть все необходимое, этот раздел можно пропустить.

Создаем свое облако

Переходим на сайт Yandex Cloud и нажимаем на кнопку Подключиться в правом верхнем углу страницы:

Для этого нужно залогиниться в Yandex Cloud либо создать новый аккаунт, если у вас его нет.

Далее необходимо настроить вашу организацию и выбрать название для будущего облака:

Указываем необходимые данные и нажимаем Создать.

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

У одного аккаунта может быть несколько облаков, их список отображен в левой части главного экрана. Сейчас там только созданное облако.

Многие услуги Yandex Cloud платные. Поэтому к облаку должен быть подключен платежный аккаунт, о чем предупреждает всплывающее в верхней части дашборда уведомление.

Чуть ниже на главной странице — список всех сервисов, которые доступны для развертывания в облаке:

Создать любой их них можно прямо из интерфейса дашборда, нажав Создать ресурс в правом верхнем углу экрана, а также с помощью консольной утилиты Yandex Cloud (CLI):

Все необходимые действия по созданию виртуальных машин Deckhouse выполнит за вас, для этого он использует CLI Yandex Cloud. Для нее необходимо настроить доступ в новое облако.

Установка и настройка Yandex Cloud (CLI)

Установите утилиту по официальной инструкции.

Все описываемые команды актуальны для UNIX-подобных операционных систем, в частности для macOS Monterey. Для Windows команды могут немного отличаться (они упомянуты в Getting Started Deckhouse).

Далее нужно получить токен авторизации в вашем аккаунте. Для этого перейдите по ссылке (при этом нужно быть авторизованным в браузере в вашем облаке). На открывшейся странице будет только одна строка — ваш токен:

Токен для доступа в облако
Токен для доступа в облако

Запишите его или оставьте страницу открытой.

Выполните команду yc init и введите полученный ранее токен:

Please go to https://oauth.yandex.ru/authorize?response_type=token&client_id=1a6990aa636648e9b2ef855fa7bec2fb
 in order to obtain OAuth token.

Please enter OAuth token: AaAaBbBbCcCcDdDdEeEeFfFfGgGg

Теперь нужно выбрать облако, с которым будете работать:

Please select cloud to use:
 [1] cloud1 (id = aoe2bmdcvatao4frg22b)
 [2] cloud2 (id = dcvatao4faoe2bmrg22b)
Please enter your numeric choice: 2

И затем — каталог:

Please choose a folder to use:
 [1] folder1 (id = cvatao4faoe2bmdrg22b)
 [2] folder2 (id = tao4faoe2cvabmdrg22b)
 [3] Create a new folder
Please enter your numeric choice: 1

Далее нужно указать зону доступности; здесь можно выбрать вариант 4:

Do you want to configure a default Yandex Compute Cloud availability zone? [Y/n] Y
Which zone do you want to use as a profile default?
 [1] ru-central1-a
 [2] ru-central1-b
 [3] ru-central1-c
 [4] Don't set default zone
Please enter your numeric choice: 4

Проверьте, что все настроено как нужно, с помощью команды:

$ yc config list
token: AaAaBbBbCcCcDdDdEeEeFfFfGgGg
cloud-id: b1g159pa15cddlv5mvcr
folder-id: b1g8o9jbt587mbadu25k

Утилита установлена и готова к работе с вашим облаком.

После того, как облако создано и доступ к нему настроен, можно переходить к установке Deckhouse.

Установка Deckhouse

Для развертывания кластера будет использоваться схема размещения узлов в облаке без использования NAT. В этой схеме IP-адреса всех машин в кластере публичные и свободно доступны из интернета.

Схема размещения будущего кластера в облаке без использования NAT
Схема размещения будущего кластера в облаке без использования NAT

Подробную информацию о возможностях работы с Yandex Cloud можно получить в документации к модулю cloud-provider-yandex.

Подготовка окружения

Для того, чтобы Deckhouse смог работать с облаком, необходимо создать сервисный аккаунт с правами на редактирование.

Сделать это можно как средствами админки Yandex Cloud, так и из консоли. Мы пойдем вторым путем:

$ yc iam service-account create --name habr
id: <userID>
folder_id: <folderID>
created_at: "YYYY-MM-DDTHH:MM:SSZ"
name: habr

Здесь мы создаем нового пользователя с именем habr. В ответ нам возвращаются его параметры: ID пользователя, ID доступного каталога, дата и время создания, а также имя.

Убедиться, что все прошло как нужно, можно в панели управления, перейдя во вкладку Сервисные аккаунты. В таблице должен появиться новый пользователь:

Далее выдадим новому пользователю права с ролью editor:

$ yc resource-manager folder add-access-binding <folderID> --role editor --subject serviceAccount:<userID>
done (1s)

Новая роль также появится в панели:

Новая роль пользователя
Новая роль пользователя

Теперь создадим JSON-файл с параметрами авторизации, который в дальнейшем будет использоваться для входа в облако:

$ yc iam key create --service-account-name habr --output deckhouse-sa-key.json

Файл создан. Теперь можно устанавливать Deckhouse!

Установка

Переходим на следующую страницу «Быстрого старта».

Выбор версии платформы

Здесь нужно выбрать Community-(CE) или Enterprise-версию (EE) Deckhouse. Их отличия:

Enterprise-версия доступна только при наличии лицензионного ключа*. Мы рассмотрим пример с бесплатной CE-редакцией. Поэтому оставляем выбор по умолчанию:

* Примечание

Чтобы оценить всю функциональность Deckhouse, можно протестировать Enterprise-версию в триальном режиме в течение 30 дней.

Генерация конфигурационных файлов

Теперь необходимо сгенерировать два файла с настройками, которые будут использоваться для развертывания кластера:

  • config.yml — файл первичной конфигурации кластера. Содержит параметры инсталлятора, параметры доступа облачного провайдера и начальные параметры кластера.

  • resources.yml — настройки узлов и Ingress-контроллера.

Рассмотрим их подробнее. Файл config.yml:

# Секция с общими параметрами кластера.
# https://deckhouse.ru/documentation/v1/installing/configuration.html#clusterconfiguration
apiVersion: deckhouse.io/v1
kind: ClusterConfiguration
clusterType: Cloud
cloud:
  provider: Yandex
  # Префикс объектов, создаваемых в облаке при установке.
  prefix: cloud-demo
# Адресное пространство Pod'ов кластера.
podSubnetCIDR: 10.111.0.0/16
# Адресное пространство для service'ов кластера.
serviceSubnetCIDR: 10.222.0.0/16
kubernetesVersion: "1.23"
clusterDomain: "cluster.local"
---
# Секция первичной инициализации кластера Deckhouse.
# https://deckhouse.ru/documentation/v1/installing/configuration.html#initconfiguration
apiVersion: deckhouse.io/v1
kind: InitConfiguration
deckhouse:
  releaseChannel: Stable
  configOverrides:
    global:
      modules:
        # Шаблон, который будет использоваться для составления адресов системных приложений в кластере.
        # Например, Grafana для %s.example.com будет доступна на домене 'grafana.example.com'.
        # Можете изменить на свой сразу, либо следовать шагам руководства и сменить его после установки.
        publicDomainTemplate: "%s.example.com"
    userAuthn:
      controlPlaneConfigurator:
        dexCAMode: DoNotNeed
      publishAPI:
        enable: true
        https:
          mode: Global
---
# Секция, описывающая параметры облачного провайдера.
# https://deckhouse.io/documentation/v1/modules/030-cloud-provider-yandex/cluster_configuration.html
apiVersion: deckhouse.io/v1
kind: YandexClusterConfiguration
layout: WithoutNAT
# Параметры доступа к облаку Yandex Cloud.
provider:
  # ID облака.
  cloudID: *!CHANGE_CloudID*
  # ID каталога.
  folderID: *!CHANGE_FolderID*
  # JSON-ключ, сгенерированный с помощью `yc iam key create` на предыдущем шаге.
  # Пример заполнения serviceAccountJSON:
  # serviceAccountJSON: |
  #    {
  #      "id": "...",
  #      "service_account_id": "...",
  #      "created_at": "2022-08-04T05:38:34.756137618Z",
  #      "key_algorithm": "RSA_2048",
  #      "public_key": "-----BEGIN PUBLIC KEY-----...-----END PUBLIC KEY-----\n",
  #      "private_key": "-----BEGIN PRIVATE KEY-----...-----END PRIVATE KEY-----\n"
  #    }
  serviceAccountJSON: *!CHANGE_ServiceAccountJSON*
masterNodeGroup:
  replicas: 1
  instanceClass:
    cores: 4
    memory: 8192
    # ID образа в Yandex Cloud. Рекомендуется использовать актуальную сборку Ubuntu 22.04 LTS.
    # Для получения можете воспользоваться командой:
    # yc compute image list --folder-id standard-images --format json | jq -r '[.[] | select(.family == "ubuntu-2204-lts")] | sort_by(.created_at)[-1].id'
    imageID: fd864gbboths76r8gm5f
    externalIPAddresses:
    - "Auto"
# Данная подсеть будет разделена на три равных части и использована для создания подсетей в трёх зонах Yandex Cloud.
nodeNetworkCIDR: "10.241.32.0/20"
# Публичная часть SSH-ключа для доступа к узлам облака.
# Этот ключ будет добавлен пользователю на созданных узлах (имя пользователя зависит от используемого образа).
sshPublicKey: *!CHANGE_SSH_KEY*

Здесь нужно обратить внимание на поля cloudID, folderID, serviceAccountJSON и sshPublicKey. Введите туда нужные данные и сохраните файл вместе с уже сгенерированным JSON-файлом с конфигурацией доступа в Yandex Cloud (удобнее всего это сделать в отдельном каталоге).

Получить значения cloudID и folderID можно командой yc config list, а содержимое публичной части вашего SSH-ключа — командой cat ~/.ssh/id_rsa.pub.

Файл resources.yml:

apiVersion: deckhouse.io/v1
kind: NodeGroup
metadata:
  name: worker
spec:
  cloudInstances:
    classReference:
      kind: YandexInstanceClass
      name: worker
    maxPerZone: 1
    minPerZone: 1
    # Можно изменить
    zones:
    - ru-central1-a
  disruptions:
    approvalMode: Automatic
  nodeTemplate:
    labels:
      node.deckhouse.io/group: worker
  nodeType: CloudEphemeral
---
apiVersion: deckhouse.io/v1
kind: YandexInstanceClass
metadata:
  name: worker
spec:
  # Можно изменить
  cores: 4
  # Можно изменить
  memory: 8192
  # Можно изменить
  diskSizeGB: 30
---
apiVersion: deckhouse.io/v1
kind: IngressNginxController
metadata:
  name: nginx
spec:
  # Имя Ingress-класса для использования Ingress Nginx controller
  ingressClass: nginx
  # способ поступления трафика из внешнего мира
  inlet: LoadBalancer
  # Описывает, на каких узлах будет находиться компонент. Лейбл node.deckhouse.io/group: <NODE_GROUP_NAME> устанавливается автоматически.
  nodeSelector:
    node.deckhouse.io/group: worker
---
apiVersion: deckhouse.io/v1
kind: ClusterAuthorizationRule
metadata:
  name: admin
spec:
  # Список учётных записей Kubernetes RBAC
  subjects:
  - kind: User
    name: admin@deckhouse.io
  # Предустановленный шаблон уровня доступа
  accessLevel: SuperAdmin
  # Разрешить пользователю делать kubectl port-forward
  portForwarding: true
---
apiVersion: deckhouse.io/v1
kind: User
metadata:
  name: admin
spec:
  email: admin@deckhouse.io
  # Это хэш сгенерированного пароля vwhnw62bio
  # Сгенерируйте свой или используйте этот, но только для тестирования
  # echo "vwhnw62bio" | htpasswd -BinC 10 "" | cut -d: -f2
  # Можно изменить
  password: '$2a$10$QZ/5WOgdoiqr9f0GG4q3oOcODjwqcCxvWdJnJX.I/L3LhJUeLDBU.'

В последней строке необходимо указать хэш пароля, который вы хотите использовать для доступа в кластер. Для этого нужно придумать сам пароль, а затем сгенерировать его хэш-сумму. 

Сгенерировать новый пароль можно любым удобным способом — например, так:

$ openssl rand 14 -base64
QIAbnGxzzDZDGxbxdAc=

Теперь посчитаем его хэш-сумму:

$ echo "QIAbnGxzzDZDGxbxdAc=" | htpasswd -BinC 10 "" | cut -d: -f2
$2y$10$VPpfbWGk5L34NkXy7wFtbO9YIbQt0UifkYPowkx0VOeJp23qlmFga

Вставляем хэш созданного пароля в поле password, затем сохраняем файл с нужным именем и помещаем рядом с предыдущими двумя файлами:

$ tree .
.
├── config.yml
├── deckhouse-sa-key.json
└── resources.yml

Развертывание в Yandex Cloud

Для установки Deckhouse Platform используется Docker-образ, в который необходимо передать конфигурационные файлы и SSH-ключи доступа на master-узел.

Чтобы запустить установку, нужно выполнить команду из каталога с конфигурационными файлами:

docker run --pull=always -it -v "$PWD/config.yml:/config.yml" -v "$HOME/.ssh/:/tmp/.ssh/" \
  -v "$PWD/resources.yml:/resources.yml" -v "$PWD/dhctl-tmp:/tmp/dhctl" registry.deckhouse.io/deckhouse/ce/install:stable bash

После того, как образ будет выкачан, откроется приглашение для работы внутри контейнера:

213ec9aee27d: Already exists
7699c8f5da30: Pull complete
d408eafd71b1: Pull complete
e79ec47abd43: Pull complete
dbe384732cbc: Pull complete
5d67ae3b7d74: Pull complete
a1bbf50e3ae0: Pull complete
Digest: sha256:014279df55f931f519d642eba4eed3ed02f3bdf4f81e6dd7a571bee353566042
Status: Downloaded newer image for registry.deckhouse.io/deckhouse/ce/install:stable
WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested
[deckhouse] root@ee5907591d42 / #

Выполните команду:

dhctl bootstrap --ssh-user=ubuntu --ssh-agent-private-keys=/tmp/.ssh/id_rsa --config=/config.yml --resources=/resources.yml

После этого запустится процесс развертывания кластера в облаке, который займет около 15 минут.

В команде выше в параметре --ssh-user указывается имя пользователя для входа по SSH на создаваемые узлы. Оно должно соответствовать образу, который указан в config.yaml (ID образа). Для выбранного нами образа это пользователь ubuntu.

В процессе установки в терминале будет отображаться полный лог всего, что происходит. В нем могут встречаться сообщения о warning'ах и error'ах, которые возникают из-за ожидания развертывания ресурсов на машинах. Это нормально, и не означает, что все сломалось.

Завершится процесс установки новым приглашением ввести команду внутри контейнера. Также будет показан адрес master-узла, куда можно постучаться по SSH, чтобы попасть на созданную ВМ:

┌ ???? ~ Common: Kubernetes Master Node addresses for SSH
│ habr-demo-master-0 | ssh ubuntu@xx.xxx.xxx.x
└ ???? ~ Common: Kubernetes Master Node addresses for SSH (0.00 seconds)

Обратите внимание, что в каталоге, в котором хранятся созданные файлы конфигурации, появился каталог dhctl-tmp. Это временный каталог, в котором инсталлятор будет хранить состояние данных Terraform. Если вы по какой-то причине установку прервалась (проблемы с сетью, нехватка квот), просто перезапустите команду установки. Инсталлятор не создаст «дублирующих» объектов и продолжит процесс с прерванного места**.

** Если что-то пошло не так

Если вы не можете продолжить установку и хотите очистить облако от созданных объектов, выполните команду в контейнере инсталлятора:

dhctl bootstrap-phase abort --ssh-user=ubuntu --ssh-agent-private-keys=/tmp/.ssh/id_rsa --config=/config.yml

Две созданные ВМ можно увидеть в дашборде Yandex Cloud. Для этого перейдите в раздел Compute Cloud / Виртуальные машины:

Итак, Deckhouse развернут. Осталось получить доступ к кластеру.

Получение доступа к кластеру

В завершении установки инсталлятор показал IP-адрес master-узла. Можно подключиться к нему по SSH:

ssh ubuntu@<MASTER_IP>

Подключение должно выполниться сразу, так как публичная часть вашего SSH-ключа уже добавлена на все созданные узлы. Теперь на master-узле можно выполнять различные действия с кластером:

$ sudo -i
root@habr-demo-master-0:~# kubectl get nodes
NAME                                    STATUS   ROLES                  AGE    VERSION
habr-demo-master-0                      Ready    control-plane,master   117m   v1.23.9
habr-demo-worker-d321e7c6-74bb7-hvfwh   Ready    worker                 105m   v1.23.9

Настройка доступа через Ingress

Во время установки кластера был создан и настроен Ingress-контроллер. Он позволяет получать доступ к веб-интерфейсам Deckhouse: Grafana, Prometheus, Dashboard и так далее. LoadBalancer тоже уже готов, поэтому остается только направить на него доменные имена. Для этого необходимо настроить работу DNS и указать в параметрах Deckhouse шаблон DNS-имен. 

Шаблон DNS-имен используется для настройки Ingress-ресурсов системных приложений. Например, имя grafana соответствует сервису Grafana. Поэтому для шаблона %s.kube.company.my Grafana будет доступна по адресу grafana.kube.company.my, и т. д.

Для настройки доменных имен будет использован сервис sslip.io. Чтобы получить IP-адрес балансировщика и автоматически настроить доступ через sslip.io, выполните команду на master-узле:

BALANCER_IP=$(sudo kubectl -n d8-ingress-nginx get svc nginx-load-balancer -o json | jq -r '.status.loadBalancer.ingress[0].ip') && \
echo "Balancer IP is '${BALANCER_IP}'." && sudo kubectl patch mc global --type merge \
  -p "{\"spec\": {\"settings\":{\"modules\":{\"publicDomainTemplate\":\"%s.${BALANCER_IP}.sslip.io\"}}}}" && echo && \
echo "Domain template is '$(sudo kubectl get mc global -o=jsonpath='{.spec.settings.modules.publicDomainTemplate}')'."

Полученный шаблон DNS-имен будет отображен после выполнения команды:

Balancer IP is '1.2.3.4'.
moduleconfig.deckhouse.io/global patched

Domain template is '%s.1.2.3.4.sslip.io'.

Также можно настроить доступ с использованием существующего доменного имени, к регистрации поддоменов которого у вас есть доступ, или с использованием файла /etc/hosts. Подробнее об этом можно прочитать в Getting Started.

Настройка доступа kubectl с локальной машины

Работать с кластером напрямую с master-узла из-под root-пользователя небезопасно. Поэтому рекомендуется настроить внешний доступ к нему с помощью kubectl на локальной машине.

Для этого войдите в веб-интерфейс Kube Configurator; его адрес соответствует шаблону https://kubeconfig.1.2.3.4.sslip.io. Логин — admin@deckhouse.io, пароль — w1ekkzbccr (если вы не меняли его в конфигурационных файлах).

Интерфейс настройки доступа kubectl
Интерфейс настройки доступа kubectl

Выберите нужную ОС и следуйте дальнейшим инструкциям.

Чтобы убедиться, что все получилось, выполните команду на вашей машине:

$ kubectl get no
NAME                                    STATUS   ROLES                  AGE   VERSION
habr-demo-master-0                      Ready    control-plane,master   38m   v1.23.9
habr-demo-worker-a32e16ee-5dcbd-sttgd   Ready    worker                 25m   v1.23.9

Если вы видите список узлов развернутого кластера — доступ настроен. Кластер развернут.

Обзор веб-интерфейсов Deckhouse

Deckhouse предоставляет несколько полезных веб-интерфейсов в составе кластера — для доступа к документации, мониторингу, Kubernetes Dashboard и контроля состояния кластера. По умолчанию доступ ко всем компонентам организован с помощью Dex, через статического пользователя, созданного в кластере во время установки.

Встроенная документация

В кластер добавлен сервис, который позволяет получить доступ ко всей актуальной документации Deckhouse. Находится она по адресу https://deckhouse.1.2.3.4.sslip.io. Логин — admin@deckhouse.io, пароль — w1ekkzbccr (если вы не меняли его в конфигурационных файлах).

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

Мониторинг с помощью Grafana

Дашборды Grafana доступны по адресу grafana. На главной странице можно увидеть общую информацию о развернутом кластере, а также ссылки на другие встроенные веб-интерфейсы:

Для мониторинга ресурсов можно перейти по соответствующим ссылкам. Например, вот так выглядит мониторинг Ingress Nginx Controller'а:

Для доступа к Prometheus напрямую можно перейти по ссылке /prometheus (либо прямо из интерфейса главной страницы Grafana):

Kubernetes Dashboard

Kubernetes Dashboard доступен по адресу dashboard. Здесь собрана информация обо всех сущностях кластера и их состоянии:

Просмотр состояния кластера

Состояние кластера и его компонентов можно посмотреть на странице, доступной по адресу status:

Удаление развернутого кластера

Если вы хотите удалить развернутый в облаке кластер, простого удаления созданных виртуальных машин будет недостаточно.

Запустите установочный образ Deckhouse, пробросив ему свой ключ SSH:

docker run --pull=always -it -v "$HOME/.ssh/:/root/.ssh/" registry.deckhouse.io/deckhouse/ce/install:stable bash

Внутри образа выполните команду:

dhctl destroy --ssh-host <MASTER-IP> --ssh-user <USER>

Удаление может занять от 5 до 10 минут. В результате будут удалены все компоненты Deckhouse и сами виртуальные машины, развернутые в облаке на момент установки.

Заключение

Мы пошагово рассмотрели, как создать новое облако в Yandex Cloud и развернуть в нем Kubernetes-кластер под управлением платформы Deckhouse. 

Эта статья основана на материалах раздела «Getting Started» на сайте Deckhouse. Более подробную информацию о настройке развернутого кластера можно получить в официальной документации (как на сайте, так и внутри развернутого кластера), где в соответствующих разделах собраны все необходимые инструкции по настройке компонентов кластера.

С любыми вопросами и предложениями ждем вас в комментариях к статье, а также в Telegram-чате deckhouse_ru, где всегда готовы помочь. Будем рады issues (и, конечно, звёздам) в GitHub-репозитории Deckhouse.

P.S.

Читайте также в нашем блоге:

Комментарии (10)


  1. dexec
    30.12.2022 16:03
    +5

    Спасибо за гайд. Заинтересовала функциональность мониторинга:
    1) идет ли он по умолчанию или это дополнительная услуга?
    2) правильно ли я понимаю что все дашборды для мониторинга k8s уже настроены?
    3) как долго храняться метрики?


    1. zimmermann
      30.12.2022 16:12
      +3

      Мониторинг входит и в Commuinty Edition и в данном руководстве модули мониторинга также включены по умолчанию (сравнение редакций по модулям). Все дашборды уже тоже настроены, да. Но можете докинуть своих.

      Настройка retention в модуле prometheus:


  1. Fitrager
    30.12.2022 17:06
    +2

    Prometheus Stack ставиться через helm одной командой и включает в себя Grafana. Мониторинг из коробки для ванильного кубера.

    Что такое "мгновенное автомасштабирование" у Deckhouse? Horizontal Pod Autoscaler?

    Ingress у Deckhouse работает через HostNetwork?


    1. n_bogdanov
      30.12.2022 17:26
      +4

      Есть такое понятие - цельность инструмента. Тут именно про это история. Есть центральный модуль для входа, автопровизионинг dashboards. Соответственно модули установлены с определённым списком настроек, которые спускаются сверху-вниз.

      То, что это реально сделать самому - спору нет. Однако зачем, если есть готовое?

      Опять же, никто не запрещает использовать лишь часть инструментов, установив остальные самостоятельно.


  1. CrzyDocTI
    30.12.2022 23:36

    пока deckhouse не идемпотентен - нет смысла рассматривать сколько у него красивостей - полетит одна и перекатывай все машины с нуля чтобы починить кластер. ставится только на чистую машину


    1. zimmermann
      31.12.2022 14:40

      Возможно у вас был какой-то неудачный опыт? Поделитесь?

      А можете подробнее про проблемы с идемпотентностью в Deckhousе? В каком-то случае вам ее не хватило? Сейчас (начиная с версии 1.41) даже конфигурация вся может лежать в гите в виде ресурсов.

      По поводу установки - установка возможна не обязательно на чистую машину. Можно установить также в существующем кластере какого-либо managed-решения или обычном существующем кластере. В managed-кластерах буду некоторые ограничения, т.к. не доступно управление control-plane, но в остальном никаких отличий. Вы можете довольно легко перебраться с Deckhouse из managed-решения к другому провайдеру или вообще на bare metal с air gap-окружением.


      1. CrzyDocTI
        31.12.2022 16:34
        +1

        тестировал в июле. выбирал какой из вариантов управления кластера развивать далее в закрытых инфраструктурах.

        по итогам - на машину которую ранее использовал в кластере(сделал reset node и все) ничего не встало. человек который общался с представителями deckhouse и собственно предложил его использование сказал что необходима чистая виртуалка...

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

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

        это пожалуй два основных фактора - не идемпотентен + не прозрачен. на данный момент раскатываю кластер ansible скриптами - тоже не идеально, но там я хотя бы пожертвовав бессонной ночью могу все запустить(а вот вы сказали что REDOS не поддерживаете, а мне понадобилось и поставил поправив пару скриптов).


        1. zimmermann
          01.01.2023 10:36
          +1

          Спасибо за резвернутый ответ.
          Deckhouse постоянно развивается. Например сейчас поддерживается работа с РЭД ОС, AlterOS и Астрой, и список будет пополняться.
          Будем рады если как-нибудь попробуете еще разок.

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

          Спасибо за фидбэк!


          1. CrzyDocTI
            01.01.2023 15:52

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


            1. CrzyDocTI
              01.01.2023 22:12

              если это соответствует действительности - нет, не попробую еще раз...