On-Premises Upgrades

• 1: Installer Upgrade (3.5.0-3.5.1)
• 2: Installer Upgrade (2.5.0+)
• 3: Manual Upgrade (3.0.0+)
• 4: Manual Upgrade (2.4.1- 2.5.0)
• 5: Manual Upgrade (2.3.0)
• 6: Manual Upgrade (v2435)
• 7: Basic Upgrade (Replicated)

1 - Installer Upgrade (3.5.0-3.5.1)

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

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:

• Quickstart Install

• Airgapped with Installation Machine

• Full Airgap Install

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

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

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.

4. • 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

-   **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.

5. 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
   

6. 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.

7. 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.

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

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

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.

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

Sysdig Cloud Files

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:

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

• 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.

• 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

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.

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.

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

Sysdig Cloud Files

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:

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

• 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.

• 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.

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

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.

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)

Non-Airgapped Installation

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

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.