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.
diff --git a/content/en/docs/reference/glossary/affinity.md b/content/en/docs/reference/glossary/affinity.md
new file mode 100644
index 0000000000..e5cfc92ea2
--- /dev/null
+++ b/content/en/docs/reference/glossary/affinity.md
@@ -0,0 +1,22 @@
+---
+title: Affinity
+id: affinity
+date: 2019-01-11
+full_link: /docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity
+short_description: >
+     Rules used by the scheduler to determine where to place pods
+aka:
+tags:
+- fundamental
+---
+
+In Kubernetes, _affinity_ is a set of rules that give hints to the scheduler about where to place pods.
+
+<!--more-->
+There are two kinds of affinity:
+* [node affinity](/docs/concepts/scheduling-eviction/assign-pod-node/#node-affinity)
+* [pod-to-pod affinity](/docs/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity)
+
+The rules are defined using the Kubernetes {{< glossary_tooltip term_id="label" text="labels">}},
+and {{< glossary_tooltip term_id="selector" text="selectors">}} specified in {{< glossary_tooltip term_id="pod" text="pods" >}}, 
+and they can be either required or preferred, depending on how strictly you want the scheduler to enforce them.