Skip to content

Update eck pdb docs #2361

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
wants to merge 2 commits into
base: main
Choose a base branch
from
Open

Update eck pdb docs #2361

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
fd4bc26
Adjusting ECK PDB documentation for upcoming changes.
naemono Aug 1, 2025
eb666da
Adjust wording.
naemono Aug 1, 2025
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
28 changes: 23 additions & 5 deletions deploy-manage/deploy/cloud-on-k8s/pod-disruption-budget.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -12,7 +12,28 @@ products:

A [Pod Disruption Budget](https://kubernetes.io/docs/tasks/run-application/configure-pdb/) (PDB) allows you to limit the disruption to your application when its pods need to be rescheduled for some reason such as upgrades or routine maintenance work on the Kubernetes nodes.

ECK manages a default PDB per {{es}} resource. It allows one {{es}} Pod to be taken down, as long as the cluster has a `green` health. Single-node clusters are not considered highly available and can always be disrupted.
ECK manages either a single default PDB, or multiple PDBs per {{es}} resource according to the license available.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does the user have to be on a stack 9.2 cluster as well as use ECK 3.2?

Consider this approach. More tagging / clarification might be necessary if the stack version is also a factor.

We have a couple of other ways we could do this with heading tagging or tabs, but this is probably a nice lightweight way to do it

Suggested change
ECK manages either a single default PDB, or multiple PDBs per {{es}} resource according to the license available.
ECK manages either a single default PDB, or multiple PDBs per {{es}} resource according to the license available.
:::{note}
In ECK 3.1 and earlier, all clusters follow the [non-enterprise behavior](#non-enterprise-licensed-customers), regardless of license type.
:::


## Enterprise licensed customers
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
## Enterprise licensed customers
## Enterprise licensed customers
```{applies_to}
deployment:
eck: ga 3.2
```


A separate PDB is created for each type of nodeSet defined in the manifest allowing upgrade or maintenance operations to be more quickly executed. The PDBs allow one {{es}} Pod per nodeSet to simultaneously be taken down as long as the cluster has the health defined in the following table:

| Role | Cluster Health Required | Notes |
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
| Role | Cluster Health Required | Notes |
| Role | Cluster health required | Notes |

|------|------------------------|--------|
| Master | Yellow | |
| Data | Green | All Data roles are grouped together into a single PDB, except for data_frozen. |
| Data Frozen | Yellow | Since the frozen tier are essentially stateless, managing searchable snapshots, additional disruptions are allowed. |
| Ingest | Yellow | |
| ML | Yellow | |
| Coordinating | Yellow | |
| Transform | Yellow | |
| Remote Cluster Client | Yellow | |
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
| Remote Cluster Client | Yellow | |
| Remote cluster client | Yellow | |


Single-node clusters are not considered highly available and can always be disrupted.

## Non-enterprise licensed customers
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
## Non-enterprise licensed customers
## Non-enterprise licensed customers
:::{note}
In ECK 3.1 and earlier, all clusters follow this behavior regardless of license type.
:::


It allows one {{es}} Pod to be taken down, as long as the cluster has a `green` health. Single-node clusters are not considered highly available and can always be disrupted.

In the {{es}} specification, you can change the default behavior as follows:
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do the instructions below this line only apply to non-enterprise? if not, you might want to change the headings a little:

## Default behavior
... 
### Enterprise licensed customers
...
### Non-enterprise licensed customers
...
## Override the default behavior
...
## Pod disruption budget ...


Expand All @@ -34,7 +55,7 @@ spec:
elasticsearch.k8s.elastic.co/cluster-name: quickstart
```

::::{note}
::::{note}
[`maxUnavailable`](https://kubernetes.io/docs/tasks/run-application/configure-pdb/#arbitrary-controllers-and-selectors) cannot be used with an arbitrary label selector, therefore `minAvailable` is used in this example.
::::

Expand Down Expand Up @@ -81,6 +102,3 @@ spec:
4. Pod disruption budget applies on all master nodes.
5. Specify pod disruption budget to have 1 hot node available.
6. Pod disruption budget applies on nodes of the same nodeset.



Loading