Consider using "can, might" instead of may

Author: barkbay

deploy-manage/deploy/cloud-on-k8s/advanced-elasticsearch-node-scheduling.md

@@ -204,7 +204,7 @@ Starting with ECK 2.0 the operator can make Kubernetes Node labels available as
 
 ### Exposing Kubernetes node topology labels in Pods [k8s-availability-zone-awareness-downward-api]
 :::{note}
-With Kubernetes 1.35 and later, the `PodTopologyLabelsAdmission` feature is enabled by default. As a result, the labels `topology.kubernetes.io/region` and `topology.kubernetes.io/zone` from the node are automatically propagated as labels on Pods. Consequently, you may not need to use the `eck.k8s.elastic.co/downward-node-labels` annotation or make additional configuration changes to expose these topology labels in your Pods. In this situation, you can skip the first two steps described below. Additionally, in this scenario, node labels appear as Pod labels rather than annotations.
+With Kubernetes 1.35 and later, the `PodTopologyLabelsAdmission` feature is enabled by default. As a result, the labels `topology.kubernetes.io/region` and `topology.kubernetes.io/zone` from the node are automatically propagated as labels on Pods. Consequently, you can skip using the `eck.k8s.elastic.co/downward-node-labels` annotation or making additional configuration changes to expose these topology labels in your Pods. In this situation, you can skip the first two steps described below. Additionally, in this scenario, node labels might appear as Pod labels rather than annotations.
 :::
 
 1. First, ensure that the operator’s flag `exposed-node-labels` contains the list of the Kubernetes node labels that should be exposed in the {{es}} Pods. If you are using the provided installation manifest, or the Helm chart, then this flag is already preset with two wildcard patterns for well-known node labels that describe Kubernetes cluster topology, like `topology.kubernetes.io/.*` and `failure-domain.beta.kubernetes.io/.*`.