The module lifecycle stageGeneral Availability
The module has requirements for installation

How to explicitly enable the module…

You may explicitly enable or disable the module in one of the following ways:

  • Via Deckhouse web UI. In the “System” → “System Management” → “Deckhouse” → “Modules” section, open the monitoring-kubernetes module and enable (or disable) the “Module enabled” toggle. Save changes.

    Example:

    Module enable/disable interface
  • Via Deckhouse CLI (d8).

    Use the d8 system module enable command for enabling, or d8 system module disable command for disabling the module (you need Deckhouse CLI (d8), configured to work with the cluster).

    Example of enabling the module:

    d8 system module enable monitoring-kubernetes
  • Using ModuleConfig monitoring-kubernetes.

    Set spec.enabled to true or false in ModuleConfig monitoring-kubernetes (create it if necessary);

    Example of a manifest to enable module monitoring-kubernetes:

    apiVersion: deckhouse.io/v1alpha1
    kind: ModuleConfig
    metadata:
      name: monitoring-kubernetes
    spec:
      enabled: true

How to configure the module…

You can configure the module in one of the following ways:

  • Via Deckhouse web UI.

    In the “System” → “System Management” → “Deckhouse” → “Modules” section, open the monitoring-kubernetes module and enable the “Advanced Settings” switch. Fill in the required fields in the “Configuration” tab or specify the module settings in YAML format on the “YAML” tab, excluding the settings section. Save the changes.

    Example:

    Module Setup Interface

    You can also edit the ModuleConfig object monitoring-kubernetes on the “YAML” tab in the module settings window (“System” → “System Management” → “Deckhouse” → “Modules”, open the module monitoring-kubernetes) by specifying the schema version in the spec.version parameter and the necessary module parameters in the spec.settings section.

  • Via Deckhouse CLI (d8) (requires Deckhouse CLI (d8) configured to work with the cluster).

    Edit the existing ModuleConfig monitoring-kubernetes (for more details on configuring Deckhouse, see the documentation) by executing the following command:

    d8 k edit mc monitoring-kubernetes

    Make the necessary changes in the spec.settings section. If necessary, specify the schema version in the spec.version parameter. Save the changes.

    You can also create a file with manifest for ModuleConfig monitoring-kubernetes using the example below. Fill in the spec.settings section with the required module parameters. If necessary, specify the schema version in the spec.version parameter.

    Apply the manifest using the following command (indicate the manifest file name):

    d8 k apply -f <FILENAME>

    Example of a manifest for ModuleConfig monitoring-kubernetes:

    apiVersion: deckhouse.io/v1alpha1
    kind: ModuleConfig
    metadata:
      name: monitoring-kubernetes
    spec:
      version: 2
      enabled: true
      settings: # Module parameters from the "Parameters" section below.

How to change the module release channel…

To change the module release channel, follow the instruction.

Requirements

To the Deckhouse version: 1.76.0 and above.

To the versions of other modules:

  • prometheus: any version.

Conversions

The module is configured using the ModuleConfig resource, the schema of which contains a version number. When you apply an old version of the ModuleConfig schema in a cluster, automatic transformations are performed. To manually update the ModuleConfig schema version, the following steps must be completed sequentially for each version:

  • Updates from version 1 to 2:

    If the .ebpfExporterEnabled field is set to true, add .oomKillsExporterEnabled=true. Then, delete the .ebpfExporterEnabled field from the object.

Parameters

Schema version: 2

  • settings
    object
    • settings.highAvailability
      boolean

      Manually enable the high availability mode.

      By default, Deckhouse automatically decides whether to enable the HA mode. Click here to learn more about the HA mode for modules.

      Examples:


      highAvailability: true
      
      highAvailability: false
      
    • settings.nodeSelector
      object

      The same as in the pods’ spec.nodeSelector parameter in Kubernetes.

      If the parameter is omitted or false, it will be determined automatically.

      Example:


      disktype: ssd
      
    • settings.oomKillsExporterEnabled
      boolean
      Set to ‘false’ to disable oom-kills-exporter in case it behaves incorrectly.

      Default: true

      Example:


      oomKillsExporterEnabled: false
      
    • settings.tolerations
      array of objects

      The same as in the pods’ spec.tolerations parameter in Kubernetes;

      If the parameter is omitted or false, it will be determined automatically.

      Example:


      tolerations:
      - effect: NoSchedule
        key: key1
        operator: Equal
        value: value1
      
      • settings.tolerations.effect
        string
      • settings.tolerations.key
        string
      • settings.tolerations.operator
        string
      • settings.tolerations.tolerationSeconds
        integer
      • settings.tolerations.value
        string
    • settings.vpa
      object
      VPA settings for kube-state-metrics pods.

      Default: {}

      Example:


      kubeStateMetricsMaxCPU: 130m
      kubeStateMetricsMaxMemory: 115Mi
      
      • settings.vpa.kubeStateMetricsMaxCPU
        The maximum value that the VPA can set for the CPU requests.

        Examples:


        kubeStateMetricsMaxCPU: 3
        
        kubeStateMetricsMaxCPU: 1000m
        
      • settings.vpa.kubeStateMetricsMaxMemory
        The maximum memory requests the VPA can set.

        Example:


        kubeStateMetricsMaxMemory: 3Mi