docs: import CloudNativePG main

Author: cnpg-bot

website/docs/cloudnative-pg.v1.md

@@ -1610,7 +1610,7 @@ _Appears in:_
 | `successThreshold` _integer_ | Minimum consecutive successes for the probe to be considered successful after having failed.<br />Defaults to 1. Must be 1 for liveness and startup. Minimum value is 1. |  |  |  |
 | `failureThreshold` _integer_ | Minimum consecutive failures for the probe to be considered failed after having succeeded.<br />Defaults to 3. Minimum value is 1. |  |  |  |
 | `terminationGracePeriodSeconds` _integer_ | Optional duration in seconds the pod needs to terminate gracefully upon probe failure.<br />The grace period is the duration in seconds after the processes running in the pod are sent<br />a termination signal and the time when the processes are forcibly halted with a kill signal.<br />Set this value longer than the expected cleanup time for your process.<br />If this value is nil, the pod's terminationGracePeriodSeconds will be used. Otherwise, this<br />value overrides the value provided by the pod spec.<br />Value must be non-negative integer. The value zero indicates stop immediately via<br />the kill signal (no opportunity to shut down).<br />This is a beta field and requires enabling ProbeTerminationGracePeriod feature gate.<br />Minimum value is 1. spec.terminationGracePeriodSeconds is used if unset. |  |  |  |
-| `isolationCheck` _[IsolationCheckConfiguration](#isolationcheckconfiguration)_ | Configure the feature that extends the liveness probe for a primary<br />instance. In addition to the basic checks, this verifies whether the<br />primary is isolated from the Kubernetes API server and from its<br />replicas, ensuring that it can be safely shut down if network<br />partition or API unavailability is detected. Enabled by default. |  |  |  |
+| `isolationCheck` _[IsolationCheckConfiguration](#isolationcheckconfiguration)_ | Configure the feature that extends the liveness probe for a primary<br />instance. In addition to the basic checks, this reports whether the<br />primary is isolated from the Kubernetes API server and from its<br />replicas, so the kubelet restarts it through the normal<br />container-termination path (a smart shutdown, bounded by<br />`.spec.smartShutdownTimeout`) when a network partition or API<br />unavailability is detected. Enabled by default. |  |  |  |
 
 
 

website/docs/failover.md

@@ -103,13 +103,21 @@ The two mechanisms are complementary and both are enabled by default:
 
 * The lease prevents *premature* promotion: a replica cannot promote
   while the former primary still holds the lease.
-* The isolation check stops an *isolated* primary from continuing to
-  accept writes.
+* The isolation check reports an isolated primary as unhealthy, which
+  the kubelet then restarts through its normal container-termination
+  path. That path is a *smart* shutdown: it refuses new connections
+  but lets sessions that are already open keep committing until
+  `.spec.smartShutdownTimeout` elapses (180 seconds by default), so
+  it narrows the write window during a partition rather than closing
+  it outright.
 
 Keep both enabled. Disabling the isolation check leaves the lease
 alone responsible for primary safety, and the lease alone cannot
 prevent split-brain when the former primary cannot reach the API
-server but remains otherwise healthy.
+server but remains otherwise healthy. If that write window matters
+for your workload, set `.spec.smartShutdownTimeout: 0` so the
+restart goes straight to a fast shutdown instead of waiting out the
+full window.
 
 ### Inspecting the primary lease
 
@@ -275,14 +283,17 @@ mechanism, driven by `tolerationSeconds` on the
 `node.kubernetes.io/unreachable` `NoExecute` taint (`300s` by default). That
 timer does not hold up the operator's failover decision; CloudNativePG
 promotes a new primary as soon as the `Ready` condition flips. By that point
-the kubelet on the isolated node has already stopped the old PostgreSQL
-container locally: with the default
-`.spec.probes.liveness.isolationCheck.enabled: true`, the instance manager
-fails its own liveness probe once it can reach neither the API server nor
-the rest of the cluster, and the kubelet kills the container within
-approximately three probe periods (`~30s`). Full high availability
-(recreation of the old primary on a healthy node by the operator) is still
-gated on the taint-based eviction actually deleting the pod.
+the kubelet on the isolated node has already noticed the problem: with the
+default `.spec.probes.liveness.isolationCheck.enabled: true`, the instance
+manager fails its own liveness probe once it can reach neither the API
+server nor the rest of the cluster, and the kubelet restarts the container
+within approximately three probe periods (`~30s`). That restart goes
+through the normal termination path, a smart shutdown that lets sessions
+already open on the isolated primary keep committing until
+`.spec.smartShutdownTimeout` elapses (180 seconds by default) on top of
+that ~30s detection window. Full high availability (recreation of the old
+primary on a healthy node by the operator) is still gated on the
+taint-based eviction actually deleting the pod.
 
 ## Failover Quorum (Quorum-based Failover)
 

website/docs/instance_manager.md

@@ -232,7 +232,7 @@ following conditions are met:
 1. The instance manager cannot reach the Kubernetes API server
 2. The instance manager cannot reach **any** other instance via the instance manager’s REST API
 
-The effect of this behavior is to consider an isolated primary to be not alive and subsequently **shut it down** when the liveness probe fails.
+The effect of this behavior is to consider an isolated primary to be not alive: the liveness probe fails, and the kubelet restarts the container through its normal termination path. That path is a **smart** shutdown: it refuses new connections but lets sessions that are already open keep committing until `.spec.smartShutdownTimeout` elapses (180 seconds by default). Set `.spec.smartShutdownTimeout: 0` if you need the restart to skip straight to a fast shutdown instead of waiting out that window.
 
 It is **enabled by default** and can be disabled by adding the following:
 
@@ -267,9 +267,11 @@ spec:
 
 :::info
 Primary isolation is distinct from the [safe primary election](failover.md#safe-primary-election)
-mechanism. The isolation check *fences* a primary that has lost connectivity to
-both the API server and the other instances, while the primary lease coordinates
-*which instance is allowed to promote*. The two mechanisms are complementary.
+mechanism. The isolation check reports a primary that has lost connectivity to
+both the API server and the other instances as unhealthy, leaving the kubelet
+to restart it through the normal container-termination path described above;
+the primary lease coordinates *which instance is allowed to promote*. The two
+mechanisms are complementary.
 :::
 
 ## Readiness Probe