Documented PodDisruptionBudget changes.

Updated default MaxUnavailable value to match latest Operator version.

Added a note about fallback licenses for call-home environments.

Author: zlogic

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

@@ -174,6 +174,11 @@ spec:
     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,6 +240,7 @@ You must make the following changes:
 * **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](/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/reduced-downtime-deployment.md

@@ -19,6 +19,15 @@ Starting from version 2.24.0, the Operator will automatically perform a Rolling
 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 2 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 didn't manage PodDisruptionBudgets.
+Instead, any manually created PodDisruptionBudget would apply to a Mendix app.
+If you're 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
 
 ## Prerequisites for Operator version 2.24.0 and higher{#prerequisites-2.24.0}
@@ -89,27 +98,43 @@ You can specify the following options:
     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.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.

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

@@ -18,6 +18,8 @@ For information on the current status of deployment to Mendix on Kubernetes and
 
 * We've simplified the approach of handling Rolling updates by the Operator. Any app with 2 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 2 or more replicas).
+* The Mendix Operator will now manage PodDisruptionBudgets. For apps that have 2 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've 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.
 * We have updated documentation that Kubernetes 1.34 is supported by the Mendix Operator.
 * We've made a few adjustments to support changes in upcoming Studio Pro version numbers.