we need this part in case somebody would do PodRunning -> InvalidValue after we disable the feature, since it also turns off validations for podHealthyPolicy field

drop this case, validation runs if the field is non-nil regardless of feature gate

I have changed the descriptions as compared to the KEP.

I have replaced legacy with default. I would argue this is not a legacy behaviour as it is just a different way of handling a PDB and pods and some people may prefer the original one to achieve the least disruption to their application. App Running pods have a chance to become Ready, without getting disrupted.

Also, wouldn't it be better to have eg. a PodReadyStrict or Default policy. So the behaviour would be on par with the other policies? We could set it on admission by default. Only old PDBs that were not updated would be still empty.

Yeah, that's fair, make sure to update the KEP to match this implementation as well.

Huh... I wasn't expecting the controller to change at all. I have a hard time seeing a use case for the controller changing to include running-but-not-ready pods in pdb.Status.CurrentHealthy.

I thought the option we were adding was strictly around the eviction logic, whether to unconditionally allow eviction of unready pods, regardless of pdb.Status.CurrentHealthy. That would avoid changing the controller at all, and limit the entire functional change to:

 		// If the pod is not ready, it doesn't count towards healthy and we should not decrement
-		if !podutil.IsPodReady(pod) && pdb.Status.CurrentHealthy >= pdb.Status.DesiredHealthy && pdb.Status.DesiredHealthy > 0 {
-			updateDeletionOptions = true
-			return nil
+		if !podutil.IsPodReady(pod) {
+			if utilfeature.DefaultFeatureGate.Enabled(features.UnreadyEvictionPolicy) {
+				if pdb.Spec.UnreadyEvictionPolicy != nil && *pdb.Spec.UnreadyEvictionPolicy == policy.AlwaysAllow {
+					updateDeletionOptions = true
+					return nil
+				}
+			}
+			if pdb.Status.CurrentHealthy >= pdb.Status.DesiredHealthy && pdb.Status.DesiredHealthy > 0 {
+				updateDeletionOptions = true
+				return nil
+			}
 		}

Do you have a pointer to the discussion around the decision to shift the design from narrowly modifying the eviction behavior to changing how the controller computes healthy pods?

cc folks on the KEP reviews: @wojtek-t, @ravisantoshgudimetla, in addition to @soltysh

@soltysh, @atiratree and I synced offline

The status.currentHealthy / status.desiredHealthy / status.disruptionsAllowed fields reflect ready pods today. Redefining those fields to be something other than ready pods seems problematic. Also, none of us could come up with a clear use case for considering running-but-not-ready pods as healthy.

The motivation for this new field and the KEP was to let PDB authors define policies that would not block eviction of unready pods, regardless of the count of healthy pods (to fix things like #72320)

We agreed to scope this change down to a field targeting specifically that use case, and to pair it with a narrow change just to the eviction logic for unready pods.

The proposed field is:

type UnreadyPodEvictionPolicyType string

// unreadyPodEvictionPolicy determines how pods which are running (status.phase="Running")
// but not yet ready (no status.conditions item with type=Ready,status=True) are handled by the eviction endpoint.
unreadyPodEvictionPolicy *UnreadyPodEvictionPolicyType `json:"...`

The allowed values would be:

• "IfHealthyBudget" - allow if pdb.Status.CurrentHealthy >= pdb.Status.DesiredHealthy && pdb.Status.DesiredHealthy > 0 - current behavior at

  kubernetes/pkg/registry/core/pod/storage/eviction.go

  Lines 229 to 230 in 81bd249

  	// If the pod is not ready, it doesn't count towards healthy and we should not decrement
  	if !podutil.IsPodReady(pod) && pdb.Status.CurrentHealthy >= pdb.Status.DesiredHealthy && pdb.Status.DesiredHealthy > 0 {

• "AlwaysAllow" - always allow evicting a running-but-unready pod
• null - default, same behavior as "IfHealthyBudget"

(I don't love the IfHealthyBudget name... that's sort of a placeholder so @atiratree can get started tweaking this PR... if @ravisantoshgudimetla or @wojtek-t or others have a better way to describe the current behavior, we're totally open to it)

@liggitt @soltysh

I have synced with @ravisantoshgudimetla, and it seems it would be better to change the name of the field from UnreadyPodEvictionPolicy -> UnhealthyPodEvictionPolicy, to cover future changes to the healthy definition. Users might want to define themselves when their pod becomes healthy. We still will have a binary way of deciding what pod to evict and what not, based on the "healthiness". So I think the current names IfHealthyBudget and AlwaysAllow are still fitting. Also, users are used to this naming from the PDB status.

Can I update the name and make the document it in the types in a better way to make it a bit more future proof?

I think we would have a hard time redefining "healthy" in the future to mean something else.

That said, I agree "unhealthy" is consistent with PDB status fields and the "IfHealthyBudget" policy, and the controller currently determines healthy as "ready and not being deleted", which matches what we want to allow here, so using that term in this field name sounds reasonable, even if we never change the definition of unhealthy in the future.

If we decide to change healthy definition for PDB it will require much more thorough changes given the current naming in the API.

we discussed that it should be probably based on pod readiness gates and we would need to figure out in a new KEP how to make it configurable and backwards compatible with the current solution. But it should be possible with the current changes.

as a follow-up before beta, consider whether we want to leave the default implicit ("this is how we will handle null") or make it explicit with API defaulting (so a null field would actually get populated with IfHealthyBudget). We don't have to decide that now, since the defaulting would be feature-gated, so null values would still have to be documented/handled, but include this in the list of questions to resolve before beta.

noted, will add to the KEP update