Стадия жизненного цикла модуля: Общедоступная версия

У модуля есть требования для установки

Требования к Deckhouse Kubernetes Platform

Чтобы обеспечить стабильную работу Deckhouse Observability Platform, кластер Deckhouse Kubernetes Platform должен иметь следующую минимальную конфигурацию:

  • Количество master-узлов — 3.
  • Количество Ingress-узлов — 2.
  • Количество system-узлов — 3.
  • Количество worker-узлов — 3.

В кластере должен быть включен модуль cni-cilium, с режимом работы туннеля VXLAN (параметр tunnelMode).

Рекомендуем использовать канал обновлений Stable для Deckhouse Kubernetes Platform.

Аппаратные требования

Для обеспечения корректной работы необходимы следующие аппаратные ресурсы и конфигурации:

  • 10-гигабитная сеть между узлами, на которых расположено долгосрочное хранилище;
  • Гигабитная сеть между всеми остальными узлами;
  • SSD-диски на всех узлах.

Требования к SSL-сертификатам

Deckhouse Observability Platform требует использования SSL-сертификатов для безопасного обмена данными. Рекомендуется использовать сертификаты Let’s Encrypt. В случае невозможности использования сертификатов Let’s Encrypt, необходимо использовать wildcard-сертификат для домена и поддоменов.

Сертификат должен содержать перечисленные ниже домены как DNS-имена в расширении Subject Alternative Name (SAN). Указывать Common Name не обязательно.

Пример альтернативных имён (SAN) в wildcard-сертификате (пример для домена dop.example.com):

  • *.dop.example.com;
  • dop.example.com.

Если использование wildcard-сертификата невозможно, в SSL-сертификате необходимо использовать следующие альтернативные имена:

  • dop.example.com — основной домен;
  • api.dop.example.com — домен для API;
  • update.dop.example.com — домен для обновлений агентов;
  • logs.dop.example.com — домен для логов;
  • collector.dop.example.com — домен для метрик;
  • s3.dop.example.com — домен для S3-хранилища;
  • registry.dop.example.com — домен встроенного Docker Registry, нужен только если включён monitoring.dockerRegistry.enabled, не задан general.clusterBaseDomain и не задан monitoring.customDomain.baseDomain.

Доменное имя кластера, если оно задано, проверяется независимо от основного домена: wildcard-запись или имена, выпущенные для основного домена, его не покрывают. В сертификате нужно дополнительно указать либо доменное имя кластера и его собственную wildcard-запись, либо доменное имя кластера и его собственный набор тех же поддоменов. Доменное имя кластера, используемое для распознавания кластеров в катастрофоустойчивом режиме, задаётся параметром general.clusterBaseDomain. Например, для clusterBaseDomain: dc1.dop.example.com в сертификате дополнительно должны быть либо dc1.dop.example.com и *.dc1.dop.example.com, либо dc1.dop.example.com, api.dc1.dop.example.com, update.dc1.dop.example.com, logs.dc1.dop.example.com, collector.dc1.dop.example.com и s3.dc1.dop.example.com.

Когда доменное имя кластера задано, модуль обслуживает встроенный Docker Registry на нём, а не на основном домене, поэтому на основном домене имя registry не нужно вовсе. Если сертификат для доменного имени кластера собран из перечисленных выше имён, а не из wildcard-пары, добавьте в него и registry.dc1.dop.example.com — и снова только если включён monitoring.dockerRegistry.enabled и не задан monitoring.customDomain.baseDomain.

Если сертификат не покрывает требуемый домен, модуль не запускается с ошибкой Error validating TLS-certificate: .... Имя registry этой валидацией не проверяется — при его отсутствии модуль запустится, но HTTPS на встроенном Docker Registry работать не будет.

Расчёт необходимых ресурсов

Стандартные ресурсы для Deckhouse Observability Platform

Количество серверов и требуемые аппаратные ресурсы уточняются индивидуально для каждого случая.

Ориентировочные системные требования для различных уровней нагрузки и объёмов данных для узлов, на которых будут размещены компоненты Deckhouse Observability Platform:

Количество метрик в минуту Количество хостов Период хранения RAM vCPU SSD
500 000 < 10–15 1 месяц 96 ГБ 24 0,7 ТБ
5 000 000 < 50–100 3 месяца 264 ГБ 32 3 ТБ
10 000 000 < 300–1000 365 дней 448 ГБ 55 8 ТБ
25 000 000 < 300–1000 365 дней 1024 ГБ 107 21 ТБ
100 000 000 < 2000–10 000 365 дней 5,5 ТБ 803 87 ТБ

Здесь:

  • количество метрик в минуту — примерное количество уникальных метрик, собираемых каждую минуту;
  • количество хостов — количество серверов, с которых осуществляется сбор мониторинговых данных;
  • период хранения — период хранения мониторинговых данных;
  • RAM, vCPU, SSD — суммарное количество ресурсов для работы системы в режиме отказоустойчивости.

Таблица не включает ресурсы, необходимые для развёртывания Deckhouse Kubernetes Platform. Для получения информации о ресурсах для master-узлов, Ingress-узлов и system-узлов обратитесь к соответствующему разделу документации.