Sysdig Documentation

Install Components (OpenShift)

Edit storageClassName Parameters

You need a storage class; step 2 shows how to create one if needed.

Enter the storageClassName in the appropriate .yaml files (see step 3).

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

    oc 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):

    apiVersion: storage.k8s.io/v1
    kind: StorageClass
    metadata:
      name: gp2
      labels:
        kubernetes.io/cluster-service: "true"
        addonmanager.kubernetes.io/mode: EnsureExists
    provisioner: kubernetes.io/aws-ebs
    parameters:
      type: gp2

    Now run the command:

    oc 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:

    datastores/as_kubernetes_pods/manifests/cassandra/cassandra-statefulset.yaml
    datastores/as_kubernetes_pods/manifests/elasticsearch/elasticsearch-statefulset.yaml
    datastores/as_kubernetes_pods/manifests/mysql/mysql-deployment.yaml

    With Secure:

    datastores/as_kubernetes_pods/manifests/postgres/postgres-statefulset.yaml

    In each file, the code snippet looks the same:

    volumeClaimTemplates:
     - metadata:
         name: data
       spec:
         accessModes: ["ReadWriteOnce"]
         resources:
           requests:
             storage: 50Gi
         storageClassName: <STORAGECLASS_NAME>

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.

    oc -n sysdigcloud apply -f datastores/as_kubernetes_pods/manifests/cassandra/cassandra-service.yaml
    oc -n sysdigcloud apply -f datastores/as_kubernetes_pods/manifests/cassandra/cassandra-statefulset.yaml
    oc -n sysdigcloud apply -f datastores/as_kubernetes_pods/manifests/elasticsearch/elasticsearch-service.yaml
    oc -n sysdigcloud apply -f datastores/as_kubernetes_pods/manifests/elasticsearch/elasticsearch-statefulset.yaml
  2. Create the MySQL and Redis databases:

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

    To add Sysdig Secure: Create the PostgreSQL database:

    oc -n sysdigcloud apply -f datastores/as_kubernetes_pods/manifests/postgres/postgres-service.yaml
    oc -n sysdigcloud apply -f datastores/as_kubernetes_pods/manifests/postgres/postgres-statefulset.yaml
  3. Wait until datastore pods are in ready state, then deploy the backend deployment sets (worker, collector, and API).

    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.

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

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

    If you are installing Sysdig Monitor only, skip to Sysdig Install on OpenShift (v. 1929+)#Configure Access for Connectivity to the Cluster.

    For Sysdig Secure

  5. Wait for the API, worker, and collector to come up before proceeding.

    Then create anchore-engine deployments and service (used in scanning):

    oc -n sysdigcloud apply -f sysdigcloud/anchore-service.yaml  
    oc -n sysdigcloud apply -f sysdigcloud/anchore-core-config.yaml 
    oc -n sysdigcloud apply -f sysdigcloud/anchore-core-deployment.yaml
    oc -n sysdigcloud apply -f sysdigcloud/anchore-worker-config.yaml
    oc -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:

    oc -n sysdigcloud apply -f sysdigcloud/scanning-api-deployment.yaml
    oc -n sysdigcloud apply -f sysdigcloud/scanning-alertmgr-deployment.yaml
    oc -n sysdigcloud apply -f sysdigcloud/scanning-service.yaml

Configure Access for Connectivity to the Cluster

Apply the appropriate ingress yaml. (The API_DNS name was entered in step 7, in Step 2 Configure Backend Components.) This configures the route to the Sysdig UI.

For Sysdig Monitor

oc -n sysdigcloud apply -f sysdigcloud/api-ingress.yaml

With Sysdig Secure:

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

Configure connectivity to the collector for the agent:

oc -n sysdigcloud apply -f sysdigcloud/openshift/openshift-collector-router.yaml

Making Configuration Changes

There are two ways to change the original installation parameters:

Option 1 Edit the Configmap

Run the following command:

oc -n sysdigcloud edit configmap/sysdigcloud-config

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

Perform the Sysdig Install on OpenShift (v. 1929+)#Required Restart.

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:

oc -n sysdigcloud replace -f sysdigcloud/config.yaml 

When completed, perform the Sysdig Install on OpenShift (v. 1929+)#Required Restart.

Required Restart

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')\"}}}}}"