docs: enhancing documentation regarding tcp update (#930)

Signed-off-by: Dario Tranchitella <dario@tranchitella.eu>

docs/content/guides/upgrade.md

@@ -1,13 +1,41 @@
 # Tenant Cluster Upgrade
-The process of upgrading a _“Tenant Cluster”_ consists in two steps:
+
+Upgrading a _Tenant Cluster_ consists of two main steps:
 
 1. Upgrade the Tenant Control Plane
-2. Upgrade of Tenant Worker Nodes
+2. Upgrade the Tenant Worker Nodes
+
+---
 
 ## Upgrade of Tenant Control Plane
-You should patch the `TenantControlPlane.spec.kubernetes.version` custom resource with a new compatible value according to the [Version Skew Policy](https://kubernetes.io/releases/version-skew-policy/).
 
-During the upgrade, a new ReplicaSet of Tenant Control Plane pod will be created, so make sure you have enough replicas to avoid service disruption. Also make sure you have the Rolling Update strategy properly configured:
+The version of the Tenant Control Plane is managed by updating the `TenantControlPlane.spec.kubernetes.version` field.  
+You should patch this field with a new compatible value according to the [Kubernetes Version Skew Policy](https://kubernetes.io/releases/version-skew-policy/).
+
+### Default Upgrade Strategy (Blue/Green)
+
+By default, when you upgrade a `TenantControlPlane`, Kamaji applies a **Blue/Green deployment** strategy.
+
+- `maxSurge: 100%`: all new control plane Pods are created at once.
+- `maxUnavailable: 0`: existing Pods remain running until the new Pods are ready.
+
+This ensures that the new ReplicaSet of Tenant Control Plane Pods comes up alongside the existing ones,
+minimising disruption and guaranteeing immediate failover.
+
+This approach provides some pros, such as a fast upgrade, and a minimal downtime, since existing Pods remain until the new ones are healthy.
+
+However, all new Pods start simultaneously, which may _overload communications with the DataStore_,
+and it requires sufficient cluster resources to host double the number of control plane Pods temporarily.
+
+### Alternative: Rolling Upgrade Strategy
+
+In environments with _constrained resources_, or where DataStore connections must be protected from sudden load spikes,
+you should configure a **Rolling Upgrade** strategy.
+
+This approach ensures that only a subset of Pods is replaced at a time,
+gradually rolling out the new version without stressing the infrastructure.
+
+Example configuration:
 
 ```yaml
 apiVersion: kamaji.clastix.io/v1alpha1
@@ -21,11 +49,10 @@ spec:
     deployment:
       replicas: 3
       strategy:
+        type: RollingUpdate
         rollingUpdate:
           maxSurge: 1
           maxUnavailable: 1
-        type: RollingUpdate
-...
 ```
 
 ## Upgrade of Tenant Worker Nodes