Available in:  CE, BE, SE, SE+, EE

The module lifecycle stage: General Availability
The module has requirements for installation

The module starts reading logs only if log-pipeline is created. Log-pipeline consists of ClusterLoggingConfig/PodLoggingConfig connected to ClusterLogDestination.

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 log-shipper 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 log-shipper

  • Using ModuleConfig log-shipper.

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

    Example of a manifest to enable module log-shipper:

    apiVersion: deckhouse.io/v1alpha1
kind: ModuleConfig
metadata:
  name: log-shipper
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 log-shipper 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 log-shipper on the “YAML” tab in the module settings window (“System” → “System Management” → “Deckhouse” → “Modules”, open the module log-shipper) 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 log-shipper (for more details on configuring Deckhouse, see the documentation) by executing the following command:

    d8 k edit mc log-shipper

    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 log-shipper 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 log-shipper:

    apiVersion: deckhouse.io/v1alpha1
kind: ModuleConfig
metadata:
  name: log-shipper
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.

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:

    Move .settings.resourcesRequests.static.cpu and .settings.resourcesRequests.static.memory to .settings.resourcesRequests.static.requests.

Parameters

Schema version: 2

  • settings
    object
    • settings.debug
      boolean
      Enable or disable agent debug logging. Default: false.

      Default: false

    • settings.nodeSelector
      object

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

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

    • settings.registry
      object

      Default: {}

      • settings.registry.dockercfg
        string
        Base64-encoded .dockerconfigjson for pulling module images. If empty, global.modulesImages.registry.dockercfg is used.
    • settings.resourcesRequests
      object

      Max amounts of CPU and memory resources that the pod can request when selecting a node.

      If the vertical-pod-autoscaler module is disabled, then these values become the default ones.

      Default: {}

      Examples: 

      mode: VPA
vpa:
  cpu:
    max: 2
    min: 50m
  memory:
    max: 2Gi
    min: 256Mi
  mode: Auto

      mode: VPA
vpa:
  cpu:
    max: 3000m
    min: 1
  memory:
    max: 4096
    min: 1024
  mode: Initial

      mode: Static
static:
  limits:
    cpu: 2
    memory: 2Gi
  requests:
    cpu: 55m
    memory: 256Mi
      • settings.resourcesRequests.mode
        string

        Required value

        Resource request management mode:

        • Static is a classic one. In it, you explicitly specify requests. The parameters of this mode are defined in the static parameter section;
        • VPA mode uses VPA. You can configure this mode by modifying parameters in the vpa parameter section.

        Default: VPA

        Allowed values: VPA, Static

      • settings.resourcesRequests.static
        object
        Resource request management options for the Static mode.

        Default: {}

        • settings.resourcesRequests.static.limits
          object
          Configuring CPU and memory limits.
          • settings.resourcesRequests.static.limits.cpu
            Configuring CPU limits.
          • settings.resourcesRequests.static.limits.memory
            Configuring memory limits.
        • settings.resourcesRequests.static.requests
          object
          Resource requests settings for pods.
          • settings.resourcesRequests.static.requests.cpu
            Configuring CPU requests.
          • settings.resourcesRequests.static.requests.memory
            Configuring memory requests.
      • settings.resourcesRequests.vpa
        object
        Resource request management options for the VPA mode.

        Default: {}

        • settings.resourcesRequests.vpa.cpu
          object

          Required value

          CPU-related parameters.

          Default: {}

          • settings.resourcesRequests.vpa.cpu.max
            The maximum value that the VPA can set for the CPU requests.

            Default: 500m

          • settings.resourcesRequests.vpa.cpu.min
            The minimum value that the VPA can set for the CPU requests.

            Default: 50m

        • settings.resourcesRequests.vpa.memory
          object

          Required value

          The amount of memory requested.

          Default: {}

          • settings.resourcesRequests.vpa.memory.max
            The maximum memory requests the VPA can set.

            Default: 2048Mi

          • settings.resourcesRequests.vpa.memory.min
            The minimum memory requests the VPA can set.

            Default: 64Mi

        • settings.resourcesRequests.vpa.mode
          string

          Required value

          The VPA usage mode.

          Default: Initial

          Allowed values: Initial, Auto

    • settings.tolerations
      array of objects

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

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

      • settings.tolerations.effect
        string
      • settings.tolerations.key
        string
      • settings.tolerations.operator
        string
      • settings.tolerations.tolerationSeconds
        integer
      • settings.tolerations.value
        string