Upgrading the NextGen OpsRamp Gateway is a critical process that involves updating the existing Gateway environment to improve performance, introduce new features, address security vulnerabilities, and ensure compatibility with the latest technologies and operating systems. Keeping your OpsRamp Gateway up to date is essential for maintaining system stability, leveraging recent enhancements, and receiving ongoing support. This guide outlines the upgrade types, supported versions, and recommended upgrade paths.

Types of Gateway Upgrades

OpsRamp offers two types of Gateway Upgrades, and the upgrade process may vary based on the type:

1. Gateway Application Upgrade
   Involves updating the Gateway software along with applying necessary OS patches and security updates without replacing the underlying appliance or server. This method retains your current infrastructure while bringing the application environment up to date.
2. Gateway Appliance Upgrade
   Entails replacing the existing appliance entirely with a new, updated appliance that includes the latest OS, patches, and Gateway software. This is a clean-slate approach, often used for major version changes or to ensure complete compatibility with new system requirements.

Upgrade Paths

Use the following table to determine the correct upgrade path based on your current version and deployment type. Following the recommended path ensures a seamless and supported transition to the latest release.

Supported Operating Systems

Compatibility with the correct operating system is crucial for successful installation and performance. Below are the supported OS versions for each Gateway release:

Known Behavior: Gateway Upgrade Impact on Multi-Tenant Cluster Deployments

In multi-tenant environments where multiple Gateways are deployed within a single Kubernetes cluster (each in separate namespaces), upgrading one Gateway can have implications beyond the individual namespace.

Cluster-Level Impact

When an upgrade is performed on any single Gateway (e.g., gateway-1), the upgrade process will include shared infrastructure components that are common across the cluster. This includes:

• Operating System (OS) patches
• K3s Kubernetes runtime
• Longhorn storage
• MetalLB, etc

These components are centralized and shared by all Gateways within the cluster. As a result, upgrading one Gateway will update these core services for all Gateways in the cluster.

Application-Level Impact

• The application components (e.g., nextgen-gw, webprobe, squid-proxy, redis, third-party apps) are namespace-scoped and tied to their respective Gateway instance.
• Only the application pods related to the upgraded Gateway (e.g., gateway-1) will be updated to the new version.
• The application versions of the remaining Gateways (e.g., gateway-2 to gateway-5) will remain unchanged.

Potential Side Effects
Even though other Gateways' application pods are not upgraded, their runtime environment may still be affected due to the upgrade of shared cluster components:

• Connectivity issues may occur temporarily due to changes in K3s, Longhorn, or MetalLB.
• Pods belonging to non-upgraded Gateways may restart or reschedule to different nodes during the process.

Example Scenario

Suppose a customer has deployed 5 Gateways in the same cluster:

• gateway-1, gateway-2, gateway-3, gateway-4, gateway-5
• Each Gateway is deployed in its own Kubernetes namespace

If the customer initiates an upgrade on gateway-1:

• The core components (OS, K3s, Longhorn, MetalLB) will be upgraded at the cluster level, affecting all Gateways
• The application version for gateway-1 will be updated
• The application versions for gateway-2 to gateway-5 will remain unchanged
• However, pods for the other Gateways may restart, reschedule, or experience brief connectivity issues due to shared infrastructure changes

Recommendation:

Customers should plan Gateway upgrades carefully in multi-tenant clusters. Consider scheduling upgrades during a maintenance window and notify stakeholders of the potential impact to shared services and pod stability for all Gateways within the cluster.