Kubernetes Upgrades in PubSub+ 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.

For PubSub+ Cloud, Solace has a Kubernetes Adoption Policy 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

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

Upgrade Notifications

Solace either notifies or contacts you based your deployment type:

Deployment Type Notification Policy

Public Region

Solace notifies you before a scheduled upgrade, typically 14 days in advance.

Dedicated Region

Solace contacts you to ask that you schedule an upgrade.

Customer-Controlled Region

Maintenance of clusters in Customer-Controlled Regions is your responsibility. See Upgrading Customer-Controlled Regions.

Upgrading Public Regions and Dedicated Regions

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

  • Solace upgrades the cluster within 180 days of either the end of support for, or end of life of, the current Kubernetes version.
  • 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 Regions

In Customer-Controlled Regions, you are responsible for keeping the Kubernetes cluster up-to-date. Your Kubernetes cluster version and your event broker service version must be 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 PubSub+ Cloud.

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.

    In Customer-Controlled Regions, if you want to ensure only a single failover, you can drain worker nodes that host the event broker service’s pods in this order: monitor, non-active, then active. For more information, see Safely Drain a Node.

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 Regions and Dedicated Regions 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)
  • RedHat OpenShift (OCP)
  • Rancher (RKE1)
  • 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 PubSub+ 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.2), 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.24 and the oldest is 1.21, then Solace validates the new event broker service release for both GKE 1.21 and 1.24. 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.

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 Solace's Kubernetes Adoption Policy for PubSub+ Cloud.

If I deploy to a Public Region, 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 Region, how does the Kubernetes Adoption Policy impact me?

Solace contacts you to ask that you schedule an upgrade.

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

Solace expects a response to an upgrade request within five to seven business days. If we do not receive a response, we will attempt to contact you again. If you do not respond to the second request, Solace notifies you that an upgrade is to occur on a specified date. We also outline the potential risks associated with this forced upgrade.

If I deploy to a Customer-Controlled Region, 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 Region, are there any coordination activities required?

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

What if I don't upgrade the cluster in a Customer-Controlled Region 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.

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:

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 PubSub+ Cloud.

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