Kubernetes Upgrades in SAP Integration Suite, Advanced Event Mesh

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 advanced event mesh, SAP 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 SAP Integration Suite, Advanced Event Mesh
• Deprecation of Support for Kubernetes Versions
• Kubernetes Adoption Policy Frequently Asked Questions

Upgrading Kubernetes Clusters to New Versions

When SAP 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

SAP either notifies or contacts you based your deployment type:

Deployment Type	Notification Policy
Public Region	SAP notifies you before a scheduled upgrade, typically 14 days in advance.
Dedicated Region	You can proactively schedule a Kubernetes cluster upgrade via Calendly; otherwise, SAP 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:

• SAP upgrades the cluster within 180 days of either the end of support for, or end of life of, the current Kubernetes version.
• SAP upgrades the cluster to the latest supported version of Kubernetes for which we have validated a provider or distribution.
• SAP 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 SAP to schedule an upgrade. For more information, see Upgrading Event Broker Services .

Cluster Upgrade Impact to Event Broker Services

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

• For standard 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, SAP 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. SAP fully supports these newer Kubernetes deployments.

SAP validates new Kubernetes versions against the event broker service version that is in full technical support, as defined in Version Adoption . 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.

SAP 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 SAP 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 SAP. the oldest supported version validated by SAP. For example, if the newest validated GKE version supported by SAP is 1.24 and the oldest is 1.21, then SAP 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	SAP 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, SAP 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. SAP maintains a table of Supported Kubernetes Version where you can see a summary of Kubernetes versions that we currently support.

SAP 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 SAP's Kubernetes Adoption Policy for advanced event mesh.

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

SAP 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 SAP will contact you to schedule it.

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

SAP 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, SAP 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:

• Standard class may experience downtime of approximately 15 minutes.
• 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 .

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?

SAP 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 advanced event mesh. These deployments may require additional time to complete, tune, and configure. SAP fully supports these newer Kubernetes deployments, but additional time is required to resolve issues.