Sysdig Documentation

Install Components (Kubernetes)

Configure Storage Class

If you are using EKS or GKE, default storage classes are provided; check for them in step 1.

In other environments, you may need to create a storage class (step 2).

Finally, enter the storageClassName in the appropriate .yaml files, as detailed in step 3.

  1. Verify whether a storage class has been created, by running the command:

    kubectl get storageclass
  2. If no storage class has been defined, create a manifest for one, and then deploy it.

    For example, a manifest could be named sysdigcloud-storageclass.yaml and contain the following contents (for a storage class using GP2 volumes in AWS):

    kind: StorageClass
      name: gp2
      annotations: "true"
      labels: "true" EnsureExists
      type: gp2

    Now run the command:

    kubectl apply -f sysdigcloud-storageclass.yaml 
  3. Using either the existing storage class name from step 1, or the storage class name defined in step 2, edit the storageClassName in the following .yaml files:

    For Monitor:


    With Secure:


Install Datastores and Backend Components

For Sysdig Monitor

  1. Create the datastore statefulsets for Elasticsearch and Cassandra. Elasticsearch and Cassandra are automatically set up with --replica=3 generating full clusters.

    kubectl -n sysdigcloud apply -f datastores/as_kubernetes_pods/manifests/cassandra/cassandra-service.yaml
    kubectl -n sysdigcloud apply -f datastores/as_kubernetes_pods/manifests/cassandra/cassandra-statefulset.yaml
    kubectl -n sysdigcloud apply -f datastores/as_kubernetes_pods/manifests/elasticsearch/elasticsearch-service.yaml
    kubectl -n sysdigcloud apply -f datastores/as_kubernetes_pods/manifests/elasticsearch/elasticsearch-statefulset.yaml
  2. Create the database and caching systems: MySQL, and Redis.

    kubectl -n sysdigcloud apply -f datastores/as_kubernetes_pods/manifests/mysql/mysql-deployment.yaml
    kubectl -n sysdigcloud apply -f datastores/as_kubernetes_pods/manifests/redis/redis-deployment.yaml

    To add Sysdig Secure: Create the PostgreSQL database:

    kubectl -n sysdigcloud apply -f datastores/as_kubernetes_pods/manifests/postgres/postgres-service.yaml
    kubectl -n sysdigcloud apply -f datastores/as_kubernetes_pods/manifests/postgres/postgres-statefulset.yaml
  3. Wait until datastore pods are in ready state:

    Run the command:

    kubectl -n sysdigcloud get pods

    Then look in the READY column to ensure all pods are ready. For example, displaying a 1/1 means 1 of 1 pods is ready

    Then deploy the backend deployment sets (worker, collector, and API).

    Pause for 60 seconds after creating the API deployment.

    kubectl -n sysdigcloud apply -f sysdigcloud/api-deployment.yaml
    kubectl -n sysdigcloud apply -f sysdigcloud/collector-deployment.yaml
    kubectl -n sysdigcloud apply -f sysdigcloud/worker-deployment.yaml
  4. Create the service for the api and collector:

    kubectl -n sysdigcloud apply -f sysdigcloud/api-headless-service.yaml
    kubectl -n sysdigcloud apply -f sysdigcloud/collector-headless-service.yaml

    If you are installing Sysdig Monitor only, skip to Sysdig Install with Kubernetes 1.9+#Configure Access for Connectivity to the Cluster.

    For Sysdig Secure

  5. Create anchore-engine deployments and service (used in scanning):

    kubectl -n sysdigcloud apply -f sysdigcloud/anchore-service.yaml
    kubectl -n sysdigcloud apply -f sysdigcloud/anchore-core-config.yaml 
    kubectl -n sysdigcloud apply -f sysdigcloud/anchore-core-deployment.yaml
    kubectl -n sysdigcloud apply -f sysdigcloud/anchore-worker-config.yaml
    kubectl -n sysdigcloud apply -f sysdigcloud/anchore-worker-deployment.yaml

    Wait 60 seconds to ensure the core-deployment is in Running status, then deploy the rest of the Secure-related yamls:

    kubectl -n sysdigcloud apply -f sysdigcloud/scanning-api-deployment.yamlkubectl -n sysdigcloud apply -f sysdigcloud/scanning-alertmgr-deployment.yamlkubectl -n sysdigcloud apply -f sysdigcloud/scanning-service.yamlkubectl -n sysdigcloud apply -f sysdigcloud/scanning-alertmgr-service.yaml #version 2.3.0 or higherkubectl -n sysdigcloud apply -f sysdigcloud/anchore-enterprise-license.yaml #version 2.4.1 or higherkubectl -n sysdigcloud apply -f sysdigcloud/anchore-reports-config.yamlkubectl -n sysdigcloud apply -f sysdigcloud/anchore-reports-deployment.yamlkubectl -n sysdigcloud apply -f sysdigcloud/anchore-reports-service.yaml
    kubectl -n sysdigcloud apply -f sysdigcloud/scanning-api-deployment.yaml
    kubectl -n sysdigcloud apply -f sysdigcloud/scanning-alertmgr-deployment.yaml
    kubectl -n sysdigcloud apply -f sysdigcloud/scanning-service.yaml

Connecting to the Cluster

GCloud/GKE Only: Add Cluster-Admin to User

kubectl create clusterrolebinding cluster-admin-binding --clusterrole cluster-admin --user $(gcloud config get-value account)

Add Ingress Controller

Sysdig Monitor

To permit incoming connections to the Sysdig API and collector, deploy the following ingress yamls.

kubectl -n sysdigcloud apply -f sysdigcloud/ingress_controller/ingress-clusterrole.yaml
kubectl -n sysdigcloud apply -f sysdigcloud/ingress_controller/ingress-clusterrolebinding.yaml
kubectl -n sysdigcloud apply -f sysdigcloud/ingress_controller/ingress-role.yaml
kubectl -n sysdigcloud apply -f sysdigcloud/ingress_controller/ingress-rolebinding.yaml
kubectl -n sysdigcloud apply -f sysdigcloud/ingress_controller/ingress-serviceaccount.yaml
kubectl -n sysdigcloud apply -f sysdigcloud/ingress_controller/default-backend-service.yaml
kubectl -n sysdigcloud apply -f sysdigcloud/ingress_controller/default-backend-deployment.yaml
kubectl -n sysdigcloud apply -f sysdigcloud/ingress_controller/ingress-configmap.yaml
kubectl -n sysdigcloud apply -f sysdigcloud/ingress_controller/ingress-tcp-services-configmap.yaml
kubectl -n sysdigcloud apply -f sysdigcloud/ingress_controller/ingress-daemonset.yaml
kubectl -n sysdigcloud apply -f sysdigcloud/api-ingress.yaml

Sysdig Secure

If you are installing Sysdig Monitor and Secure, replace the api-ingress.yaml with the following line:

kubectl -n sysdigcloud apply -f sysdigcloud/api-ingress-with-secure.yaml

There are two ways to change the original installation parameters:

Making Configuration Changes

There are two ways to change the original installation parameters:

Option 1 Edit the Configmap

Run the following command:

kubectl edit configmap/sysdigcloud-config --namespace sysdigcloud

A text editor is presented with the configmap to be edited. Enter parameters as needed, then save and quit.

Then Restart Configmap

Option 2 Overwrite the Configmap

If the configmap is edited on the client side (for example, to keep it synced in a git repository), it can be overridden with the following command:

kubectl replace -f sysdigcloud/config.yaml --namespace sysdigcloud

When completed, Restart Configmap.

Restart Configmap

After updating the configmap, the Sysdig components must be restarted for the changed parameters to take effect. This can be done by forcing a rolling update of the deployments.

A possible way to do so is to change something innocuous, which forces a rolling update. E.g.:

oc -n sysdigcloud patch deployment [deploymnet] -p \
 "{\"spec\":{\"template\":{\"metadata\":{\"annotations\":{\"date\":\"$(date +'%s')\"}}}}}"