Merge pull request #10217 from zlogic/DES-7101_release-mxok-2.24.0

Release notes and documentation for Mx4PC/MxOK 2.24.0 (planned for release on October 20)

Author: katarzyna-koltun-mx

content/en/docs/deployment/private-cloud/private-cloud-operator.md

@@ -170,11 +170,15 @@ spec:
       azure.workload.identity/use: "true" # Example: enable Azure Workload Identity
   runtimeLicenseProduct: # Optional: Specify the type of product required for the Runtime License. This is applicable when PCLM is used for licensing. By default, the value is set to Standard, if left empty
   deploymentStrategy: # Optional: Specify a deployment strategy to reduce app downtime
-    type: PreferRolling
     switchoverThreshold: 50%
     rollingUpdate:
       maxSurge: 0
       maxUnavailable: 50%
+  podDisruptionBudget: # Optional: Specify a pod disruption budget to reduce app downtime
+    # Kubernetes doesn't allow specifying both maxUnavailable and minAvailable at the same time:
+    # https://kubernetes.io/docs/tasks/run-application/configure-pdb/#specifying-a-poddisruptionbudget
+    maxUnavailable: 2 # Example: do not disrupt more than 2 pods at the same time
+    # minAvailable: 50% # Example: make sure that at least 50% of pods are available
   runtimeReadOnlyRootFilesystem: true # Optional: specify if the Mendix Runtime container should use a read-only root filesystem
 ```
 
@@ -235,7 +239,8 @@ You must make the following changes:
     * `leaderless` - A mode where the nodes dynamically choose a leader. This feature is in preview mode. It requires Mendix Runtime 10.24 or newer, and Mendix Operator 2.23 or newer.
 * **customPodLabels** - Specify additional pod labels. Avoid using labels that start with the `privatecloud.mendix.com/` prefix.
     * **general** - Specify additional labels for all pods of the app.
-* **deploymentStrategy** - Specify parameters for the deployment strategy. For more information, see the reduced downtime deployment documentation.
+* **deploymentStrategy** - Specify parameters for the deployment strategy. For more information, see the [reduced downtime deployment](/developerportal/deploy/private-cloud-reduced-downtime/#deployment-strategy-in-standalone) documentation.
+* **podDisruptionBudget** - Specify parameters for the pod disruption budget. For more information, see the [reduced downtime deployment](/developerportal/deploy/private-cloud-reduced-downtime/#pod-disruption-budget-in-standalone) documentation.
 * **runtimeReadOnlyRootFilesystem** - Specify if the Runtime container should mount the root filesystem in [read-only mode](/developerportal/deploy/private-cloud-cluster/#readonlyrootfs).
 
 #### Setting App Constants{#set-app-constants}

content/en/docs/deployment/private-cloud/private-cloud-supported-environments.md

@@ -36,7 +36,7 @@ If deploying to Red Hat OpenShift, you need to specify that specifically when cr
 
 Mendix on Kubernetes Operator `v2.*.*` is the latest version which officially supports:
 
-* Kubernetes versions 1.19 through 1.33
+* Kubernetes versions 1.19 through 1.34
 * OpenShift 4.6 through 4.19
 
 {{% alert color="warning" %}}

content/en/docs/deployment/private-cloud/reduced-downtime-deployment.md

@@ -6,27 +6,50 @@ weight: 35
 ---
 ## Introduction
 
-Kubernetes allows to update an app without downtime by [performing a rolling update](https://kubernetes.io/docs/tutorials/kubernetes-basics/update/update-intro/). Instead of stopping an app and then starting it with an updated version or configuration, Kubernetes can replace pods (replicas) one by one with an updated version. Existing pods handle requests until the newer version is fully started. Any changes in the [Data in the Domain Model](/refguide/domain-model/) need a database (schema) update. While the update process runs, you cannot modify any persistent entities.
+Kubernetes allows you to update an app without downtime by [performing a rolling update](https://kubernetes.io/docs/tutorials/kubernetes-basics/update/update-intro/). Instead of stopping an app and then starting it with an updated configuration, Kubernetes can replace pods (replicas) one by one.
 
-The Mendix on Kubernetes Operator uses a [recreate](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#recreate-deployment) strategy by default. That is, the current version (configuration) of an app stops, and then the new version starts. Alternatively, the Mendix on Kubernetes Operator can use a **PreferRolling** strategy. That is, the Operator tries to perform a rolling update whenever possible. If the Operator detects that a database schema update is needed, it switches to a Recreate strategy to perform a full restart. If the new version of the app has model changes, deploying it requires a schema update. In this case, the Mendix on Kubernetes Operator automatically stops all replicas of the app, causing downtime.
+The Mendix on Kubernetes Operator uses a [recreate](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#recreate-deployment) strategy by default. That is, the current version (configuration) of an app stops, and then the new version starts.
 
-This feature works with Mendix on Kubernetes version 2.20 and later.
+Starting from version 2.24.0, the Operator will automatically perform a Rolling update for any environment that meets the [prerequisites](#prerequisites-2.24.0):
+
+* The environment has two or more replicas.
+* The configuration update does not modify the app source code (MDA or container image).
+
+{{% alert color="info" %}}
+Versions 2.20.0 to 2.23.1 of the Operator had an option to manually enable a **PreferRolling** strategy. That is, the Operator tried to perform a rolling update whenever possible. If the Operator detected that a database schema update was needed, it switched to a Recreate strategy to perform a full restart. If the new version of the app had model changes, deploying it required a schema update. In that case, the Mendix on Kubernetes Operator automatically stopped all replicas of the app, causing downtime.
+{{% /alert %}}
+
+In addition Operator version 2.24.0 will automatically assign a PodDisruptionBudget to environments with 2 or more replicas. Any environment with two or more replicas will be configured with a PodDisruptionBudget that ensures that no more than 1 replicas are stopped by Kubernetes when scaling down a cluster node or preparing an OS upgrade.
+
+{{% alert color="info" %}}
+Previous versions of the Operator did not manage PodDisruptionBudgets. Instead, any manually created PodDisruptionBudget would apply to a Mendix app.
+
+If you have manually created PodDisruptionBudgets for an app, delete it and instead specify the PodDisruptionBudget parameters [in the MendixApp CR](#pod-disruption-budget-in-standalone).
+{{% /alert %}}
 
 ## Prerequisites
 
-You can enable the `PreferRolling` deployment strategy if your environment fulfills the following requirements:
+## Prerequisites for Operator version 2.24.0 and Higher{#prerequisites-2.24.0}
+
+The Operator automatically performs a Rolling update for any environment that meets the following conditions:
 
-* The app must have two or more replicas specified in the MendixApp CR or Developer Portal.
-* For Connected environments, the **Low Downtime Deployment Strategy** option must be enabled in the Cloud Portal.
-* For Standalone environments, **deploymentStrategy** must be set to **PreferRolling** in the MendixApp CR.
+* The environment has two or more replicas.
+* The configuration update does not modify the app source code (MDA or container image).
 
-If the app can be deployed without having to modify the database schema (model), it will now be deployed using a Rolling deployment strategy.
+{{% alert color="warning" %}}
+Mendix Operator versions 2.20.0 to 2.23.1 had an experimental feature that also performed database schema upgrades with a Rolling strategy. This feature was removed in Operator 2.24.0, as it does not work well with the latest Mendix Runtime security features.
+{{% /alert %}}
 
-## How a PreferRolling Strategy Works
+## How the Operator Chooses a Deployment Strategy
 
-When the Operator is configured to use a **PreferRolling** strategy, it will try to do an optimistic update and use a **Rolling** strategy. If the app needs to perform a database schema update, it signals to the Operator that it is waiting for approval to perform the update. The Operator then switches the app to use a **Recreate** strategy (stop all current replicas and start an updated version) and wait until all replicas of the app are running the same MDA version. Then, the Operator lets the app know that it is safe to update the database schema, and approve the process.
+If any of the following conditions is true, the Operator always uses a **Recreate** strategy, performing a full stop of all of the app's replicas:
 
-As a **Rolling** strategy can run multiple versions of the app at the same time, requests from the browser must be routed to a matching app version (that is, an app that has the same microflow or nanoflow parameters). The Operator uses Kubernetes service labels to perform an atomic switch, and instantly switch all clients to the updated version. This is done automatically once the number of updated replicas reaches a certain threshold. By default the threshold is 50% of all replicas. The value is specified in the [switchoverThreshold](#prefer-rolling-in-standalone) parameter.
+* There are app pods that are running a different (older) version of the app image: there are changes in the app MDA or base OS image.
+* The app environment has one replica.
+
+Otherwise, the Operator performs a **Rolling** update automatically.
+
+As a **Rolling** strategy can run multiple versions of the app at the same time, requests from the browser must be routed to a matching app version (that is, an app that has the same microflow or nanoflow parameters). The Operator uses Kubernetes service labels to perform an atomic switch, and instantly switch all clients to the updated version. This is done automatically once the number of updated replicas reaches a certain threshold. By default the threshold is 50% of all replicas. The value is specified in the [switchoverThreshold](#deployment-strategy-in-standalone) parameter.
 
 ### Use Cases
 
@@ -36,23 +59,13 @@ Whether a change can be performed without downtime depends on the type of the ch
 * Changing environment variables, Runtime or Java options
 * Changing Runtime Metrics settings
 * Upgrading the Mendix Operator version
-* Rebuilding the same MDA version to get the latest CVE updates
-* Changes in microflows or Java actions that do not affect the model
-* Updating Java dependencies
-
-The following changes in the UI can be done without downtime, but as soon as the new version becomes available, all clients must log in again:
 
-* Page changes, including layout or CSS changes
-* Changes in nanoflows or microflow parameters, if the microflow is used on a page
-* Changes in JavaScript actions
+The following changes will cause a full restart and downtime:
 
-The following changes will be deployed with downtime, because the model must be updated:
+* Any changes that cause a modified MDA file
+* Rebuilding the same MDA version with a different base image version (e.g. switching to another Java version or installing the latest CVE patches)
 
-* Adding Marketplace modules that have persistent entities
-* Updating the object model in the app itself, or its Marketplace modules
-* Updating to a newer Mendix version
-
-## Using the PreferRolling Strategy in Standalone Environments {#prefer-rolling-in-standalone}
+## Configuring the Deployment Strategy parameters in Standalone Environments {#deployment-strategy-in-standalone}
 
 To reduce deployment downtime, add the `deploymentStrategy` section to your `MendixApp` CR, as in the following example:
 
@@ -69,7 +82,6 @@ spec:
   # ...
   # Add or update this section:
   deploymentStrategy:
-    type: PreferRolling
     switchoverThreshold: 50%
     rollingUpdate:
       maxSurge: 0
@@ -78,42 +90,51 @@ spec:
 
 For more information on the `MendixApp` CR, see [Editing CR](/developerportal/deploy/private-cloud-operator/#edit-cr).
 
-If the `deploymentStrategy` is not specified, the Operator will use the Recreate strategy and perform a complete restart on any changes, causing downtime. This follows how updates were processed by Mendix on Kubernetes versions before 2.19 and earlier.
-
 You can specify the following options:
 
-* **type** – Specifies a type:
-    * **Recreate** - The default setting
-    * **PreferRolling** - Try to deploy without downtime when possible
 * **switchoverThreshold** – Specifies a threshold of updated, ready replicas after which all clients should switch to the updated version. The threshold can be a percentage or an absolute value.
     For example, setting this to **50%** will switch all clients to the updated app version once 50% of all replicas are running the updated version. If not otherwise specified, 50% is used as the default value. This option is only used if the strategy **type** is set to **PreferRolling**.
 * **rollingUpdate** - Specifies parameters for rolling updates if the Operator is able to perform the update without a restart. These parameters are used as Kubernetes [rollingUpdate](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#rolling-update-deployment) parameters:
     * **maxSurge** – Specifies an absolute or percentage value for how many additional replicas can be added during the deployment process. The default **0** value means that no additional replicas are added during the rollout process, and instead existing replicas are stopped to avoid using additional cluster resources.
-    * **maxUnavailable** – Specifies an absolute or percentage value for how many replicas can be stopped to be replaced with updated versions during the rollout process. The default **50%** value means that half of the replicas would be stopped during the update process. Lowering this value slows down the rollout process, but ensures that less replicas are stopped during the update process.
+    * **maxUnavailable** – Specifies an absolute or percentage value for how many replicas can be stopped to be replaced with updated versions during the rollout process. The default **1** value means that at most one replicas would be stopped during the update process. Increasing this value speeds up the rollout process, but can cause performance issues.
 
-## Preventing Kubernetes Disruptions
+## Configuring Pod Disruption Budget parameters in Standalone Environments {#pod-disruption-budget-in-standalone}
 
-Kubernetes can stop an app's pods if needed to stop a node (to scale down and consolidate apps to run on fewer nodes), or perform a node update (for example, install CVE patches on the host OS). You can add a [PodDisruptionBudget](https://kubernetes.io/docs/tasks/run-application/configure-pdb/) to an app to ensure that Kubernetes only stops a limited number of an app's pods, and if necessary waits for replacement pods to become available.
+Kubernetes can stop an app's pods if needed to stop a node (to scale down and consolidate apps to run on fewer nodes), or perform a node update (for example, install CVE patches on the host OS).
+Starting from Mendix Operator version 2.24.0, you can specify parameters for a [PodDisruptionBudget](https://kubernetes.io/docs/tasks/run-application/configure-pdb/) of an app to ensure that Kubernetes only stops a limited number of an app's pods, and if necessary waits for replacement pods to become available.
 
-To add a PodDisruptionBudget, create the following PodDisruptionBudget, replacing `<mendixapp-cr-name>` with your app's internal name (the MendixApp CR name):
+To manually configure parameters for a PodDisruptionBudget, add the `podDisruptionBudget` section to your `MendixApp` CR, as in the following example:
 
 ```yaml
-apiVersion: policy/v1
-kind: PodDisruptionBudget
+apiVersion: privatecloud.mendix.com/v1alpha1
+kind: MendixApp
 metadata:
-  name: <mendixapp-cr-name> # This should be updated to match the MenedixApp CR name
+# ...
+# omitted lines for brevity
+# ...
 spec:
-  maxUnavailable: 1 # Ensure that at most 1 replica is stopped by Kubernetes
-  selector:
-    matchLabels:
-      privatecloud.mendix.com/app: <mendixapp-cr-name> # This should be updated to match the MenedixApp CR name
-      privatecloud.mendix.com/component: mendix-app
+  # ...
+  # omitted lines for brevity
+  # ...
+  # Add or update this section:
+  podDisruptionBudget:
+    # Kubernetes doesn't allow specifying both maxUnavailable and minAvailable at the same time:
+    # https://kubernetes.io/docs/tasks/run-application/configure-pdb/#specifying-a-poddisruptionbudget
+    maxUnavailable: 1 # Example: do not disrupt more than 1 pod at the same time
+    # minAvailable: 50% # Example: make sure that at least 50% of pods are available
 ```
 
+You can specify the following options:
+
+* **maxUnavailable** – Specifies an absolute or percentage value for how many replicas can be stopped if Kubernetes needs to evict them from a node. The default **1** value means that at most 1 replica can be stopped, and that Kubernetes needs to wait until a replacement replica becomes available. Increasing this value speeds up the rollout process, but can cause performance issues.
+* **minAvailable** – Specifies an absolute or percentage value for how many replicas need to be remain available if Kubernetes needs to evict them from a node. Increasing this value slows down the rollout process, but ensures that less replicas can be disrupted.
+
+{{% alert color="warning" %}}
+Kubernetes doesn't allow specifying values for both `maxUnavailable` and `minAvailable`, and specifying values for both of them will [result in an error](https://kubernetes.io/docs/tasks/run-application/configure-pdb/#specifying-a-poddisruptionbudget).
+{{% /alert %}}
+
 ## Limitations
 
-* This feature is only supported by Mendix Operator version 2.20 (and later).
-* If the new app version has UI changes, all clients are automatically logged out and will need to sign back into the app.
-* Deploying a new version of the app will cause downtime if there are changes in the domain model, or the Mendix version.
-* If an app is based on Mendix 9.12 or a later version, a Rolling update can run scheduled events on any replica. During an update, scheduled events might use a newer or older version of their associated microflows, which will be random. If there are major changes in a scheduled event microflow, consider temporarily disabling scheduled events during an update.
+* This feature is only supported by Mendix Operator version 2.24 (and later). Mendix Operator versions 2.20.0 to 2.23.1 used to have an experimental implementation of this feature; upgrading to 2.24.0 or later is highly recommended.
+* Deploying a new version of the app will cause downtime if there are any changes in the app MDA or the base OS image.
 * To ensure that scheduled events [are correctly synchronized at startup](/releasenotes/studio-pro/10.20/#improvements), it is recommended to use Mendix 10.20 or later.

content/en/docs/releasenotes/deployment/mendix-for-private-cloud.md

@@ -12,6 +12,17 @@ For information on the current status of deployment to Mendix on Kubernetes and
 
 ## 2025
 
+### October 21, 2025
+
+#### Mendix Operator v2.24.0 {#2.24.0}
+
+* We have simplified the approach of handling Rolling updates by the Operator. Any app with two or more replicas will be updated without downtime, as long as the app is running the same MDA and base OS image.
+* Starting from this version, all Operator upgrades will run without causing downtime (in environments that have two or more replicas).
+* The Mendix Operator now manages **PodDisruptionBudgets**. For apps that have two or more replicas, a PodDisruptionBudget will be automatically created, so that cluster OS upgrades and scaling down nodes will happen in a controlled way, without causing disruption or downtime.
+* We have added a fallback license for Connected environments using Subscription Secrets. If an environment fails to communicate with the licensing server, it will use the fallback license instead of switching into Trial mode. This feature will become available for use with a future release of the Mendix on Kubernetes portal.
+* We have updated documentation to indicate that Kubernetes 1.34 is supported by the Mendix Operator.
+* We have made a few adjustments to support changes in upcoming Studio Pro version numbers.
+
 ### September 25, 2025
 
 #### Portal Improvements