The module lifecycle stage: Generally available version

The module has requirements for installation

Deckhouse Kubernetes Platform requirements

To ensure stable operation of the Deckhouse Observability Platform, the cluster Deckhouse Kubernetes Platform must have the following minimum configuration:

  • Number of master nodes — 3;
  • Number of Ingress nodes — 2;
  • Number of system nodes — 3;
  • Number of worker nodes — 3.

The cni-cilium module must be enabled in the cluster, with the tunnel mode set to VXLAN (parameter tunnelMode).

We recommend using the Stable update channel for the Deckhouse Kubernetes Platform.

Hardware Requirements

The following hardware resources and configurations are necessary for proper operation:

  • 10 Gbps Network between nodes hosting long-term storage;
  • 1 Gbps Network between all other hosts;
  • SSD Disks on all servers.

SSL Certificate Requirements

The Deckhouse Observability Platform requires the use of SSL certificates for secure data exchange. It is recommended to use Let’s Encrypt certificates. If Let’s Encrypt cannot be used, a wildcard certificate for the domain and subdomains is necessary.

The certificate must list the domain names below as DNS names in its Subject Alternative Name (SAN) extension. Specifying a Common Name is not required.

Example of alternative names (SAN) in a wildcard certificate (example for the domain dop.example.com):

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

If using a wildcard SSL certificate is not possible, use the following alternative names in the SSL certificate:

  • dop.example.com — main domain;
  • api.dop.example.com — domain for API;
  • update.dop.example.com — domain for agent updates;
  • logs.dop.example.com — domain for logs;
  • collector.dop.example.com — domain for metrics;
  • s3.dop.example.com — domain for S3 storage;
  • registry.dop.example.com — domain for the built-in Docker Registry, needed only when monitoring.dockerRegistry.enabled is true, general.clusterBaseDomain is not set, and monitoring.customDomain.baseDomain is not set.

A cluster domain name, if configured, is checked independently of the main domain: the wildcard or the names issued for the main domain do not cover it. The certificate must additionally list either the cluster domain and its own wildcard, or the cluster domain and its own copy of the same subdomains. The cluster domain name is set in the general.clusterBaseDomain parameter and is used to distinguish between clusters in multi-cluster environments. For example, with clusterBaseDomain: dc1.dop.example.com, the certificate must also contain either dc1.dop.example.com and *.dc1.dop.example.com, or dc1.dop.example.com, api.dc1.dop.example.com, update.dc1.dop.example.com, logs.dc1.dop.example.com, collector.dc1.dop.example.com, and s3.dc1.dop.example.com.

When a cluster domain name is set, the module serves the built-in Docker Registry on the cluster domain instead of the main domain, so the main domain needs no registry name at all. If the certificate for the cluster domain is assembled from the explicit names above rather than from a wildcard pair, add registry.dc1.dop.example.com to it as well — again, only when monitoring.dockerRegistry.enabled is true and monitoring.customDomain.baseDomain is not set.

If the certificate does not cover a required domain, the module fails to start with an Error validating TLS-certificate: ... error. The registry name is not checked by this validation — if it’s missing, the module starts, but HTTPS on the built-in Docker Registry will not work.

Resource Calculation

Standard Resources for Deckhouse Observability Platform

The number of servers and required hardware resources are determined individually for each case. Approximate system requirements for different levels of load and data volumes, for nodes where Deckhouse Observability Platform components will be deployed.

Metrics per Minute Number of Hosts Storage Period RAM vCPU SSD
500,000 < 10-15 1 month 96 GB 24 0.7 TB
5,000,000 < 50-100 3 months 264 GB 32 3 TB
10,000,000 < 300-1000 365 days 448 GB 55 8 TB
25,000,000 < 300-1000 365 days 1024 GB 107 21 TB
100,000,000 < 2000-10,000 365 days 5.5 TB 803 87 TB

Notes:

  • Metrics per Minute — approximate number of unique metrics collected every minute.
  • Number of Hosts — number of servers from which monitoring data is collected.
  • Storage Period — the period for which monitoring data is retained.
  • RAM, vCPU, SSD — total resources required for the system to operate in fault-tolerant mode.

The table does not include resources needed to deploy the Deckhouse Kubernetes Platform. For information on resources for Master Nodes, Ingress Nodes and System Nodes, refer to the corresponding section of the documentation.