Frequently Used Installer Configurations
SMTP Configs for Email Notifications
The available fields for SMTP configuration are documented in the
configuration_parameters.md
. Each includes SMTP
in its name. For
example:
sysdig:
...
smtpServer: smtp.sendgrid.net
smtpServerPort: 587
#User,Password can be empty if the server does not require authentication
smtpUser: apikey
smtpPassword: XY.abcdefghijk...
smtpProtocolTLS: true
smtpProtocolSSL: false
#Optional Email Header
smtpFromAddress: sysdig@mycompany.com
To configure email settings to be used for a notification
channel, copy the
parameters and appropriate values into yourvalues.yaml.
Configure AWS Credentials Using the Installer
The available fields for AWS credentials are documented in the configuration_parameters.md. They are:
sysdig:
accessKey: my_awesome_aws_access_key
secretKey: my_super_secret_secret_key
Use hostPath for Static Storage of Sysdig Components
The Installer assumes the usage of a dynamic storage provider (AWS or
GKE). In case these are not used in your environment, add the entries
below to thevalues.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 thevalues.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 issmall
, 3 when configured size ismedium
and 6 when configured size islarge
.elasticsearch.hostPathNodes:
The number of nodes configured here needs to be at minimum 1 when configured size issmall
, 3 when configured size ismedium
and 6 when configured size islarge
.sysdig.mysql.hostPathNodes:
When sysdig.mysqlHA is configured totrue
, 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 thesize
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:
Assign labels and taints to the relevant nodes.
Review the sample node-labels-and-taints values.yaml in the Sysdig github repo.
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 thevalues.yaml
.
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. 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
Feedback
Was this page helpful?
Glad to hear it! Please tell us how we can improve.
Sorry to hear that. Please tell us how we can improve.