Merge pull request #7824 from MicrosoftDocs/repo_sync_working_branch

Confirm merge from repo_sync_working_branch to main to sync with https://github.com/MicrosoftDocs/SupportArticles-docs (branch main)

Author: Simonx Xu

support/azure/azure-kubernetes/availability-performance/node-not-ready-then-recovers.md

@@ -1,41 +1,36 @@
 ---
 title: Node not ready but then recovers
-description: Troubleshoot scenarios in the status of an Azure Kubernetes Service (AKS) cluster node is Node Not Ready, but then the node recovers.
-ms.date: 04/15/2022
+description: Troubleshoot scenarios in which the status of an AKS cluster node is Node Not Ready, but then the node recovers.
+ms.date: 12/09/2024
 ms.reviewer: rissing, chiragpa, momajed, v-leedennis
 ms.service: azure-kubernetes-service
-#Customer intent: As an Azure Kubernetes user, I want to prevent the Node Not Ready status for nodes that later recover so that I can avoid future errors within an Azure Kubernetes Service (AKS) cluster.
+#Customer intent: As an Azure Kubernetes user, I want to prevent the Node Not Ready status for nodes that later recover so that I can avoid future errors within an AKS cluster.
 ms.custom: sap:Node/node pool availability and performance
 ---
 # Troubleshoot Node Not Ready failures that are followed by recoveries
 
-This article helps troubleshoot scenarios in which a node within a Microsoft Azure Kubernetes Service (AKS) cluster shows the Node Not Ready status, but then automatically recovers to a healthy state.
-
-## Symptoms
-
-You notice that your application stops responding while the node is reporting that it has a Not Ready status. However, the node recovers automatically, and now, it's looking for a root cause analysis (RCA).
+This article provides a guide to troubleshoot and resolve "Node Not Ready" issues in Azure Kubernetes Service (AKS) clusters. When a node enters a "Not Ready" state, it can disrupt the application's functionality and cause it to stop responding. Typically, the node recovers automatically after a short period. However, to prevent recurring issues and maintain a stable environment, it's important to understand the underlying causes to be able to implement effective resolutions. 
 
 ## Cause
 
-Possible causes of this issue include the following scenarios:
+There are several scenarios that could cause a "Not Ready" state to occur:
 
-- The API server isn't available, and you're using a readiness probe for the deployment.
+- The unavailability of the API server. This causes the readiness probe to fail. This prevents the pod from being attached to the service so that traffic is no longer forwarded to the pod instance.
 
-  If a pod is running but isn't ready, that situation means that the readiness probe is failing. If the readiness probe fails, the pod isn't attached to the service, and traffic isn't forwarded to the pod instance.
-
-- Virtual machine (VM) host faults occur. To determine whether VM host faults occurred, check the following information sources:
+- Virtual machine (VM) host faults. To determine whether VM host faults occurred, check the following information sources:
   - [AKS diagnostics](/azure/aks/concepts-diagnostics)
   - [Azure status](https://status.azure.com/)
   - Azure notifications (for any recent outages or maintenance periods)
 
+## Resolution
+
+Check the API server availability by running the `kubectl get apiservices` command. Make sure that the readiness probe is correctly configured in the deployment YAML file.
+
+For further steps, see [Basic troubleshooting of Node Not Ready failures](node-not-ready-basic-troubleshooting.md).
+
 ## Prevention
 
 To prevent this issue from occurring in the future, take one or more of the following actions:
 
 - Make sure that your service tier is fully paid for.
 - Reduce the number of `watch` and `get` requests to the API server.
-- Replace the node pool with a healthy node pool.
-
-## More information
-
-- For general troubleshooting steps, see [Basic troubleshooting of Node Not Ready failures](node-not-ready-basic-troubleshooting.md).