diff --git a/content/en/docs/concepts/scheduling-eviction/pod-priority-preemption.md b/content/en/docs/concepts/scheduling-eviction/pod-priority-preemption.md
index 112e244f46..fe49f2acd4 100644
--- a/content/en/docs/concepts/scheduling-eviction/pod-priority-preemption.md
+++ b/content/en/docs/concepts/scheduling-eviction/pod-priority-preemption.md
@@ -252,12 +252,12 @@ Even so, the answer to the preceding question must be yes. If the answer is no,
 the Node is not considered for preemption.
 {{< /note >}}
 
-If a pending Pod has inter-pod affinity to one or more of the lower-priority
-Pods on the Node, the inter-Pod affinity rule cannot be satisfied in the absence
-of those lower-priority Pods. In this case, the scheduler does not preempt any
-Pods on the Node. Instead, it looks for another Node. The scheduler might find a
-suitable Node or it might not. There is no guarantee that the pending Pod can be
-scheduled.
+If a pending Pod has inter-pod {{< glossary_tooltip text="affinity" term_id="affinity" >}}
+to one or more of the lower-priority Pods on the Node, the inter-Pod affinity
+rule cannot be satisfied in the absence of those lower-priority Pods. In this case, 
+the scheduler does not preempt any Pods on the Node. Instead, it looks for another
+Node. The scheduler might find a suitable Node or it might not. There is no 
+guarantee that the pending Pod can be scheduled.
 
 Our recommended solution for this problem is to create inter-Pod affinity only
 towards equal or higher priority Pods.