Sysdig Documentation

Advanced Installer Options

Use hostPath for Static Storage of Sysdig Components

As described in the Prerequisites , the Installer assumes usage of a dynamic storage provider (AWS or GKE). In case these are not used in your environment, add the entries below to the values.yaml to configure static storage.

Based on the size entered in the values.yaml file (small/medium/large), the Installer assumes a minimum number of replicas and nodes to be provided. You will enter the names of the nodes on which you will run the Cassandra, ElasticSearch, mySQL and Postgres components of Sysdig in the values.yaml, as in the parameters and example below.

Parameters
  • storageClassProvisioner:hostPath.

  • sysdig.cassandra.hostPathNodes: The number of nodes configured here needs to be at minimum 1 when configured size is small, 3 when configured size is medium and 6 when configured size is large.

  • elasticsearch.hostPathNodes: The number of nodes configured here needs to be at minimum 1 when configured size is small, 3 when configured size is medium and 6 when configured size is large.

  • sysdig.mysql.hostPathNodes: When sysdig.mysqlHA is configured to true, this must be at least 3 nodes. When sysdig.mysqlHA is not configured, it should be at least 1 node.

  • sysdig.postgresql.hostPathNodes: This can be ignored if Sysdig Secure is not licensed or used in this environment. If Secure is used, then the parameter should be set to 1, regardless of the size setting

Example

storageClassProvisioner: hostPath
elasticsearch:
  hostPathNodes:
    - my-cool-host1.com
    - my-cool-host2.com
    - my-cool-host3.com
    - my-cool-host4.com
    - my-cool-host5.com
    - my-cool-host6.com
sysdig:
  cassandra:
    hostPathNodes:
      - my-cool-host1.com
      - my-cool-host2.com
      - my-cool-host3.com
      - my-cool-host4.com
      - my-cool-host5.com
      - my-cool-host6.com
  mysql:
    hostPathNodes:
      - my-cool-host1.com
  postgresql:
    hostPathNodes:
      - my-cool-host1.com

Patching

Patching can be used to customize or “tweak” the default behavior of the Installer to accommodate the unique requirements of a specific environment. Use patching to modify the parameters that are not exposed by thevalues.yaml. Refer to the configuration_parameters.md for more detail about various parameters.  

The most common use case for patching is during upgrades. When generating the differences between an existing installation and the upgrade, you may see previously customized configurations that the upgrade would overwrite, but that you want to preserve.

Patching Process

If you have run  generate diff  and found a configuration that you need to tweak (e.g. the installer will delete something you want to keep, or you need to add something that isn't there), then follow these general steps:

  • Create an overlays directory in the same location as the values.yaml.

    Note

    This directory, and the PATCH.yaml you create for it, must be kept. The installer will use it during future upgrades of Sysdig.

  • Create a .yaml file to be used for patching. You can name it whatever you want; we will call it PATCH.yaml for this example.

    Patch files must include, at a minimum:

    • apiVersion

    • kind

    • metadata.name

    of the object to be patched.

    Then you add the specific configuration required for your needs. See one example below.

    You will need this patch definition for every Kubernetes object you want to patch.

  • Run generate diff again and check that the outcome will be what you want.

  • When satisfied, complete the update by changing the scripts value to deploy and running the installer (see v2.5.0+ Upgrade (Installer: Kubernetes).

If you want to add another patch, you can either add a separate .yaml file or a new YAML document separated by ---

The recommended practice is to use a single patch per Kubernetes object.

Example

Presume you have the following generated configuration:

apiVersion: v1
kind: Service
metadata:
  annotations: {}
  labels:
    app: sysdigcloud
    role: api
  name: sysdigcloud-api
  namespace: sysdigcloud
spec:
  clusterIP: None
  ports:
  - name: api
    port: 8080
    protocol: TCP
    targetPort: 8080
  selector:
    app: sysdigcloud
    role: api
  sessionAffinity: None
  type: ClusterIP

To Add to the Generated Configuration

Suppose you want to add an extra label my-awesome-label: my-awesome-value to the Service object. Then in the PATCH.yaml, you would put the following:

apiVersion: v1
kind: Service
metadata:
  name: sysdigcloud-api
  labels:
    my-awesome-label: my-awesome-value

Run the installer again, and the configuration would be as follows:

apiVersion: v1
kind: Service
metadata:
  annotations: {}
  labels:
    app: sysdigcloud
    role: api
    my-awesome-label: my-awesome-value
  name: sysdigcloud-api
  namespace: sysdigcloud
spec:
  clusterIP: None
  ports:
  - name: api
    port: 8080
    protocol: TCP
    targetPort: 8080
  selector:
    app: sysdigcloud
    role: api
  sessionAffinity: None
  type: ClusterIP

To Remove from the Generated Configuration

Supposed you wanted to remove all the labels. Then in the PATCH.yaml, you would put the following:

apiVersion: v1
kind: Service
metadata:
  name: sysdigcloud-api
  labels:

Run the installer again, and the configuration would be as follows:

apiVersion: v1
kind: Service
metadata:
  annotations: {}
  name: sysdigcloud-api
  namespace: sysdigcloud
spec:
  clusterIP: None
  ports:
  - name: api
    port: 8080
    protocol: TCP
    targetPort: 8080
  selector:
    app: sysdigcloud
    role: api
  sessionAffinity: None
  type: ClusterIP