Ensure that users do not enable auto-upgrades in K8s guides (#1185)

Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>

Author: JakeSCahill

modules/deploy/pages/deployment-option/self-hosted/kubernetes/aks-guide.adoc

@@ -11,18 +11,16 @@ Deploy a secure Redpanda cluster and Redpanda Console in Azure Kubernetes Servic
 
 == Prerequisites
 
-Before you begin, you must have the following:
-
-* You must satisfy the prerequisites listed in the https://learn.microsoft.com/en-us/azure/aks/learn/quick-kubernetes-deploy-cli#prerequisites[AKS quickstart^]
+* Satisfy the prerequisites listed in the https://learn.microsoft.com/en-us/azure/aks/learn/quick-kubernetes-deploy-cli#prerequisites[AKS quickstart^]
 to get access to the Azure CLI.
-* https://kubernetes.io/docs/tasks/tools/[`kubectl`^]. Minimum required Kubernetes version: {supported-kubernetes-version}.
+* Install https://kubernetes.io/docs/tasks/tools/[`kubectl`^]. Minimum required Kubernetes version: {supported-kubernetes-version}.
 +
 [,bash]
 ----
 kubectl version --short --client
 ----
 
-* https://helm.sh/docs/intro/install/[Helm^]. Minimum required Helm version: {supported-helm-version}
+* Install https://helm.sh/docs/intro/install/[Helm^]. Minimum required Helm version: {supported-helm-version}
 +
 [,bash]
 ----
@@ -38,8 +36,6 @@ In this step, you create an AKS cluster with three nodes on https://learn.micros
 - 2 cores per worker node, which is a requirement for production.
 - Local NVMe disks, which is recommended for best performance.
 
-NOTE: The Helm chart configures default `podAntiAffinity` rules to make sure that only one Pod running a Redpanda broker is scheduled on each worker node. To learn why, see xref:deploy:deployment-option/self-hosted/kubernetes/k-requirements.adoc#number-of-workers[Number of workers].
-
 . Create a resource group for Redpanda:
 +
 [,bash]
@@ -56,10 +52,15 @@ az aks create -g redpandaResourceGroup -n <cluster-name> \
   --generate-ssh-keys \
   --enable-node-public-ip \
   --node-vm-size Standard_L8s_v3 \
-  --disable-file-driver
+  --disable-file-driver \
+  --node-os-upgrade-channel None <1>
 ----
 +
-TIP: For all available options, see the https://learn.microsoft.com/en-us/cli/azure/aks?view=azure-cli-latest#az-aks-create[AKS documentation^].
+<1> Set the https://learn.microsoft.com/en-us/azure/aks/auto-upgrade-node-os-image[OS upgrade channel^] to `None` to prevent AKS from automatically rebooting or upgrading nodes.
++
+For more details, see the xref:deploy:deployment-option/self-hosted/kubernetes/k-requirements.adoc#node-updates[requirements and recommendations] for deploying Redpanda in Kubernetes.
+
+For all available options, see the https://learn.microsoft.com/en-us/cli/azure/aks?view=azure-cli-latest#az-aks-create[AKS documentation^].
 
 include::deploy:partial$kubernetes/guides/create-storageclass.adoc[leveloffset=+2]
 

modules/deploy/pages/deployment-option/self-hosted/kubernetes/eks-guide.adoc

@@ -13,7 +13,7 @@ Then, use `rpk` both as an internal client and an external client to interact wi
 
 == Prerequisites
 
-Before you begin, you must have the following prerequisites.
+Before you begin, you must meet the following prerequisites.
 
 === IAM user
 
@@ -252,8 +252,6 @@ In this step, you create an EKS cluster with three nodes on https://aws.amazon.c
 - 2 cores per worker node, which is a requirement for production.
 - Local NVMe disks, which is recommended for best performance.
 
-NOTE: The Helm chart configures default `podAntiAffinity` rules to make sure that only one Pod running a Redpanda broker is scheduled on each worker node. To learn why, see xref:deploy:deployment-option/self-hosted/kubernetes/k-requirements.adoc#number-of-workers[Number of workers].
-
 . Create an EKS cluster and give it a unique name. If your account is configured with OIDC, add the `--with-oidc` flag to the `create cluster` command.
 +
 [,bash,lines=4-6]
@@ -266,16 +264,22 @@ eksctl create cluster \
   --external-dns-access
 ----
 +
-[TIP]
+[IMPORTANT]
 ====
-To see all options:
+Do not enable https://docs.aws.amazon.com/eks/latest/userguide/automode.html[auto mode^] (`--enable-auto-mode`) on Amazon EKS clusters running Redpanda.
+
+Auto mode can trigger automatic reboots or node upgrades that disrupt Redpanda brokers, risking data loss or cluster instability. Redpanda requires manual control over node lifecycle events.
 
+For more details, see the xref:deploy:deployment-option/self-hosted/kubernetes/k-requirements.adoc#node-updates[requirements and recommendations] for deploying Redpanda in Kubernetes.
+====
++
+To see all options:
++
 ```bash
 eksctl create cluster --help
 ```
-
++
 Or, for help creating an EKS cluster, see the https://eksctl.io/usage/creating-and-managing-clusters/[Creating and managing clusters^] in the `eksctl` documentation.
-====
 
 . Make sure that your local `kubeconfig` file points to your EKS cluster:
 +

modules/deploy/pages/deployment-option/self-hosted/kubernetes/gke-guide.adoc

@@ -11,17 +11,15 @@ Deploy a secure Redpanda cluster and Redpanda Console in Google Kubernetes Engin
 
 == Prerequisites
 
-Before you begin, you must have the following:
-
 * Complete the 'Before you begin' steps and the 'Launch Cloud Shell' steps of the https://cloud.google.com/kubernetes-engine/docs/deploy-app-cluster#before-you-begin[GKE quickstart^]. Cloud Shell comes preinstalled with the Google Cloud CLI, the `kubectl` command-line tool, and the Helm package manager.
-* https://kubernetes.io/docs/tasks/tools/[`kubectl`^]. Minimum required Kubernetes version: {supported-kubernetes-version}.
+* Ensure https://kubernetes.io/docs/tasks/tools/[`kubectl`^] is installed. Minimum required Kubernetes version: {supported-kubernetes-version}.
 +
 [,bash]
 ----
 kubectl version --short --client
 ----
 
-* https://helm.sh/docs/intro/install/[Helm^]. Minimum required Helm version: {supported-helm-version}
+* Ensure https://helm.sh/docs/intro/install/[Helm^] is installed. Minimum required Helm version: {supported-helm-version}
 +
 [,bash]
 ----
@@ -37,8 +35,6 @@ In this step, you create a GKE cluster with three nodes on https://cloud.google.
 - 2 cores per worker node, which is a requirement for production.
 - Local NVMe disks, which is recommended for best performance.
 
-NOTE: The Helm chart configures default `podAntiAffinity` rules to make sure that only one Pod running a Redpanda broker is scheduled on each worker node. To learn why, see xref:deploy:deployment-option/self-hosted/kubernetes/k-requirements.adoc#number-of-workers[Number of workers].
-
 Create a GKE cluster. Replace the `<region>` placeholder with your own region.
 
 [,bash]
@@ -50,12 +46,18 @@ gcloud container clusters create <cluster-name> \
   --region=<region>
 ----
 
-[TIP]
+[IMPORTANT]
 ====
+Do not enable https://cloud.google.com/kubernetes-engine/docs/how-to/node-auto-upgrades[node auto-upgrades^] (`--enable-autoupgrade`) on Google GKE clusters running Redpanda.
+
+Node auto-upgrades can trigger automatic reboots or node upgrades that disrupt Redpanda brokers, risking data loss or cluster instability. Redpanda requires manual control over node lifecycle events.
+
+For more details, see the xref:deploy:deployment-option/self-hosted/kubernetes/k-requirements.adoc#node-updates[requirements and recommendations] for deploying Redpanda in Kubernetes.
+====
+
 To see all options that you can specify when creating a cluster, see the https://cloud.google.com/sdk/gcloud/reference/container/clusters/create[Cloud SDK reference^].
 
 Or, for help creating a GKE cluster, see the https://cloud.google.com/kubernetes-engine/docs/deploy-app-cluster#create_cluster[GKE documentation^].
-====
 
 include::deploy:partial$kubernetes/guides/create-storageclass.adoc[leveloffset=+2]
 

modules/deploy/partials/requirements.adoc

@@ -52,35 +52,27 @@ ifndef::env-kubernetes[]
 endif::[]
 
 [[node-updates]]
-== Node maintenance and operating system upgrades
+== Prevent automatic node upgrades
 
 Ensure that node and operating system (OS) upgrades are manually managed when running Redpanda in production. Manual control avoids unplanned reboots or replacements that disrupt Redpanda brokers, causing service downtime, data loss, or quorum instability.
 
-=== Limitations of automatic updates
+Common issues with automatic node upgrades include:
 
-Redpanda is stateful. Redpanda brokers manage partition data and leadership, making them sensitive to disruptions. Proper handling during maintenance is required to:
-
-- Avoid data loss, especially for nodes with ephemeral or local storage.
-- Ensure smooth leadership transitions by decommissioning brokers before removing a node.
-- Minimize service downtime by upgrading nodes one at a time during planned maintenance windows.
-
-However, automatic update mechanisms provided by cloud platforms may not meet Redpanda's stateful requirements. Common issues include:
-
-- Hard timeouts for graceful shutdowns that may not allow Redpanda brokers enough time to complete decommissioning or leadership transitions.
+- Hard timeouts for graceful shutdowns that do not allow Redpanda brokers enough time to complete decommissioning or leadership transitions.
 - Replacements or reboots without ensuring data has been safely migrated or replicated, risking data loss.
 - Parallel upgrades across multiple nodes, which can disrupt quorum or reduce cluster availability.
 
-*Recommendations*:
+*Requirements*:
 
 - Disable automatic node maintenance or upgrades.
 ifdef::env-kubernetes[]
 To prevent managed Kubernetes services from automatically rebooting or upgrading nodes:
-** **Azure AKS**: Set the OS upgrade channel to `None`. https://learn.microsoft.com/en-us/azure/aks/auto-upgrade-node-os-image[Azure Documentation^].
-** **Google GKE**: Disable GKE auto-upgrades for node pools. https://cloud.google.com/kubernetes-engine/docs/how-to/node-auto-upgrades[GCP Documentation^].
-** **Amazon EKS**: Avoid enabling EKS node auto-upgrades. https://docs.aws.amazon.com/eks/latest/userguide/worker.html[AWS Documentation^].
-- xref:upgrade:k-upgrade-kubernetes.adoc[Manually manage node upgrades].
-endif::[]
+** **Azure AKS**: https://learn.microsoft.com/en-us/azure/aks/auto-upgrade-node-os-image[Set the OS upgrade channel to `None`^].
+** **Google GKE**: https://cloud.google.com/kubernetes-engine/docs/how-to/node-auto-upgrades[Disable GKE auto-upgrades for node pools^].
+** **Amazon EKS**: https://docs.aws.amazon.com/eks/latest/userguide/automode.html[Disable EKS node auto-upgrades^].
 
+See also: xref:upgrade:k-upgrade-kubernetes.adoc[How to manually manage node upgrades].
+endif::[]
 
 == CPU and memory