Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Handle errors better in the disruption controller #85553
What type of PR is this?
What this PR does / why we need it:
For the example described in the issue, the controller will now compute the allowed disruptions based only on the pods that belongs to the Deployment. So the status of the pdb will be set as if the pod from the CronJob never existed. During an eviction, the pod from the CronJob will be covered by the pdb which means it will affect the number of pods belonging to the PDB that can be disrupted at the same time. But this just means that eviction will take slightly longer than if the pod was not included in the PDB and the number of disrupted pods belonging to the Deployment will never drop below the threshold in the PDB.
Which issue(s) this PR fixes:
Special notes for your reviewer:
Does this PR introduce a user-facing change?:
Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.:
[APPROVALNOTIFIER] This PR is NOT APPROVED
The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing
It would be helpful to decide/document/test the behavior or derived scale in the following scenarios (it's possible this is already documented somewhere but I had a hard time finding it, and the documentation I did find didn't seem to agree with either the code or the API docs):
* add configurable PDB for minio * change label for post-install-create-bucket-job because until kubernetes/kubernetes#85553 is merged, PDB will also detect the minio-create-bucket-job and PDB won't work correctly (kubernetes/kubernetes#77383) Signed-off-by: Mario Constanti <firstname.lastname@example.org> Signed-off-by: Artur <email@example.com>