This the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

  • 1:
    • 2:
      • 3:
        • 4:
          • 5:
            • 6:
              • 7:

                On-Premises Upgrades

                This section describes how to upgrade an on-premise installation, depending on whether it was installed using a Kubernetes or a Replicated orchestrator.

                As needed, version-specific upgrade or migration instructions will be added to this section.

                Oversight Services Now Offered for All Installs and Upgrades

                As part of our continued focus on our customers, we are now offering oversight services for all on-premise installs and upgrades. Your Technical Account Manager (TAM), in conjunction with our support organization and Professional Services [where applicable], will work with you to:

                • Assess your environment to ensure it is configured correctly

                • Review your infrastructure to validate the appropriate storage capacities are available

                • Review and provide recommendations for backing up your Sysdig data

                • Work with you to ensure our teams are ready to assist you during the install and upgrade process

                • Provide the software for the install

                • Be available during the process to ensure a successful deployment

                You can always review the process in the documentation on GitHub (v. 3.6.0+) or the standard docs site (for older versions).

                If you are a new customer looking to explore Sysdig, please head over here to sign up for a trial on our SaaS Platform. Alternatively, you can contact us here.

                Explore the Upgrade Topics

                This section provides roadmaps for upgrading Sysdig Platform components. Review the topics appropriate to your environment.

                TopicsDescription
                Supported Upgrade PathsUnderstand the upgrade and migration paths for on-prem installations.
                Installer Upgrade (3.5.0-3.5.1)Upgrading Sysdig Platform to v 3.5.0 from v. 3.0, 3.2.x using the installer tool. There is no manual install option as of version 3.5.0.
                Installer Upgrade (2.5.0+)Upgrading Sysdig Platform v2.5.0 - 3.2.2 by using the Installer tool. As of version 2.5.0, the Sysdig platform on Kubernetes or OpenShift should be upgraded using the Installer tool.
                Manual Upgrade (3.0.0+)Upgrading Sysdig Platform v3.0.0 and above manually on Kubernetes.
                Upgrading v2.4.1- v2.5.0 on KubernetesUpgrading the Sysdig Platform versions between 2.4.1and 2.5.0 manually on Kubernetes.
                Upgrading v2.3.0 on KubernetesUpgrading Sysdig Platform v2.3.0 manually on Kubernetes.
                Upgrading v2435 on KubernetesUpgrading Sysdig Platform v2435 manually on Kubernetes.
                Basic Upgrade on ReplicatedUpgrading the mandatory components of the Sysdig Platform on a Replicated environment.

                Supported Migration Paths

                In general, Sysdig tests and supports direct upgrade from five releases back to the current version. Release-specific requirements are listed in the table below.

                For Kubernetes Environments

                Install Version

                Incl. Hotfixes

                Supported Upgrade From

                Notes

                Baseline Documentation

                3.6.0 (by request)

                3.2.2, 3.5.1

                Platform changes: new inline scanner version, interactive session expiration. Sysdig Secure modules added/changed, including Compliance, Event Forwarding, Capture improvements, Image Scan results. Sysdig Monitor improvements in UI.

                GitHub Readme

                3.5.1

                (by request)

                3.0, 3.2.x, (3.5.0 if it was installed)

                New/changed modules in both Sysdig Secure and Sysdig Monitor, including: New Getting Started and Overview, new Dashboards, overhauled Secure Events Feed, new navigation bar icons and layout, changed Image scanning navigation and usage, new Secure vulnerability feed and benchmark test,

                Installer Upgrade (3.5.0-3.5.1) with oversite assistance from Sysdig Support

                3.2.2

                2.5.0, 3.2.0

                Hot fix

                Installer Upgrade (2.5.0+)

                Installer Upgrade (2.5.0+)

                3.2.0

                3.2.1, 3.2.2

                2.5.0, 3.0.0

                In Sysdig Secure: Data retention limits for scan results, vulnerabiity comparison in scan results, redesigned Captures page, RBAC capability, activity audit improvement. In Sysdig Monitor and Secure: S3-compatible storage for Capture files.

                Installer Upgrade (2.5.0+)

                3.0.0

                2.4.1, 2.5.0

                Beta Activity Audit feature, Beta Policy Advisor feature.

                Installer Upgrade (2.5.0+)

                2.5.0

                2.3.0, 2.4.1

                New Installer tool for upgrading; new documentation site; inline scanning for Secure, other enhancements

                Installer Upgrade (2.5.0+)

                2.4.1

                2.3.0

                Report service added; upgrade to Anchore license required

                Upgrade v 2.4.1

                2.3.0

                1929, 2435

                Ability to secure Elasticsearch and the Cassandra DB with password authentication or SSL/TLS protection.

                Manual Upgrade (2.3.0)

                2435

                (2304) (2266) (2172)

                1929, 1765

                Architecture changes to Dashboards

                & API pods.

                Manual Upgrade (v2435)

                Note that this replaces 2172, 2266, and 2304.

                1929

                legacy

                1765

                Migration Tool (MySQL Connector)

                Architecture & Port 443 change

                legacy

                1630

                ((1586)

                legacy

                1511

                (1472) (1402)

                legacy

                1245

                legacy

                1149

                Migration Tool (Unified Events)

                legacy

                1091

                legacy

                For Replicated Environments

                Most Replicated environments can be upgraded directly to the current version. See also: Basic Upgrade (Replicated).

                It is recommended to follow upgrade best practices:

                • Keep upgrades current.

                • Test upgrades in a non-mission-critical or staging environment before rolling into production.

                1 -

                Installer Upgrade (3.5.0-3.5.1)

                As of version 3.5.0/3.5.1, Sysdig has changed its upgrade procedure.

                All on-premises installations and upgrades are now scheduled with and guided by Sysdig technical account managers and professional services division. See Oversight Services Now Offered for All Installs and Upgrades .

                For customers, the instructions in this section are for review purposes only.

                Overview

                With version 3.5.0, both installing and upgrading with the installer has been simplified from previous versions. Upgrade differs from Install in that you run an installer diff to discover the differences between the old and new versions and then installer deploy for the new version.

                Some guidance from Sysdig Support may be warranted in highly customized installations.

                Upgrade Steps

                Upgrading is performed just like a fresh install, with the addition of the generate diff step. Refer to the appropriate workflow, depending on your environment:

                Postgres Version Update v10.x to 12.x

                Version 3.5.0 upgrade includes an automatic Postgres version upgrade. Depending on the size of your database, that can take some time.

                The data migration takes approximately 1 min per 1 GiB of data. The speed of data migration ultimately depends on the underlying storage media.

                To complete the Postgres upgrade, you must also ensure there is sufficient disk space in the volume when using a local-disk storage provisioner in Kubernetes. For example, if your current Postgres size is 100 GiB, ensure there is at least another 100 GiB space free in the volume. This is required temporarily for copying the data during the upgrade.

                3.5.0 - 3.5.1 Elasticsearch Upgrade

                Upgrading from version 3.5.0 to 3.5.1 also upgrades Elasticsearch. Due to the Elasticsearch update strategy of ondelete, the pods will only be upgraded when they are restarted:

                image: quay.io/sysdig/elasticsearch:6.8.3.7
                image: quay.io/sysdig/elasticsearch:6.8.3.9
                
                

                2 -

                Installer Upgrade (2.5.0+)

                Overview

                All on-premises installations and upgrades are now scheduled with and guided by Sysdig technical account managers and professional services division. See Oversight Services Now Offered for All Installs and Upgrades .

                For customers, the instructions in this section are for review purposes only.

                The Installer tool can be used to upgrade a Sysdig implementation. Just as in an installation, you must meet the prerequisites, download the values.yaml, edit the values as indicated, and run the installer. The main difference is that you run it twice: once to discover the differences between the old and new versions and the second time to deploy the new version.

                As this is a new feature, some guidance from Sysdig Professional Services may be warranted in highly customized installations.

                Supported Installer Versions

                On-Prem VersionInstaller Version
                3.0.03.0.0-7
                3.2.03.2.0-9
                3.2.23.2.2-1

                Upgrade Steps

                To upgrade:

                1. Download the latest installer binary that matches your OS from the sysdigcloud-kubernetes releases page.

                2. Copy the current version of values.yaml to your working directory.

                  wget https://raw.githubusercontent.com/draios/sysdigcloud-kubernetes/installer/installer/values.yaml
                  
                3. Edit the following values:

                  • scripts: set to generate diff.

                    This setting will generate the differences between the installed environment and the upgrade version. The changes will be displayed in your terminal.

                  • size: Specifies the size of the cluster. Size defines CPU, Memory, Disk, and Replicas. Valid options are: small, medium and large

                  • quaypullsecret: quay.io provided with your Sysdig purchase confirmation mail

                  • storageClassProvisioner: The name of the storage class provisioner to use when creating the configured storageClassName parameter. When installing, if you use AWS or GKE as your storage provisioner for Kubernetes, enter aws or gke in the storageClassProvisioner field. If you do not use one of those two dynamic storage provisioners, enter: hostPath and then refer to the Advanced examples for how to configure static storage provisioning using this option.

                  • sysdig.license: Sysdig license key provided with your Sysdig purchase confirmation mail

                  • sysdig.anchoreLicensePath: The path relative to the values.yaml where the Anchore enterprise license yaml is located. (For Sysdig Secure users only.)

                  • sysdig.dnsname: The domain name the Sysdig APIs will be served on. Note that the master node may not be used as the DNS name when using hostNetwork mode.

                  • sysdig.collector.dnsName: (OpenShift installs only) Domain name the Sysdig collector will be served on. When not configured it defaults to whatever is configured for sysdig.dnsName. Note that the master node may not be used as the DNS name when using hostNetwork mode.

                  • deployment: (OpenShift installs only) Add deployment: openshift to the root of the values.yaml file.

                  • sysdig.ingressNetworking: The networking construct used to expose the Sysdig API and collector.Options are:

                    • hostnetwork: sets the hostnetworking in the ingress daemonset and opens host ports for api and collector. This does not create a Kubernetes service.

                    • loadbalancer: creates a service of type loadbalancer and expects that your Kubernetes cluster can provision a load balancer with your cloud provider.

                    • nodeport: creates a service of type nodeport.The node ports can be customized with:

                      sysdig.ingressNetworkingInsecureApiNodePort

                      sysdig.ingressNetworkingApiNodePort

                      sysdig.ingressNetworkingCollectorNodePort

                    If doing an airgapped install , you would also edit the following values:

                  • airgapped_registry_name: The URL of the airgapped (internal) docker registry. This URL is used for installations where the Kubernetes cluster can not pull images directly from Quay

                  • airgapped_registry_password: The password for the configured airgapped_registry_username. Ignore this parameter if the registry does not require authentication.

                  • airgapped_registry_username: The username for the configured airgapped_registry_name. Ignore this parameter if the registry does not require authentication.

                4. Run the installer.

                  For environments with access to the internet:

                  docker run -e HOST_USER=$(id -u) -e KUBECONFIG=/.kube/config
                  -v ~/.kube:/.kube:Z -v $(pwd):/manifests:Z
                  quay.io/sysdig/installer:<version>
                  

                  For other supported installer versions, see Supported Installer Versions.

                  For partial-airgap (installation machine has access to the internet):

                  docker run -e HOST_USER=$(id -u) -e KUBECONFIG=/.kube/config
                    -v ~/.kube:/.kube:Z
                    -v $(pwd):/manifests:Z
                    -v /var/run/docker.sock:/var/run/docker.sock:Z
                    -v ~/.docker:/root/docker:Z
                    quay.io/sysdig/installer:<version>
                  

                  For other supported installer versions, see Supported Installer Versions.

                  For full airgapped environment:

                  Run steps 1-4 in the Full Airgap Install, then run:

                  bash sysdig_installer.tar.gz
                  
                5. If you are fine with the differences displayed, then set scripts to deploy and rerun the installer as in Step 3.

                  If you want to override a change, based on your environment’s custom settings, then contact Sysdig Support for assistance.

                6. The datastores Cassandra and ElasticSearch have an onDelete update strategy and must be manually restarted to complete the upgrade.

                3 -

                Manual Upgrade (3.0.0+)

                As of August 2020, Sysdig has changed its upgrade procedure.

                All on-premises installations and upgrades are now scheduled with and guided by Sysdig technical account managers and professional services division. See Oversight Services Now Offered for All Installs and Upgrades .

                For customers, the instructions in this section are for review purposes only.

                Sysdig platform on-premise releases are listed here. Each release has a version number and specific release notes.

                This release has the following significant changes:

                • Added NATS service to deliver events to the Sysdig backend

                • Added services for the beta Policy Advisor, which permits a user to auto-generate Pod Security Policies and perform dry tests or “simulations” of them before committing them to an environment.

                • Added services for activity audit, which allows users to view different data sources in-depth for monitoring, troubleshooting, diagnostics, or to meet regulatory controls

                • Some Anchore reporting components are not needed anymore and have been removed.

                Download the New Version

                Download the new version from Sysdig’s GitHub and unzip it.

                wget https://github.com/draios/sysdigcloud-kubernetes/archive/<version_number>.tar.gz &&  tar xvf <version_number>.tar.gz
                

                Edit New Files to Match Your Customized Files

                It is important to use the latest YAML files for a successful upgrade.

                Edit the following files within the sysdigcloud directory to match any customizations you may have made in your existing production system.

                Please do not edit the image: property.

                Sysdig Component Files

                Ensure that any passwords or user names are transferred from your existing config.yaml to the new one. Suggested areas to review are listed below.

                • config.yaml:

                  The following variables are always customized in Sysdig installations:

                  api.url
                  collector.endpoint
                  sysdigcloud.license
                  mysql.password
                  

                  Modifying following variables is optional but commonly done:

                  cassandra.jvm.options
                  elasticsearch.jvm.options
                  sysdigcloud.jvm.api.options
                  sysdigcloud.jvm.collector.options
                  sysdigcloud.jvm.worker.options
                  
                • Check deployment YAML files for CPU/memory settings.

                • Update the spec.replicas definition in the following files:

                  • sysdigcloud/api-deployment.yaml

                  • sysdigcloud/collector-deployment.yaml

                  • sysdigcloud/worker-deployment.yaml

                • If running Sysdig Secure:

                  • sysdigcloud/anchore-core-config.yaml

                  • sysdigcloud/anchore-worker-config.yaml

                  • sysdigcloud/anchore-core-deployment.yaml

                  • sysdigcloud/anchore-worker-deployment.yaml

                  • sysdigcloud/scanning-api-deployment.yaml

                  • sysdigcloud/scanning-alertmgr-deployment.yaml

                Postgres File (Sysdig Secure Only)

                • postgres-statefulset.yaml : Edit the storage class name in this file.

                  The file is located in datastores/as_kubernetes_pods/manifests/postgres/postgres-statefulsets.yaml

                  Storage class name appears as spec.volumeClaimTemplates[].spec.storageClassName

                Elasticsearch and Cassandra Files

                • elasticsearch-statefulset.yaml: For example, your environment may have customized the values for the number of replicas, resource constraints, amount of storage, and the storage class name:

                  spec.replicas and spec.template.spec.containers[elasticsearch].env[ELASTICSEARCH_GOSSIP_NODES_NUM].value
                  spec.template.spec.containers[].resources
                  spec.volumeClaimTemplates[].spec.resources.requests.storage
                  spec.volumeClaimTemplates[].spec.storageClassName
                  
                • cassandra-statefulset.yaml: As with Elasticsearch, your environment may have customized the values for the number of replicas, resource constraints, amount of storage, and the storage class name:

                  spec.replicas
                  spec.template.spec.containers[].resources
                  spec.volumeClaimTemplates[].spec.resources.requests.storage
                  spec.volumeClaimTemplates[].spec.storageClassName
                  

                Apply the Files

                The --force flag deletes the object and re-creates it whereas the --replace flag automatically creates an object if it doesn’t exist.

                For the upgrade, assume NAMESPACE=sysdigcloud.

                Install the NATS Components

                In version 3.0, a NATS datastore was introduced for handling events inside the Sysdig platform:

                kubectl -n $NAMESPACE apply -f datastores/as_kubernetes_pods/manifests/nats-streaming/nats-streaming-deployment.yaml
                kubectl -n $NAMESPACE apply -f datastores/as_kubernetes_pods/manifests/nats-streaming/nats-streaming-service.yaml
                

                Upgrade Sysdig Monitor

                Run the kubectl commands to apply the relevant files to your cluster.

                kubectl -n $NAMESPACE apply -f sysdigcloud/config.yaml
                
                kubectl -n $NAMESPACE replace --force -f datastores/as_kubernetes_pods/manifests/elasticsearch/elasticsearch-statefulset.yaml
                kubectl -n $NAMESPACE replace --force -f datastores/as_kubernetes_pods/manifests/cassandra/cassandra-statefulset.yaml
                

                Pause to allow Elasticsearch and Cassandra to come up. then continue:

                kubectl -n $NAMESPACE apply -f sysdigcloud/api-deployment.yaml
                

                Pause to allow api to come up, then continue:

                kubectl -n $NAMESPACE apply -f sysdigcloud/collector-deployment.yaml
                kubectl -n $NAMESPACE apply -f sysdigcloud/worker-deployment.yaml
                

                Upgrade Sysdig Secure

                Run the kubectl commands to apply the relevant files to your cluster.

                kubectl -n $NAMESPACE replace --force -f datastores/as_kubernetes_pods/manifests/postgres/postgres-statefulset.yaml
                
                kubectl -n $NAMESPACE apply -f sysdigcloud/anchore-core-config.yaml
                kubectl -n $NAMESPACE apply -f sysdigcloud/anchore-worker-config.yaml
                kubectl -n $NAMESPACE apply -f sysdigcloud/anchore-core-deployment.yaml
                kubectl -n $NAMESPACE apply -f sysdigcloud/anchore-worker-deployment.yaml
                
                kubectl -n $NAMESPACE apply -f sysdigcloud/scanning-api-deployment.yaml
                kubectl -n $NAMESPACE apply -f sysdigcloud/scanning-alertmgr-deployment.yaml
                

                Create secrets for the new policy advisor and activity audit components by deploying the policy-advisor-secret.yaml.

                kubectl -n $NAMESPACE apply -f sysdigcloud/policy-advisor-secret.yaml
                

                Deploy the components:

                kubectl -n $NAMESPACE apply -f sysdigcloud/policy-advisor-service.yaml
                kubectl -n $NAMESPACE apply -f sysdigcloud/activity-audit-api-service.yaml
                kubectl -n $NAMESPACE apply -f sysdigcloud/activity-audit-api-deployment.yaml
                kubectl -n $NAMESPACE apply -f sysdigcloud/policy-advisor-deployment.yaml
                kubectl -n $NAMESPACE apply -f sysdigcloud/activity-audit-worker-deployment.yaml
                kubectl -n $NAMESPACE apply -f sysdigcloud/activity-audit-janitor-cronjob.yaml
                

                You can delete the Anchore reporting components to free up system resources:

                kubectl -n $NAMESPACE delete -f sysdigcloud/anchore-enterprise-license.yaml
                kubectl -n $NAMESPACE delete -f sysdigcloud/anchore-reports-config.yaml
                kubectl -n $NAMESPACE delete -f sysdigcloud/anchore-reports-deployment.yaml
                kubectl -n $NAMESPACE delete -f sysdigcloud/anchore-reports-service.yaml
                
                

                4 -

                Manual Upgrade (2.4.1- 2.5.0)

                As of August 2020, Sysdig has changed its upgrade procedure.

                All on-premises installations and upgrades are now scheduled with and guided by Sysdig technical account managers and professional services division. See Oversight Services Now Offered for All Installs and Upgrades .

                For customers, the instructions in this section are for review purposes only.

                Sysdig platform on-premise releases are listed here. Each release has a version number and specific release notes.

                This release has the following significant component change:

                The Report service is now available for Sysdig Secure. Installing it requires first applying an Anchore license and then applying the appropriate report yamls, as listed below.

                Download the New Version

                Download the new version from Sysdig’s GitHub and unzip it.

                Note that as of this release, versioning standards have changed from a single build number (e.g. v1929) to semantic versioning (e.g. 2.3.0)

                wget https://github.com/draios/sysdigcloud-kubernetes/archive/<version_number>.tar.gz &&  tar xvf <version_number>.tar.gz
                

                Edit New Files to Match Your Customized Files

                It is important to use the latest YAML files for a successful upgrade.

                Edit the following files within the sysdigcloud directory to match any customizations you may have made in your existing production system.

                Sysdig Cloud Files

                Customization involves copying the existing settings from your environment and modifying the files listed in this section.

                Update the following files with customizations from your existing environment:

                • sysdigcloud/config.yaml: Pull configurations from your sysdigcloud-config configmap to the downloaded sysdigcloud/config.yaml.

                  The following variables are mandatory for Sysdig installations:

                  api.url
                  collector.endpoint
                  sysdigcloud.license
                  

                  The following variables are optional but commonly modified for Sysdig installations:

                  cassandra.jvm.options
                  elasticsearch.jvm.options
                  sysdigcloud.jvm.api.options
                  sysdigcloud.jvm.collector.options
                  sysdigcloud.jvm.worker.options
                  

                  If you have modified the previous config.yaml, copy the modified options such as the external endpoints. You must also check deployment YAML files for CPU/memory settings.

                • Copy configurations from your existing deployment and update the spec.replicas definition in the following files:

                  • sysdigcloud/api-deployment.yaml

                  • sysdigcloud/collector-deployment.yaml

                  • sysdigcloud/worker-deployment.yaml

                • If running Sysdig Secure:

                  Please do not edit the image: property.

                  • sysdigcloud/anchore-core-config.yaml

                  • sysdigcloud/anchore-worker-config.yaml

                  • sysdigcloud/anchore-core-deployment.yaml

                  • sysdigcloud/anchore-worker-deployment.yaml

                  • sysdigcloud/scanning-api-deployment.yaml

                  • sysdigcloud/scanning-alertmgr-deployment.yaml

                Postgres File (if running Sysdig Secure)

                Update the following file with customizations from your existing environment:

                Please do not edit the image: property.

                • Modify the storage class name, spec.volumeClaimTemplates[].spec.storageClassName in the datastores/as_kubernetes_pods/manifests/postgres/postgres-statefulset.yaml file.

                Elasticsearch and Cassandra Files

                In version 2.3.0, Elasticsearch and Cassandra yaml configurations have been updated. Update the new files with customizations from your existing environment.

                Please do not edit the image: property.

                • elasticsearch-statefulset.yaml - For example, your environment may have customized the values for the number of replicas, resource constraints, amount of storage, and the storage class name:

                  spec.replicas and spec.template.spec.containers[elasticsearch].env[ELASTICSEARCH_GOSSIP_NODES_NUM].value
                  spec.template.spec.containers[].resources
                  spec.volumeClaimTemplates[].spec.resources.requests.storage
                  spec.volumeClaimTemplates[].spec.storageClassName
                  
                • cassandra-statefulset.yaml - As with Elasticsearch, your environment may have customized the values for the number of replicas, resource constraints, amount of storage, and the storage class name:

                  spec.replicas
                  spec.template.spec.containers[].resources
                  spec.volumeClaimTemplates[].spec.resources.requests.storage
                  spec.volumeClaimTemplates[].spec.storageClassName
                  

                Apply the Files

                Run the kubectl commands to apply the relevant files to your cluster.

                Upgrade for Sysdig Monitor

                The --force flag deletes the object and re-creates it whereas the --replace flag automatically creates an object if it doesn’t exist.

                NAMESPACE=sysdigcloud
                kubectl -n $NAMESPACE apply -f sysdigcloud/config.yaml
                kubectl -n $NAMESPACE replace --force -f datastores/as_kubernetes_pods/manifests/elasticsearch/elasticsearch-statefulset.yaml
                kubectl -n $NAMESPACE replace --force -f datastores/as_kubernetes_pods/manifests/cassandra/cassandra-statefulset.yaml
                kubectl -n $NAMESPACE apply -f sysdigcloud/api-deployment.yaml
                kubectl -n $NAMESPACE apply -f sysdigcloud/collector-deployment.yaml
                kubectl -n $NAMESPACE apply -f sysdigcloud/worker-deployment.yaml
                

                Upgrade for Sysdig Secure

                For versions 2.4.1 and higher: To use the Reports functionality in Sysdig Secure, it is necessary to enter a license key in the anchore-license.yaml. If you are upgrading or installing and do not have an anchore license please contact support. This license is used for additional 3rd party vulnerability feed entitlements.

                1. Edit the license YAML file: sysdigcloud/anchore-enterprise-license.yaml. Replace <LICENSE> with the key received from Sysdig.

                  ---
                  apiVersion: v1
                  kind: Secret
                  metadata:
                    name: anchore-enterprise-license
                  data:
                    # <LICENSE> is derived from `cat anchore-license.yaml | base64`
                    anchore-license.yaml: <LICENSE>
                  type: Opaque
                  
                2. Run the command:

                  kubectl -n sysdigcloud apply -f sysdigcloud/anchore-enterprise-license.yaml
                  

                Apply the Files

                Run the following commands, preserving the order:

                kubectl -n $NAMESPACE replace --force -f datastores/as_kubernetes_pods/manifests/postgres/postgres-statefulset.yaml
                kubectl -n $NAMESPACE apply -f sysdigcloud/anchore-core-config.yaml
                kubectl -n $NAMESPACE apply -f sysdigcloud/anchore-worker-config.yaml
                kubectl -n $NAMESPACE apply -f sysdigcloud/anchore-core-deployment.yaml
                kubectl -n $NAMESPACE apply -f sysdigcloud/anchore-worker-deployment.yaml
                kubectl -n $NAMESPACE apply -f sysdigcloud/scanning-alertmgr-service.yaml
                kubectl -n $NAMESPACE apply -f sysdigcloud/scanning-api-deployment.yaml
                kubectl -n $NAMESPACE apply -f sysdigcloud/scanning-alertmgr-deployment.yaml
                kubectl -n $NAMESPACE apply -f sysdigcloud/anchore-enterprise-license.yaml #version 2.4.1 or higher
                kubectl -n $NAMESPACE apply -f sysdigcloud/anchore-reports-config.yaml
                kubectl -n $NAMESPACE apply -f sysdigcloud/anchore-reports-deployment.yaml
                kubectl -n $NAMESPACE apply -f sysdigcloud/anchore-reports-service.yaml
                
                

                5 -

                Manual Upgrade (2.3.0)

                As of August 2020, Sysdig has changed its upgrade procedure.

                All on-premises installations and upgrades are now scheduled with and guided by Sysdig technical account managers and professional services division. See Oversight Services Now Offered for All Installs and Upgrades .

                For customers, the instructions in this section are for review purposes only.

                Sysdig platform on-premise releases are listed here. Each release has a version number and specific Release Notes.

                This release has the following significant component changes:

                1. Includes the option of securing Elasticsearch and/or Cassandra with username/password authentication and TLS-encrypted data in transit. This prevents both unauthorized access to the clusters and network eavesdropping. The upgrade instructions below incorporate this new capability when using the Sysdig-provided Cassandra and Elasticsearch components.

                  If you are running your own Cassandra or Elasticsearch clusters, you can skip the section Elasticsearch and Cassandra Files.

                2. Updates of the Postgres database and Anchore engine (if you are running Sysdig Secure).

                3. The following parameter has been renamed in config.yaml: elasticsearch.url to elasticsearch.hostname

                  The value of elasticsearch.hostname does not include the protocol (e.g.http://); just use the hostname itself. For example, if you had elasticsearch.url: ``http://sysdigcloud-elasticsearch, it would now be elasticsearch.hostname: sysdigcloud-elasticsearch.

                Download the New Version

                Download the new version from Sysdig’s GitHub and unzip it.

                Note that as of this release, versioning standards have changed from a single build number (e.g. v1929) to semantic versioning (e.g. 2.3.0)

                wget https://github.com/draios/sysdigcloud-kubernetes/archive/<version_number>.tar.gz &&  tar xvf <version_number>.tar.gz
                

                Edit New Files to Match Your Customized Files

                It is important to use the latest YAML files for a successful upgrade.

                Edit the following files within the sysdigcloud directory to match any customizations you may have made in your existing production system.

                Sysdig Cloud Files

                Customization involves copying the existing settings from your environment and modifying the files listed in this section.

                Update the following files with customizations from your existing environment:

                • sysdigcloud/config.yaml: Pull configurations from your sysdigcloud-config configmap to the downloaded sysdigcloud/config.yaml.

                  The following variables are mandatory for Sysdig installations:

                  api.url
                  collector.endpoint
                  sysdigcloud.license
                  

                  The following variables are optional but commonly modified for Sysdig installations:

                  cassandra.jvm.options
                  elasticsearch.jvm.options
                  sysdigcloud.jvm.api.options
                  sysdigcloud.jvm.collector.options
                  sysdigcloud.jvm.worker.options
                  

                  If you have modified the previous config.yaml, copy the modified options such as the external endpoints. You must also check deployment YAML files for CPU/memory settings.

                • Copy configurations from your existing deployment and update the spec.replicas definition in the following files:

                  • sysdigcloud/api-deployment.yaml

                  • sysdigcloud/collector-deployment.yaml

                  • sysdigcloud/worker-deployment.yaml

                • If running Sysdig Secure:

                  Please do not edit the image: property.

                  • sysdigcloud/anchore-core-config.yaml

                  • sysdigcloud/anchore-worker-config.yaml

                  • sysdigcloud/anchore-core-deployment.yaml

                  • sysdigcloud/anchore-worker-deployment.yaml

                  • sysdigcloud/scanning-api-deployment.yaml

                  • sysdigcloud/scanning-alertmgr-deployment.yaml

                Postgres File (if running Sysdig Secure)

                Update the following file with customizations from your existing environment:

                Please do not edit the image: property.

                • Modify the storage class name, spec.volumeClaimTemplates[].spec.storageClassName in the datastores/as_kubernetes_pods/manifests/postgres/postgres-statefulset.yaml file.

                Elasticsearch and Cassandra Files

                In version 2.3.0, Elasticsearch and Cassandra yaml configurations have been updated. Update the new files with customizations from your existing environment.

                Please do not edit the image: property.

                • elasticsearch-statefulset.yaml - For example, your environment may have customized the values for the number of replicas, resource constraints, amount of storage, and the storage class name:

                  spec.replicas and spec.template.spec.containers[elasticsearch].env[ELASTICSEARCH_GOSSIP_NODES_NUM].value
                  spec.template.spec.containers[].resources
                  spec.volumeClaimTemplates[].spec.resources.requests.storage
                  spec.volumeClaimTemplates[].spec.storageClassName
                  
                • cassandra-statefulset.yaml - As with Elasticsearch, your environment may have customized the values for the number of replicas, resource constraints, amount of storage, and the storage class name:

                  spec.replicas
                  spec.template.spec.containers[].resources
                  spec.volumeClaimTemplates[].spec.resources.requests.storage
                  spec.volumeClaimTemplates[].spec.storageClassName
                  

                Apply the Files

                Run the kubectl commands to apply the relevant files to your cluster.

                Note: if you run into an error replacing the statefulsets, you may need to delete the existing one before applying the new configuration. See the Statefulset Deletion and Creation section below.

                Upgrade for Sysdig Monitor

                NAMESPACE=sysdigcloud
                kubectl -n $NAMESPACE apply -f sysdigcloud/config.yaml
                kubectl -n $NAMESPACE apply -f sysdigcloud/api-deployment.yaml
                kubectl -n $NAMESPACE apply -f sysdigcloud/collector-deployment.yaml
                kubectl -n $NAMESPACE apply -f sysdigcloud/worker-deployment.yaml
                kubectl -n $NAMESPACE replace -f datastores/as_kubernetes_pods/manifests/elasticsearch/elasticsearch-statefulset.yaml
                kubectl -n $NAMESPACE replace -f datastores/as_kubernetes_pods/manifests/cassandra/cassandra-statefulset.yaml
                

                Upgrade for Sysdig Secure

                kubectl -n $NAMESPACE apply -f sysdigcloud/anchore-core-config.yaml
                kubectl -n $NAMESPACE apply -f sysdigcloud/anchore-worker-config.yaml
                kubectl -n $NAMESPACE apply -f sysdigcloud/anchore-core-deployment.yaml
                kubectl -n $NAMESPACE apply -f sysdigcloud/anchore-worker-deployment.yaml
                kubectl -n $NAMESPACE apply -f sysdigcloud/scanning-alertmgr-service.yaml
                kubectl -n $NAMESPACE apply -f sysdigcloud/scanning-api-deployment.yaml
                kubectl -n $NAMESPACE apply -f sysdigcloud/scanning-alertmgr-deployment.yaml
                kubectl -n $NAMESPACE apply -f datastores/as_kubernetes_pods/manifests/postgres/postgres-statefulset.yaml
                

                Statefulset Deletion and Creation

                If you are unable to update the existing statefulsets with the commands above, you may need to delete them before applying the new configuration.

                # Elasticsearch
                kubectl -n $NAMESPACE delete statefulset sysdigcloud-elasticsearch
                kubectl -n $NAMESPACE apply -f datastores/as_kubernetes_pods/manifests/elasticsearch/elasticsearch-statefulset.yaml
                
                # Cassandra
                kubectl -n $NAMESPACE delete statefulset sysdigcloud-cassandra
                kubectl -n $NAMESPACE apply -f datastores/as_kubernetes_pods/manifests/cassandra/cassandra-statefulset.yaml
                
                # Postgres (if running Sysdig Secure)
                kubectl -n $NAMESPACE delete statefulset sysdigcloud-postgresql
                kubectl -n $NAMESPACE apply -f datastores/as_kubernetes_pods/manifests/postgres/postgres-statefulset.yaml
                

                Replace Existing Statefulset Pods

                The replace command above only replaces the Kubernetes configuration, but not the running pods themselves. For the changes to take effect, perform the following steps:

                1. For Elasticsearch, run:

                  kubectl -n $NAMESPACE delete pod -l role=elasticsearch
                  kubectl -n $NAMESPACE delete pod -l role=cassandra
                  # If running Sysdig Secure
                  kubectl -n $NAMESPACE delete pod -l role=postgresql
                  
                2. Check that all the new pods come up Ready by running the commands below separately:

                  kubectl -n $NAMESPACE get pod -l role=elasticsearch
                  kubectl -n $NAMESPACE get pod -l role=cassandra
                  # If running Sysdig Secure
                  kubectl -n $NAMESPACE get pod -l role=postgresql
                  

                  This may take a few minutes.

                6 -

                Manual Upgrade (v2435)

                As of August 2020, Sysdig has changed its upgrade procedure.

                All on-premises installations and upgrades are now scheduled with and guided by Sysdig technical account managers and professional services division. See Oversight Services Now Offered for All Installs and Upgrades .

                For customers, the instructions in this section are for review purposes only.

                Sysdig platform on-premise releases are listed here. Each release has a version number and specific Release Notes.

                Sysdig On-Premise version 2435 replaces v2304, v2266, and v2172. Versions 2304 and 2266 are hotfix releases. Version 2172 is a major release.

                Sysdig On-Premise version 2435 includes the following changes:

                • Dashboards upgraded from v1 to v2: This update happens automatically.

                  However, if you have saved v1 dashboards and need to reapply them, follow these instructions: Migrate Saved Dashboards from V1 to V2.

                • Architecture Change in the ContainersIn previous releases, there was a single backend container which ran several processes.

                  As of version 2435, the processes have been divided into unique containers, following container best practices.

                  As a result, it is necessary to apply the entire configuration, not simply change the image version. Follow the instructions below.

                Contents

                If you have licensed and will run only Sysdig Monitor, then you upgrade fewer components than if you also use Sysdig Secure, as described below.

                Download the New Version

                Use get to download the new version from Sysdig’s GitHub and unzip it.

                For example:

                wget https://github.com/draios/sysdigcloud-kubernetes/archive/<version_number>.tar.gz &&  tar xvf <version_number>.tar.gz
                

                Edit New Files to Match Your Customized Files

                Edit the following files within the sysdigcloud directory to match any customizations you may have made in your existing production system.

                config.yaml

                Edit the Sysdig user name, default user, API URL, Sysdig license, collector endpoint, from your config.yaml to the new config.yaml .

                sysdigcloud.default.user: test@sysdig.com
                collector.endpoint: onprem.sysdigcloud.com
                collector.port: "6443"
                api.url: https://onprem.sysdigcloud.com:443
                

                deployment YAML files

                Edit the CPU limits and replicas in the deployment YAML files: api-deployment.yaml, collector-deployment.yaml, worker-deployment.yaml

                Note that the values in the sample below are examples only; edit them to match the requirements of your deployment.

                spec:
                 replicas: 1
                
                ....
                
                resources:
                  limits:
                    cpu: "4"
                    memory: 4Gi
                  requests:
                    cpu: "1"
                    memory: 1G
                

                Apply the Files

                Run the kubctl commands to apply the relevant files to the environment.

                This upgrade updates dashboards from v1 to v2. The process requires 20-30 minutes on large systems, and the environment remains live throughout the rolling upgrade.

                DO NOT create or delete dashboards during the upgrade.

                After upgrading, if you have saved v1 dashboards previously and need to upload them to the v2 environment, see Migrate Saved Dashboards from V1 to V2.

                Upgrade for Sysdig Monitor Only

                kubectl -n sysdigcloud apply -f config.yaml
                kubectl -n sysdigcloud apply -f api-deployment.yaml
                kubectl -n sysdigcloud apply -f collector-deployment.yaml
                kubectl -n sysdigcloud apply -f worker-deployment.yaml
                

                Upgrade for Sysdig Monitor + Sysdig Secure

                kubectl -n sysdigcloud apply -f config.yaml
                kubectl -n sysdigcloud apply -f api-deployment.yaml
                kubectl -n sysdigcloud apply -f collector-deployment.yaml
                kubectl -n sysdigcloud apply -f worker-deployment.yaml
                kubectl -n sysdigcloud apply -f scanning-api-deployment.yaml
                kubectl -n sysdigcloud apply -f scanning-alertmgr-deployment.yaml
                
                

                7 -

                Basic Upgrade (Replicated)

                Support for new Replicated installations will be deprecated in the coming months. Feel free to contact Sysdig Support with questions.

                Non-Airgapped Installation

                Upgrading is very simple when your environment has access to the Internet during the installation process (non-airgapped).

                It is highly recommended to follow upgrade best practices:

                • Keep upgrades current

                • Upgrade progressively without skipping versions, and

                • Test upgrades in a non-mission-critical or staging environment before rolling in to production.

                Review the On-Premises Upgrades for supported upgrade paths.

                Upgrade Replicated Components

                Check Current Version

                The Replicated infrastructure installs its own container based agents that deploy and manage the various Sysdig back-end components. To confirm the currently running version of the Replicated agent, perform replicated --version at the command line on each host. [Reference Replicated.com]

                Upgrade Replicated Client

                1. Log in to the Replicated Management Console and stop the Sysdig application (Sysdig Monitor and Sysdig Secure, if applicable) before upgrading the Replicated client.

                2. Run the following command on the management host to upgrade the replicated infrastructure:

                  sudo curl -sSL https://get.replicated.com/docker | sudo bash
                  
                3. Run the following command on the remaining nodes in the cluster:

                  sudo curl -sSL https://get.replicated.com/operator | sudo bash
                  

                Upgrade Sysdig Application

                Installation Sequence:

                • Pre-Version 860: Install upgrades sequentially, one version at a time.

                • Version 860 - 1091: You can directly install the version you want.*

                • Version 1091 - Sept 2018 release: All users must upgrade from 1091 - Sept 2018 and run the Unified Events migration tool.

                • Version 2266: See Note, below.

                *Sequential installs (even when not strictly required) ensure consistent database migrations and allow for easier troubleshooting, should problems occur. Sysdig recommends staying fairly up-to-date on the release cycle to avoid “stacking up” upgrades.

                1. Log in to the Replicated Management Console > Dashboards.

                2. Click View Update.

                  The release history is listed, and “New” for any new releases.

                3. Click Install for the desired release.

                Upgrades to version 2304

                After upgrading to version 2304, you must add a node for emailrenderer and nginxfrontend to the replicated cluster, and then run a command on the node.

                • Private and Public IP Addresses: Provide the IPs where the containers will run.

                • Select emailrenderer and nginxfrontend.

                • Run the curl command as noted in the image above, including the optional parameters as needed for your environment.

                Airgapped Installation

                Upgrade Replicated Components

                Check Current Version

                The Replicated infrastructure installs its own container based agents that deploy and manage the various Sysdig back-end components. To confirm the currently running version of the Replicated agent, perform replicated --version at the command line on each host. See also Replicated.com.

                Upgrade Replicated Client

                1. Download the latest Replicated agent installation package:

                  curl https://s3.amazonaws.com/replicated-airgap-work/replicated.tar.gz > replicated.tar.gz
                  
                2. In a command shell, extract the Replicated installer:

                  sudo tar xzvf replicated.tar.gz
                  
                3. Run the ‘install.sh’ script on the management host:

                  sudo cat ./install.sh | sudo bash -s airgap
                  
                4. Run the ‘operator_install.sh’ script on all remaining nodes:

                  sudo cat ./operator_install.sh | sudo bash -s airgap
                  

                Upgrade Sysdig Application

                1. Download the new Sysdig application .airgap installer, using the link and password supplied for the initial installation.

                2. Copy the .airgap file to the update directory on the management host.

                  To check or configure the update path, log in to the Replicated Management Console and click Console Settings > Airgapped Settings section under the gear icon.

                3. In the Replicated Management Console, select the Dashboard tab and click Check Now.

                4. Click Install for the desired version.