Skip to content

ECK: mention PodTopologyLabelsAdmission #4660

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
barkbay wants to merge 6 commits into
base: main
Choose a base branch
from
Open

ECK: mention PodTopologyLabelsAdmission #4660

Changes from 5 commits
Commits
Show all changes
6 commits
Select commit Hold shift + click to select a range
0dd63ab
ECK: mention PodTopologyLabelsAdmission
barkbay Jan 15, 2026
5dc6e7b
update
barkbay Jan 15, 2026
788f187
Don't use "note that"
barkbay Jan 15, 2026
8e2f5ff
Consider using "can, might" instead of may
barkbay Jan 15, 2026
932d970
minor fix
barkbay Jan 15, 2026
a43915b
Update deploy-manage/deploy/cloud-on-k8s/advanced-elasticsearch-node-…
barkbay Jan 15, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 3 additions & 0 deletions deploy-manage/deploy/cloud-on-k8s/advanced-elasticsearch-node-scheduling.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -203,6 +203,9 @@ This example restricts {{es}} nodes so they are only scheduled on Kubernetes hos
Starting with ECK 2.0 the operator can make Kubernetes Node labels available as Pod annotations. It can be used to make information, such as logical failure domains, available in a running Pod. Combined with [{{es}} shard allocation awareness](elasticsearch://reference/elasticsearch/configuration-reference/cluster-level-shard-allocation-routing-settings.md) and [Kubernetes topology spread constraints](https://kubernetes.io/docs/concepts/workloads/pods/pod-topology-spread-constraints/), you can create an availability zone-aware {{es}} cluster.

### 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 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 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/.*`.
2. On the {{es}} resources set the `eck.k8s.elastic.co/downward-node-labels` annotations with the list of the Kubernetes node labels that should be copied as Pod annotations.
Expand Down
Loading