Skip to content

Commit 4798193

Browse files
authored
Merge pull request #39670 from i8r/main
Clarify PDB maxUnavailable rounding logic
2 parents 1d514a5 + 6297df7 commit 4798193

File tree

1 file changed

+8
-4
lines changed

1 file changed

+8
-4
lines changed

content/en/docs/tasks/run-application/configure-pdb.md

Lines changed: 8 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -86,12 +86,14 @@ Values for `minAvailable` or `maxUnavailable` can be expressed as integers or as
8686
- When you specify an integer, it represents a number of Pods. For instance, if you set `minAvailable` to 10, then 10
8787
Pods must always be available, even during a disruption.
8888
- When you specify a percentage by setting the value to a string representation of a percentage (eg. `"50%"`), it represents a percentage of
89-
total Pods. For instance, if you set `maxUnavailable` to `"50%"`, then only 50% of the Pods can be unavailable during a
89+
total Pods. For instance, if you set `minAvailable` to `"50%"`, then at least 50% of the Pods remain available during a
9090
disruption.
9191

9292
When you specify the value as a percentage, it may not map to an exact number of Pods. For example, if you have 7 Pods and
9393
you set `minAvailable` to `"50%"`, it's not immediately obvious whether that means 3 Pods or 4 Pods must be available.
94-
Kubernetes rounds up to the nearest integer, so in this case, 4 Pods must be available. You can examine the
94+
Kubernetes rounds up to the nearest integer, so in this case, 4 Pods must be available. When you specify the value
95+
`maxUnavailable` as a percentage, Kubernetes rounds up the number of Pods that may be disrupted. Thereby a disruption
96+
can exceed your defined `maxUnavailable` percentage. You can examine the
9597
[code](https://github.com/kubernetes/kubernetes/blob/23be9587a0f8677eb8091464098881df939c44a9/pkg/controller/disruption/disruption.go#L539)
9698
that controls this behavior.
9799

@@ -129,8 +131,10 @@ of the number of desired replicas are healthy.
129131
Example 3: With a `maxUnavailable` of 5, evictions are allowed as long as there are at most 5
130132
unhealthy replicas among the total number of desired replicas.
131133

132-
Example 4: With a `maxUnavailable` of 30%, evictions are allowed as long as no more than 30%
133-
of the desired replicas are unhealthy.
134+
Example 4: With a `maxUnavailable` of 30%, evictions are allowed as long as the number of
135+
unhealthy replicas does not exceed 30% of the total number of desired replica rounded up to
136+
the nearest integer. If the total number of desired replicas is just one, that single replica
137+
is still allowed for disruption, leading to an effective unavailability of 100%.
134138

135139
In typical usage, a single budget would be used for a collection of pods managed by
136140
a controller—for example, the pods in a single ReplicaSet or StatefulSet.

0 commit comments

Comments
 (0)