# 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

## Run Only Sysdig Pods on a Node Using Taints and Tolerations

If you have a large shared Kubernetes cluster and want to dedicate a few nodes for just the Sysdig backend component installation, you can use the Kubernetes concept of taints and tolerations.

The basic process is:

1. Assign labels and taints to the relevant nodes.

2. Review the sample node-labels-and-taints values.yaml in the Sysdig github repo.

3. Copy that section to your own values.yaml file and edit with labels and taints you assigned.

Example from the sample file:

# To make the ‘tolerations’ code sample below functional, assign nodes the taint
# dedicated=sysdig:NoSchedule. E.g:
# kubectl taint my-awesome-node01 dedicated=sysdig:NoSchedule
tolerations:
- key: "dedicated"
operator: "Equal"
value: sysdig
effect: "NoSchedule"
# To make the Label code sample below functional, assign nodes the label
# role=sysdig.
# e.g: kubectl label nodes my-awesome-node01 role=sysdig
nodeaffinityLabel:
key: role
value: sysdig

## 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 Installer Upgrade (2.5.0+).

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
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
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
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
name: sysdigcloud-api
labels:

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

apiVersion: v1
kind: Service
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