activator's PDB creates with no disruptionsAllowed when there are a few replicas

[nak3]

Since knative/serving@591510c was introduced, activator's PDB has 80% and operator includes the PDB without any change.
PDB 80% creates with zero disruptionsAllowed even if we have 2 or some replicas, so it will block an eviction.

e.g. Even 2 activator replicas, disruptionsAllowed is zero.

spec:
  minAvailable: 80%
  selector:
    matchLabels:
      app: activator
status:
  currentHealthy: 2
  desiredHealthy: 2
  disruptionsAllowed: 0
  expectedPods: 2
  observedGeneration: 1

The users who installed Knaative by operator cannot modify the PDB so operator should manage the PDB well or document this HA restriction.

[nak3]

FYI @vagababov @julz

[github-actions]

This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Reopen the issue with /reopen. Mark the issue as
fresh by adding the comment /remove-lifecycle stale.

[Fabian-K]

Because the PDB cannot be configured using the operator, currently the only way to get 1 allowed disruption is to run 5 replicas. Do you consider making this configurable or changing the PDB itself?

[marcomancini1994]

We are actually facing the same issue when using the Knative Operator, are you guys planning to release this feature in the next release? (e.g 0.23.0)

[matzew]

The same is true for eventing, not just the serving PDB.

[matzew]

/cc @houshengbo @lionelvillard

[Morriz]

bump

[treyhyde]

I have really struggled with this one. Finally buckled down and added the 5 replicas so I could actually shut things down without manual intervention only to discover that cluster-autoscaler.kubernetes.io/safe-to-evict: "false" is sprinkled everywhere. Is there documentation somewhere suggesting why this stuff isn't safe to evict?

[nak3]

I think this issue should be fixed before Beta/GA. There are some options for the solutions like:

• option-1. Support fully customizable pdb.
• option-2. Support only enable or disable option for pdb.
• option-3. Do not include pdb manifest at all.
• option-4. Support "automatic" pdb based on the number of replicas.

Probably option-2 (like spec.high-availability) or option-1 would be alright?

[treyhyde]

option 1 seems like a good path, but frankly, a more reasonable default would go a long way. (minAvailable: 1 or maxDisruptions: 1)

[peteroruba]

We are also stuck with this issue when it comes to replacing worker nodes.

[bartusz01]

hi @nak3 any update on this?

[Legion2]

Instead of using minAvailable 80% I use maxUnavailable 20%, which works with 2 replicas

[nak3]

@bartusz01 No, I'm not working on it.

[isaac88]

Hello @nak3 @matzew @julz,
Do you have the ETA for that ?
Best regards.

[nak3]

@isaac88 Sorry I am not working on it so I have no idea.

[github-actions]

This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Reopen the issue with /reopen. Mark the issue as
fresh by adding the comment /remove-lifecycle stale.

[Morriz]

bump