updated YAML code sample to fix formatting

Author: MGoedtel

articles/aks/operator-best-practices-advanced-scheduler.md

@@ -4,15 +4,16 @@ titleSuffix: Azure Kubernetes Service
 description: Learn the cluster operator best practices for using advanced scheduler features such as taints and tolerations, node selectors and affinity, or inter-pod affinity and anti-affinity in Azure Kubernetes Service (AKS)
 services: container-service
 ms.topic: conceptual
-ms.date: 03/09/2021
+ms.date: 11/11/2022
 
 ---
 
 # Best practices for advanced scheduler features in Azure Kubernetes Service (AKS)
 
 As you manage clusters in Azure Kubernetes Service (AKS), you often need to isolate teams and workloads. Advanced features provided by the Kubernetes scheduler let you control:
+
 * Which pods can be scheduled on certain nodes.
-* How multi-pod applications can be appropriately distributed across the cluster. 
+* How multi-pod applications can be appropriately distributed across the cluster.
 
 This best practices article focuses on advanced Kubernetes scheduling features for cluster operators. In this article, you learn how to:
 
@@ -23,22 +24,24 @@ This best practices article focuses on advanced Kubernetes scheduling features f
 
 ## Provide dedicated nodes using taints and tolerations
 
-> **Best practice guidance:** 
+> **Best practice guidance:**
 >
 > Limit access for resource-intensive applications, such as ingress controllers, to specific nodes. Keep node resources available for workloads that require them, and don't allow scheduling of other workloads on the nodes.
 
-When you create your AKS cluster, you can deploy nodes with GPU support or a large number of powerful CPUs. You can use these nodes for large data processing workloads such as machine learning (ML) or artificial intelligence (AI). 
+When you create your AKS cluster, you can deploy nodes with GPU support or a large number of powerful CPUs. You can use these nodes for large data processing workloads such as machine learning (ML) or artificial intelligence (AI).
 
-Since this node resource hardware is typically expensive to deploy, limit the workloads that can be scheduled on these nodes. Instead, you'd dedicate some nodes in the cluster to run ingress services and prevent other workloads.
+Because this node resource hardware is typically expensive to deploy, limit the workloads that can be scheduled on these nodes. Instead, dedicate some nodes in the cluster to run ingress services and prevent other workloads.
 
-This support for different nodes is provided by using multiple node pools. An AKS cluster provides one or more node pools.
+This support for different nodes is provided by using multiple node pools. An AKS cluster supports one or more node pools.
 
 The Kubernetes scheduler uses taints and tolerations to restrict what workloads can run on nodes.
 
 * Apply a **taint** to a node to indicate only specific pods can be scheduled on them.
 * Then apply a **toleration** to a pod, allowing them to *tolerate* a node's taint.
 
-When you deploy a pod to an AKS cluster, Kubernetes only schedules pods on nodes whose taint aligns with the toleration. For example, assume you added a node pool in your AKS cluster for nodes with GPU support. You define name, such as *gpu*, then a value for scheduling. Setting this value to *NoSchedule* restricts the Kubernetes scheduler from scheduling pods with undefined toleration on the node.
+When you deploy a pod to an AKS cluster, Kubernetes only schedules pods on nodes whose taint aligns with the toleration. Taints and tolerations work together to ensure that pods are not scheduled onto inappropriate nodes. One or more taints are applied to a node, marking the the node so that it does not accept any pods that do not tolerate the taints.
+
+For example, assume you added a node pool in your AKS cluster for nodes with GPU support. You define name, such as *gpu*, then a value for scheduling. Setting this value to *NoSchedule* restricts the Kubernetes scheduler from scheduling pods with undefined toleration on the node.
 
 ```azurecli-interactive
 az aks nodepool add \
@@ -85,9 +88,11 @@ For more information about how to use multiple node pools in AKS, see [Create an
 When you upgrade a node pool in AKS, taints and tolerations follow a set pattern as they're applied to new nodes:
 
 #### Default clusters that use VM scale sets
+
 You can [taint a node pool][taint-node-pool] from the AKS API to have newly scaled out nodes receive API specified node taints.
 
 Let's assume:
+
 1. You begin with a two-node cluster: *node1* and *node2*. 
 1. You upgrade the node pool.
 1. Two additional nodes are created: *node3* and *node4*. 
@@ -97,6 +102,7 @@ Let's assume:
 #### Clusters without VM scale set support
 
 Again, let's assume:
+
 1. You have a two-node cluster: *node1* and *node2*. 
 1. You upgrade the node pool.
 1. An additional node is created: *node3*.
@@ -112,8 +118,8 @@ When you scale a node pool in AKS, taints and tolerations do not carry over by d
 
 ## Control pod scheduling using node selectors and affinity
 
-> **Best practice guidance** 
-> 
+> **Best practice guidance**
+>
 > Control the scheduling of pods on nodes using node selectors, node affinity, or inter-pod affinity. These settings allow the Kubernetes scheduler to logically isolate workloads, such as by hardware in the node.
 
 Taints and tolerations logically isolate resources with a hard cut-off. If the pod doesn't tolerate a node's taint, it isn't scheduled on the node.
@@ -153,7 +159,8 @@ spec:
         cpu: 4.0
         memory: 16Gi
   nodeSelector:
-      hardware: highmem
+      hardware:
+      values: highmem
 ```
 
 When you use these scheduler options, work with your application developers and owners to allow them to correctly define their pod specifications.
@@ -162,7 +169,8 @@ For more information about using node selectors, see [Assigning Pods to Nodes][k
 
 ### Node affinity
 
-A node selector is a basic solution for assigning pods to a given node. *Node affinity* provides more flexibility, allowing you to define what happens if the pod can't be matched with a node. You can: 
+A node selector is a basic solution for assigning pods to a given node. *Node affinity* provides more flexibility, allowing you to define what happens if the pod can't be matched with a node. You can:
+
 * *Require* that Kubernetes scheduler matches a pod with a labeled host. Or,
 * *Prefer* a match but allow the pod to be scheduled on a different host if no match is available.
 
@@ -191,7 +199,8 @@ spec:
         - matchExpressions:
           - key: hardware
             operator: In
-            values: highmem
+            values:
+            - highmem
 ```
 
 The *IgnoredDuringExecution* part of the setting indicates that the pod shouldn't be evicted from the node if the node labels change. The Kubernetes scheduler only uses the updated node labels for new pods being scheduled, not pods already scheduled on the nodes.
@@ -202,9 +211,10 @@ For more information, see [Affinity and anti-affinity][k8s-affinity].
 
 One final approach for the Kubernetes scheduler to logically isolate workloads is using inter-pod affinity or anti-affinity. These settings define that pods either *shouldn't* or *should* be scheduled on a node that has an existing matching pod. By default, the Kubernetes scheduler tries to schedule multiple pods in a replica set across nodes. You can define more specific rules around this behavior.
 
-For example, you have a web application that also uses an Azure Cache for Redis. 
-1. You use pod anti-affinity rules to request that the Kubernetes scheduler distributes replicas across nodes. 
-1. You use affinity rules to ensure each web app component is scheduled on the same host as a corresponding cache. 
+For example, you have a web application that also uses an Azure Cache for Redis.
+
+* You use pod anti-affinity rules to request that the Kubernetes scheduler distributes replicas across nodes.
+* You use affinity rules to ensure each web app component is scheduled on the same host as a corresponding cache.
 
 The distribution of pods across nodes looks like the following example:
 
@@ -213,7 +223,7 @@ The distribution of pods across nodes looks like the following example:
 | webapp-1   | webapp-2   | webapp-3   |
 | cache-1    | cache-2    | cache-3    |
 
-Inter-pod affinity and anti-affinity provide a more complex deployment than node selectors or node affinity. With the deployment, you logically isolate resources and control how Kubernetes schedules pods on nodes. 
+Inter-pod affinity and anti-affinity provide a more complex deployment than node selectors or node affinity. With the deployment, you logically isolate resources and control how Kubernetes schedules pods on nodes.
 
 For a complete example of this web application with Azure Cache for Redis example, see [Co-locate pods on the same node][k8s-pod-affinity].
 
@@ -226,14 +236,12 @@ This article focused on advanced Kubernetes scheduler features. For more informa
 * [Authentication and authorization][aks-best-practices-identity]
 
 <!-- EXTERNAL LINKS -->
-[k8s-taints-tolerations]: https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/
 [k8s-node-selector]: https://kubernetes.io/docs/concepts/configuration/assign-pod-node/
 [k8s-affinity]: https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity
 [k8s-pod-affinity]: https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#always-co-located-in-the-same-node
 
 <!-- INTERNAL LINKS -->
 [aks-best-practices-scheduler]: operator-best-practices-scheduler.md
-[aks-best-practices-cluster-isolation]: operator-best-practices-cluster-isolation.md
 [aks-best-practices-identity]: operator-best-practices-identity.md
 [use-multiple-node-pools]: use-multiple-node-pools.md
 [taint-node-pool]: use-multiple-node-pools.md#specify-a-taint-label-or-tag-for-a-node-pool