removes incorrect explanation for topologyKey in an affinity or anti-…

…affinity rule (#1)

The existing text does not make sense to me.  

There is no zone "V" or "R" in the example.  

I have changed the text to be consistent with top answer here which seems to make more sense: https://stackoverflow.com/questions/72240224/what-is-topologykey-in-pod-affinity

content/en/docs/concepts/scheduling-eviction/assign-pod-node.md

@@ -295,16 +295,12 @@ Pod affinity rule uses the "hard"
 uses the "soft" `preferredDuringSchedulingIgnoredDuringExecution`.
 
 The affinity rule says that the scheduler can only schedule a Pod onto a node if
-the node is in the same zone as one or more existing Pods with the label
-`security=S1`. More precisely, the scheduler must place the Pod on a node that has the
-`topology.kubernetes.io/zone=V` label, as long as there is at least one node in
-that zone that currently has one or more Pods with the Pod label `security=S1`.
+the node is in the same zone (`topologyKey: topology.kubernetes.io/zone`) as one or more existing Pods with the label
+`security=S1`.
 
 The anti-affinity rule says that the scheduler should try to avoid scheduling
-the Pod onto a node that is in the same zone as one or more Pods with the label
-`security=S2`. More precisely, the scheduler should try to avoid placing the Pod on a node that has the
-`topology.kubernetes.io/zone=R` label if there are other nodes in the
-same zone currently running Pods with the `Security=S2` Pod label.
+the Pod onto a node that is in the same zone (`topologyKey: topology.kubernetes.io/zone`) as one or more Pods with the label
+`security=S2`.
 
 To get yourself more familiar with the examples of Pod affinity and anti-affinity,
 refer to the [design proposal](https://git.k8s.io/design-proposals-archive/scheduling/podaffinity.md).