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
- Kubernetes Provider Categories and Validation
- Kubernetes Upgrades in PubSub+ 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 Regions and Dedicated Regions.
- Responsibilities for Upgrading Customer-Controlled Regions.
- 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 Region |
Solace notifies you before a scheduled upgrade, typically 14 days in advance. |
|
Dedicated Region |
You can proactively schedule a Kubernetes cluster upgrade via Calendly; otherwise, Solace will contact you to schedule it. |
|
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
-
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
PodDisruptionBudgetthat 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 |
|
Within 90 days of the vendor’s release. |
|
Other |
|
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:
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?
-
You can proactively schedule a Kubernetes cluster upgrade using Calendly, otherwise Solace will contact you to schedule it.
- 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:
-
- High-availability (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 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.