fix3

Author: mochizuki875

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

@@ -379,8 +379,9 @@ The keys are used to look up values from the pod labels; those key-value labels
 filtering selects the set of existing pods that will be taken into Pod (anti)affinity calculation.
 
 {{< caution >}}
-It's not recommended to use `matchLabelKeys` with labels that might be updated 
-because the update of the label isn't reflected onto the merged `labelSelector`.
+It's not recommended to use `matchLabelKeys` with labels that might be updated directly on pods.
+Even if you edit the pod's label that is specified at `matchLabelKeys` **directly**, (that is, not via a deployment),
+kube-apiserver doesn't reflect the label update onto the merged `labelSelector`.
 {{< /caution >}}
 
 A common use case is to use `matchLabelKeys` with `pod-template-hash` (set on Pods
@@ -431,8 +432,9 @@ or anti-affinity. The field specifies keys for the labels that should **not** ma
 when satisfying the Pod (anti)affinity.
 
 {{< caution >}}
-It's not recommended to use `matchLabelKeys` with labels that might be updated 
-because the update of the label isn't reflected onto the merged `labelSelector`.
+It's not recommended to use `mismatchLabelKeys` with labels that might be updated directly on pods.
+Even if you edit the pod's label that is specified at `mismatchLabelKeys` **directly**, (that is, not via a deployment),
+kube-apiserver doesn't reflect the label update onto the merged `labelSelector`.
 {{< /caution >}}
 
 One example use case is to ensure Pods go to the topology domain (node, zone, etc) where only Pods from the same tenant or team are scheduled in.