Kubernetes Upgrades in Solace Cloud

Kubernetes releases new versions at a specific cadence. The Kubernetes providers and distributions release their implementations on their own schedules. New Kubernetes versions can introduce or remove APIs and features and include security and bug fixes.

Solace has a Kubernetes Adoption Policy for Solace Cloud, that defines the process for testing, validating, and adopting Kubernetes versions from a set list of providers and distributions. This policy outlines:

• Upgrading Kubernetes Clusters to New Versions
• Kubernetes Provider Categories and Validation
• Kubernetes Upgrades in Solace Cloud
• Deprecation of Support for Kubernetes Versions
• Kubernetes Adoption Policy Frequently Asked Questions

Upgrading Kubernetes Clusters to New Versions

When Solace validates a new version of Kubernetes, we schedule cluster upgrades according to the type of deployment you are using. This section explains:

• How we notify you when an upgrade is required. See Upgrade Notifications.
• When upgrades happen, what version we upgraded you to, and how often we perform cluster upgrades. See Upgrading Public Clusters and Dedicated Clusters.
• Responsibilities for Upgrading Customer-Controlled Clusters.
• What impact you can expect to your event broker services during the cluster upgrade. See Cluster Upgrade Impact to Event Broker Services.

Upgrade Notifications

Solace either notifies or contacts you based your deployment type:

Deployment Type	Notification Policy
Public Cluster	Solace notifies you before a scheduled upgrade, typically 14 days in advance.
Dedicated Cluster	Solace sends several email notifications at specific intervals before a Kubernetes version reaches its end of support date, as defined by our primary providers. Solace encourages you to proactively schedule a Kubernetes cluster upgrade before the end of support date. Solace sends you the following notifications: 90-Day Notification: A first reminder that the Kubernetes version is approaching end-of-support. 30-Day Notification: A second reminder that the Kubernetes version is approaching its end of support date. 15-Day Notification: A final reminder, advising you to schedule an upgrade for your Kubernetes version as soon as possible. If you don't respond to this reminder, Solace upgrades your Kubernetes version in an available maintenance window of our choosing, after the Kubernetes version reaches end of support. All notifications include an explanation of why the upgrade is necessary, a link to the Private Regions tab of the Cloud Console where you can schedule an upgrade, upgrade downtime and service impact information, and a link to contact Solace. You can also view the end of support date for a Kubernetes version on the Private Regions tab of the Cloud Console.
Customer-Controlled Cluster	Maintenance of clusters in Customer-Controlled Clusters is your responsibility. See Upgrading Customer-Controlled Clusters.

Upgrading Public Clusters and Dedicated Clusters

Kubernetes cluster upgrades of Public Clusters and Dedicated Clusters apply to the Kubernetes providers listed in the primary category, as outlined in Kubernetes Provider Categories and Validation. For both Public Clusters and Dedicated Clusters, the upgrade policies are below:

• For Public Clusters, Solace upgrades the cluster within 180 days of the end of support for the current Kubernetes version.
• For Dedicated Clusters, Solace begins sending you notifications to schedule a cluster upgrade 90 days before the end of support for a Kubernetes version. You must schedule cluster upgrades before the version's end of support date. You can view Kubernetes versions and schedule upgrades from the Private Regions tab of the Cloud Console.
• Solace upgrades the cluster to the latest supported version of Kubernetes for which we have validated a provider or distribution.
• Solace performs up to two Kubernetes upgrades within a 12-month period. Exceptions to this may occur due to security and stability patch reviews. See Support for Security and Stability Updates.

Upgrading Customer-Controlled Clusters

In Customer-Controlled Clusters, you are responsible for keeping the Kubernetes cluster up-to-date, but Solace does offer a recommended Kubernetes cluster upgrade process to ensure minimum Messaging Connectivity downtime. Before upgrading your cluster, you must ensure your Kubernetes cluster version and your event broker service version are compatible. For more information about version compatibility, see Supported Kubernetes Versions. If your event broker services need to be upgraded before you upgrade your Kubernetes cluster, contact Solace to schedule an upgrade. For more information, see Upgrading Event Broker Services in Solace Cloud.

Recommended Kubernetes Cluster Upgrade Process for High Availability Event Broker Services

Upgrading your Customer-Controlled Cluster is your responsibility. You can choose to upgrade your cluster as you like. While event broker services are resilient to Kubernetes upgrades, Solace recommends following a suggested upgrade process to keep any Messaging Connectivity downtime to a minimum, by limiting message node switchovers to one.

When upgrading your Customer-Controlled Cluster, Solace strongly recommends following:

• Kubernetes best-practices by upgrading nodes individually

• our best-practice cluster upgrade process, using the Solace Event Broker CLI show redundancy command to review the status of your event broker service during each step of a Kubernetes cluster upgrade

Use the following steps to upgrade your Customer-Controlled Cluster using our best-practices:

1. Using the Cloud Console, enable the Solace Event Broker CLI.

2. Access the CLI for the event broker service.

3. From the CLI, run the show redundancy command.

   Verify all event broker service nodes are healthy and redundancy is operational. The command should show Redundancy Status: Up. If redundancy status does not display Up, stop the cluster upgrade and contact Solace.

4. If the event broker service is healthy, upgrade the monitoring node first.

5. After the monitoring node has upgraded, from the CLI, run the show redundancy command.

   Verify all event broker service nodes are healthy and redundancy is operational. The command should show Redundancy Status: Up. If redundancy status does not display Up, stop the cluster upgrade and contact Solace.

6. If the event broker service is healthy, upgrade the backup node.

7. After the backup node has upgraded, from the CLI, run the show redundancy command.

   Verify all event broker service nodes are healthy and redundancy is operational. The command should show Redundancy Status: Up. If redundancy status does not display Up, stop the cluster upgrade and contact Solace.

8. In the Cloud Console, use the High Availability Switchover for Event Broker Services to switch the active node of your event broker service.

9. Upgrade the formerly active node, which is now the backup node for your event broker service.

10. After the backup node (formerly active) has upgraded, from the CLI, run the show redundancy command.

    Verify all event broker service nodes are healthy and redundancy is operational. The command should show Redundancy Status: Up. If redundancy status does not display Up, stop the cluster upgrade and contact Solace.

Cluster Upgrade Impact to Event Broker Services

During a cluster upgrade, there may be some downtime for your event broker service:

• For standalone and developer class event broker services, you may experience up to 15 minutes of downtime.

• For high availability (HA) class event broker services, you can expect switching of activity between the event broker services, which may lead to an interruption of less than one minute. HA event broker services use a PodDisruptionBudget that ensures that there is always a healthy event broker service that can carry traffic. If the upgrade is done in an uncontrolled way, there may be up to two failovers. To reduce failovers to just one in Customer-Controlled Cluster, use our recommended cluster upgrade process.

Support for Security and Stability Updates

This policy applies to security and patch releases for all Kubernetes providers and distributions. See Releases in the Kubernetes documentation for an explanation of how to determine a Kubernetes release type.

Evaluation of the stability and security impacts of Kubernetes patch releases on Public Clusters and Dedicated Clusters occurs within 30 days. If the evaluation determines that an upgrade is required, Solace contacts you to schedule an upgrade outside the regular upgrade schedule.

Kubernetes Provider Categories and Validation

Validation and testing occur on different schedules based on which group the provider or distribution falls into. The following table lists the providers and distributions in each group.

Category	Provider or distribution supplier	Validation Time Frame
Primary	Amazon Elastic Kubernetes Service (EKS) Azure Kubernetes Service (AKS) Google Kubernetes Engine (GKE)	Within 90 days of the vendor’s release.
Other	Azure Red Hat OpenShift (ARO) Alibaba Cloud Container Service for Kubernetes (ACK) Anthos GKE on AWS (Controlled Availability) see note Canonical Charmed (Controlled Availability) see note EKS on AWS Outposts (Controlled Availability) see note Huawei Cloud Container Engine (CCE) Oracle Kubernetes Engine (OKE) (Controlled Availability) see note RedHat OpenShift (OCP) Rancher (RKE2) VMware Tanzu Kubernetes Grid (TKG)	Within 180 Days of the vendor’s release.

Kubernetes distributions/providers in Controlled Availability may require additional time, tuning, and configuration for deployments. Solace fully supports these newer Kubernetes deployments.

Solace validates new Kubernetes versions against the event broker service version that is in full technical support, as defined in Version Adoption in Solace Cloud. See Supported Kubernetes Versions for a complete list of supported versions.

Providers may have varying names for their releases. For example, AKS terms a release Generally Available (GA), while GKE refers to a release as a regular channel release. Refer to the provider or distribution release documentation for more information.

Solace does not recommend the adoption of any Kubernetes version before we have validated its compatibility with event broker versions that are currently in full technical support.

Whenever Solace releases a major event broker service version (for example 10.25.0), we validate its support on the various Kubernetes providers and distributions according to the following schedule:

Event Broker Service Release Date	Support Level for Major Event Broker Service
Day of release	Support for the primary Kubernetes providers and distributions includes: the newest version validated by Solace. the oldest supported version validated by Solace. For example, if the newest validated GKE version supported by Solace is 1.34 and the oldest is 1.32, then Solace validates the new event broker service release for both GKE 1.32 and 1.34. See Supported Kubernetes Versions for a complete list of supported versions.
90 days after release	Solace validates Kubernetes providers and distributions that were not validated on the day of the major event broker service within 90 days.

Deprecation of Support for Kubernetes Versions

When a Kubernetes provider or distribution ends support for a version of Kubernetes, referred to as End Of Life (EOL) by some providers, Solace also ends support for that Kubernetes version. You should refer to the documentation and support policies for your chosen provider or distribution for details about the end of support for your chosen Kubernetes implementation. Solace maintains a table of Supported Kubernetes Version where you can see a summary of Kubernetes versions that we currently support.

For Dedicated Clusters, automated notifications are based on the cloud provider's official end of support calendar for each of the primary Kubernetes providers. The automated notification system tracks these dates and sends notifications at 90, 30, and 15 days before end-of-support, as described in Upgrade Notifications.

Solace reserves the right to deprecate support for particular Kubernetes versions at other times. Reasons for deprecation can include:

• a lifecycle support policy change from a Kubernetes provider or distribution.
• a need to drop compatibility with APIs that are out-of-date.

Kubernetes Adoption Policy Frequently Asked Questions

Below you will find answers to typically asked questions you may have about the Solace Kubernetes Adoption Policy for Solace Cloud.

If I deploy to a Public Cluster, how does the Kubernetes Adoption Policy impact me?

Solace determines an upgrade schedule and informs you of the maintenance window.

If I deploy to a Dedicated Cluster, how does the Kubernetes Adoption Policy impact me?

You receive automated email notifications at 90, 30, and 15 days before your cluster reaches its end of support date. For more information, see Upgrade Notifications. You can proactively schedule a Kubernetes version upgrade using the Cloud Console.

What if I don't schedule an upgrade for my cluster in a Dedicated Cluster in time?

If the Kubernetes version for your cluster reaches its end of support date without a scheduled upgrade, it becomes unsupported by both the cloud provider and Solace. If you don't schedule an upgrade at this point, Solace will schedule an upgrade in the next available maintenance window, as running an end-of-support Kubernetes version creates security vulnerabilities and support challenges.

If I deploy to a Customer-Controlled Cluster, how does the Kubernetes Adoption Policy impact me?

Keeping the Kubernetes cluster up to date is your responsibility. Your event broker service must support the Kubernetes version hosting it, as outlined in Supported Kubernetes Versions.

When I upgrade my cluster in a Customer-Controlled Cluster, are there any coordination activities required?

No. Upgrading your Customer-Controlled Cluster Kubernetes cluster is your responsibility.

What if I don't upgrade the cluster in a Customer-Controlled Cluster before Kubernetes support expires?

If you haven’t upgraded your cluster before the Kubernetes provider ends support for that version of Kubernetes, then the provider may not continue to offer support for any Kubernetes based issues you encounter until after you have upgraded the cluster.

Is there a recommended way to upgrade my Customer-Controlled Cluster?

Yes. Solace provides a recommended upgrade process for HA event broker services that minimizes interruptions to Messaging Connectivity.

What is the impact to my event broker services during a Kubernetes upgrade?

The impact on your event broker services depends on its service class:

• Enterprise-100 Standalone and standalone classes may experience downtime of approximately 15 minutes.
• HA class event broker services may have an interruption of less than a minute, which accounts for the switching of activity between the event broker services.

How can I prepare for my Kubernetes cluster upgrade?

You can ensure your event broker service is up to date and is a version that is supported on the Kubernetes version you are upgrading to. For details about upgrading your event broker services, see Upgrading Event Broker Services in Solace Cloud.

How can I view my scheduled upgrade date for a Dedicated Cluster?

For Dedicated Clusters, your scheduled upgrade date is visible on the Private Regions tab of the Cloud Console. The Private Region tab allows you to track when your Kubernetes version is scheduled for an upgrade and plan accordingly.

What is pre-upgrade validation?

Before sending upgrade notifications for Dedicated Clusters, Solace performs automated pre-upgrade validation checks to ensure your cluster is in a healthy state for upgrade. These checks include node pool health, resource availability, and configuration validation. If validation issues are detected, Solace works to resolve them before proceeding with notifications.

What information is included in the upgrade notification emails?

Each automated notification email for Dedicated Clusters includes: a clear explanation of why the upgrade is necessary, a direct link to schedule the upgrade on the Private Regions tab of the Cloud Console, expected downtime and service impact information, and information to contact Solace.

Can I upgrade my Kubernetes cluster on the same day as my event broker services?

For Dedicated Cluster customers, no. Solace cannot perform consecutive event broker service and Kubernetes (or vice-versa) upgrades. You must upgrade your Kubernetes cluster and event broker service upgrades on separate days.

For customers with Customer-Controlled Clusters, Solace strongly recommends against performing Kubernetes cluster upgrades on the same day as event broker service upgrades.

How long is the maintenance window for a Kubernetes cluster upgrade?

The maintenance window for the cluster upgrade can be up to six hours.

When does support for a Kubernetes version end?

Solace ends support for a Kubernetes version when the provider ends their support for it. In certain situations, we may end support earlier.

Why are some Kubernetes versions listed as Controlled Availability?

Kubernetes distributions or providers that are in Controlled Availability are early in the Kubernetes adoption process for Solace Cloud. These deployments may require additional time to complete, tune, and configure. Solace fully supports these newer Kubernetes deployments, but additional time is required to resolve issues.