tech review updates

Author: amsliu

support/azure/azure-kubernetes/availability-performance/identify-memory-saturation-aks.md

@@ -1,9 +1,9 @@
 --- 
 title: Troubleshoot Memory Saturation in AKS Clusters
 description: Troubleshoot memory saturation in Azure Kubernetes Service (AKS) clusters across namespaces and containers. Learn how to identify the hosting node.
-ms.date: 06/27/2025
+ms.date: 08/18/2025
 editor: v-jsitser
-ms.reviewer: chiragpa, aritraghosh, v-leedennis
+ms.reviewer: chiragpa, aritraghosh, v-leedennis, v-liuamson
 ms.service: azure-kubernetes-service
 ms.custom: sap:Node/node pool availability and performance
 ---
@@ -61,9 +61,9 @@ Container Insights is a feature within AKS that monitors container workload perf
 1. Because the first node has the highest memory usage, select that node to investigate the memory usage of the pods that are running on the node.
 
    :::image type="complex" source="./media/identify-memory-saturation-aks/containers-containerinsights-memorypressure.png" alt-text="Azure portal screenshot of a node's containers under the Nodes view in Container Insights within an Azure Kubernetes Service (AKS) cluster." lightbox="./media/identify-memory-saturation-aks/containers-containerinsights-memorypressure.png":::
-   
+
       The Azure portal screenshot shows a table of nodes. The first node is expanded to display an **Other processes** heading and a sublist of processes that are running within the first node. As for the nodes themselves, the table column values for the processes include **Name**, **Status**, **Max %** (the percentage of memory capacity that's used), **Max** (memory usage), **Containers**, **UpTime**, **Controller**, and **Trend Max % (1 bar = 15m)**. The processes also have an expand/collapse arrow icon next to their names.
-   
+
       Nine processes are listed under the node. The statuses are all **Ok**, the maximum percentage of memory used for the processes ranges from 16 to 0.3 percent, the maximum memory used is from 0.7 mc to 22 mc, the number of containers used is 1 to 3, and the uptime is 3 to 4 days. Unlike for the node, the processes all have a corresponding controller listed. In this screenshot, the controller names are prefixes of the process names, and they're hyperlinked.
    :::image-end:::
 
@@ -91,7 +91,7 @@ This procedure uses the kubectl commands in a console. It displays only the curr
    aks-testmemory-30616462-vmss000002   74m          3%     1715Mi          31%
    ```
 
-2. Get the list of pods that are running on the node and their memory usage by running the [kubectl get pods](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#get) and [kubectl top pods](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#-em-pod-em-) commands: 
+2. Get the list of pods that are running on the node and their memory usage by running the [kubectl get pods](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#get) and [kubectl top pods](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#-em-pod-em-) commands:
 
    ```bash
    kubectl get pods --all-namespaces --output wide \
@@ -205,7 +205,7 @@ For advanced process level memory analysis, use [Inspektor Gadget](https://go.mi
       aks-agentpool-3…901-vmss000001    default                memory-stress        21677     stress          944 MB       872 MB              5.2     
       aks-agentpool-3…901-vmss000001    default                memory-stress        21679     stress          944 MB       796 MB              4.8     
 
-   ```   
+   ```
 
 You can use this output to identify the processes that are consuming the most memory on the node. The output can include the node name, namespace, pod name, container name, process ID (PID), command name (COMM), CPU, and memory usage. For more details, see [the documentation](https://aka.ms/igtopprocess).
 
@@ -215,7 +215,7 @@ Review the following table to learn how to implement best practices for avoiding
 
 | Best practice | Description |
 |---|---|
-| Use memory [requests and limits](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#requests-and-limits) | Kubernetes provides options to specify the minimum memory size (*request*) and the maximum memory size (*limit*) for a container. By configuring limits on pods, you can avoid memory pressure on the node. Make sure that the aggregate limits for all pods that are running doesn't exceed the node's available memory. This situation is called *overcommitting*. The Kubernetes scheduler allocates resources based on set requests and limits through [Quality of Service](https://kubernetes.io/docs/tasks/configure-pod-container/quality-service-pod/) (QoS). Without appropriate limits, the scheduler might schedule too many pods on a single node. This situation might eventually bring down the node. Additionally, while the kubelet is evicting pods, it prioritizes pods in which the memory usage exceeds their defined requests. We recommend that you set the memory request close to the actual usage. |
+| Use memory [requests and limits](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#requests-and-limits) | Kubernetes provides options to specify the minimum memory size (_request_) and the maximum memory size (_limit_) for a container. By configuring limits on pods, you can avoid memory pressure on the node. Make sure that the aggregate limits for all pods that are running doesn't exceed the node's available memory. This situation is called _overcommitting_. The Kubernetes scheduler allocates resources based on set requests and limits through [Quality of Service](https://kubernetes.io/docs/tasks/configure-pod-container/quality-service-pod/) (QoS). Without appropriate limits, the scheduler might schedule too many pods on a single node. This situation might eventually bring down the node. Additionally, while the kubelet is evicting pods, it prioritizes pods in which the memory usage exceeds their defined requests. We recommend that you set the memory request close to the actual usage. |
 | Enable the [horizontal pod autoscaler](/azure/aks/tutorial-kubernetes-scale?tabs=azure-cli#autoscale-pods) | By scaling the cluster, you can balance the requests across many pods to prevent memory saturation. This technique can reduce the memory footprint on the specific node. |
 | Use [anti-affinity tags](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity) | For scenarios in which memory is unbounded by design, you can use node selectors and affinity or anti-affinity tags, which can isolate the workload to specific nodes. By using anti-affinity tags, you can prevent other workloads from scheduling pods on these nodes and reduce the memory saturation problem. |
 | Choose [higher SKU VMs](https://azure.microsoft.com/pricing/details/virtual-machines/linux/) | VMs that have more random-access memory (RAM) are better suited to handle high memory usage. To use this option, you must create a new node pool, cordon the nodes (make them unschedulable), and drain the existing node pool. |

support/azure/azure-kubernetes/availability-performance/troubleshoot-oomkilled-aks-clusters.md

@@ -1,13 +1,13 @@
 --- 
 title: Troubleshoot OOMkilled in AKS clusters
 description: Troubleshoot and resolve out-of-memory (OOMkilled) issues in Azure Kubernetes Service (AKS) clusters.
-ms.date: 08/13/2025
+ms.date: 08/18/2025
 editor: v-jsitser
 ms.reviewer: v-liuamson
 ms.service: azure-kubernetes-service
 ms.custom: sap:Node/node pool availability and performance
 ---
-# Troubleshooting OOMKilled in AKS clusters 
+# Troubleshooting OOMKilled in AKS clusters
 
 ## Understanding OOM Kills
 
@@ -96,47 +96,47 @@ You can use one of these various methods to identify the POD which is killed due
 
 Use the following command to check the status of all pods in a namespace:
 
-- `kubectl get pods -n \<namespace\>`
+- `kubectl get pods -n <namespace>`
 
 Look for pods with statuses of OOMKilled.
 
 ### Describe the Pod
 
-Use `kubectl describe pod \<pod-name\>` to get detailed information about the pod.
+Use `kubectl describe pod <pod-name>` to get detailed information about the pod.
 
-- `kubectl describe pod \<pod-name\> -n \<namespace\>`
+- `kubectl describe pod <pod-name> -n <namespace>`
 
 In the output, check the Container Statuses section for indications of OOM kills.
 
 ### Pod Logs
 
-Review pod logs using `kubectl logs \<pod-name\>` to identify memory-related issues.
+Review pod logs using `kubectl logs <pod-name>` to identify memory-related issues.
 
 To view the logs of the pod, use:
 
-- `kubectl logs \<pod-name\> -n \<namespace\>`
+- `kubectl logs <pod-name> -n <namespace>`
 
 If the pod has restarted, check the previous logs:
 
-- `kubectl logs \<pod-name\> -n \<namespace\> \--previous`
+- `kubectl logs <pod-name> -n <namespace> --previous`
 
 ### Node Logs
 
 You can [review the kubelet logs](/azure/aks/kubelet-logs) on the node to see if there are messages indicating that the OOM killer was triggered at the time of the issue and that pod's memory usage reached its limit.
 
 Alternatively, you can [SSH into the node](/azure/aks/node-access) where the pod was running and check the kernel logs for any OOM messages. This command will display which processes the OOM killer terminated:
 
-`chroot /host \# access the node session`
+`chroot /host # access the node session`
 
-`grep -i \"Memory cgroup out of memory\" /var/log/syslog`
+`grep -i "Memory cgroup out of memory" /var/log/syslog`
 
 ### Events
 
-- Use `kubectl get events \--sort-by=.lastTimestamp -n \<namespace\>` to find OOMKilled pods.
+- Use `kubectl get events --sort-by=.lastTimestamp -n <namespace>` to find OOMKilled pods.
 
 - Use the events section from the pod description to look for OOM-related messages:
 
-  - `kubectl describe pod \<pod-name\> -n \<namespace\>`
+  - `kubectl describe pod <pod-name> -n <namespace>`
 
 ## Handling OOMKilled for system pods
 
@@ -186,8 +186,8 @@ restart.
 To solve, review request and limits documentation to understand how to modify
 your deployment accordingly. For more information, see [Resource Management for Pods and Containers](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#requests-and-limits).
 
-`kubectl set resources deployment \<deployment-name\>
-\--limits=memory=\<LIMITS\>Mi ---requests=memory=\<MEMORY\>Mi`
+`kubectl set resources deployment <deployment-name>
+--limits=memory=<LIMITS>Mi ---requests=memory=<MEMORY>Mi`
 
 Setting resource requests and limits to the recommended amount for the
 application pod.
@@ -201,24 +201,22 @@ Confirm the Memory Pressure at the pod level:
 
 Use kubectl top to check memory usage:
 
-`kubectl top pod \<pod-name\> -n \<namespace\>`
+`kubectl top pod <pod-name> -n <namespace>`
 
 If metrics are unavailable, you can inspect cgroup stats directly:
 
-`kubectl exec -it \<pod-name\> -n \<namespace\> \-- cat
-/sys/fs/cgroup/memory.current`
+`kubectl exec -it <pod-name> -n <namespace> -- cat /sys/fs/cgroup/memory.current`
 
 Or you can use this to see the value in MB:
 
-`kubectl exec -it \<pod-name\> -n \<namespace\> \-- cat
-/sys/fs/cgroup/memory.current \| awk \'{print \$1/1024/1024 \" MB\"}\'`
+`kubectl exec -it <pod-name> -n <namespace> -- cat /sys/fs/cgroup/memory.current | awk '{print $1/1024/1024 " MB"}'`
 
 This helps to confirm whether the pod is approaching or exceeding its
 memory limits.
 
 - Check for OOMKilled Events
 
-`kubectl get events \--sort-by=\'.lastTimestamp\' -n \<namespace\>`
+`kubectl get events --sort-by='.lastTimestamp' -n <namespace>`
 
 To resolve, engage the application vendor. If the app is from a third party, check
 if they have known issues or memory tuning guides. Also, depending on the application framework, ask the vendor to verify whether they are using the latest version of Java or .Net as recommended in [Memory saturation occurs in pods after cluster upgrade to Kubernetes 1.25](../create-upgrade-delete/aks-memory-saturation-after-upgrade.md).