Add deprecation notices related to matchLabelKeys/mismatchLabelKeys

Author: mochizuki875

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

@@ -377,6 +377,8 @@ when satisfying the Pod (anti)affinity.
 The keys are used to look up values from the pod labels; those key-value labels are combined
 (using `AND`) with the match restrictions defined using the `labelSelector` field. The combined
 filtering selects the set of existing pods that will be taken into Pod (anti)affinity calculation.
+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`.
 
 A common use case is to use `matchLabelKeys` with `pod-template-hash` (set on Pods
 managed as part of a Deployment, where the value is unique for each revision).
@@ -424,6 +426,8 @@ When you want to disable it, you have to disable it explicitly via the
 Kubernetes includes an optional `mismatchLabelKeys` field for Pod affinity
 or anti-affinity. The field specifies keys for the labels that should **not** match with the incoming Pod's labels,
 when satisfying the Pod (anti)affinity.
+It's not recommended to use `mismatchLabelKeys` with labels that might be updated 
+because the update of the label isn't reflected onto the merged `LabelSelector`.
 
 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.
 In other words, you want to avoid running Pods from two different tenants on the same topology domain at the same time.