Added configuration for PodDisruptionBudget

[d7oc]

Description

This PR adds the configuration for PodDisruptionBudget. It can be configured globally and/or overwrites by service/app.

Related Issue

• Fixes add configuration for PodDisruptionBudget #149

Motivation and Context

Feature Request

How Has This Been Tested?

Tested with helm template and the following own values YAML:

features:
  basicAuthentication: true
podDisruptionBudget:
  maxUnavailable: 1
services:
 webdav:
   podDisruptionBudget:
     maxUnavailable: 2

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Technical debt
• Tests only (no source changes)

Checklist:

• Code changes
• Unit tests added
• Acceptance tests added
• Documentation generated (make docs) and committed
• Documentation ticket raised:
• Documentation PR created:

[d7oc]

@wkloucek It would be nice if we could harmonise the app names between the values file and the name of the app in the metadata in the future.

After this change the template I used for PDB generation could be reduced by one argument in the dict.

[wkloucek]

@wkloucek It would be nice if we could harmonise the app names between the values file and the name of the app in the metadata in the future.

After this change the template I used for PDB generation could be reduced by one argument in the dict.

I addressed this in #164. Something we should definitely do early (since it's most likely a breaking change)

[d7oc]

Then I would move this PR to draft until #164 is done and grab #164 in between. Fine for you?

[d7oc]

I converted the PR to draft right now to avoid accidental merging. I will address #164 first.

[d7oc]

Ready for final review and merge.

[wkloucek]

@d7oc wouldn't it make sense to add the PDB to all services?

From the docs (https://kubernetes.io/docs/tasks/run-application/configure-pdb/):

Single-instance Stateful Application:
Concern: do not terminate this application without talking to me.
Possible Solution 1: Do not use a PDB and tolerate occasional downtime.
Possible Solution 2: Set PDB with maxUnavailable=0. Have an understanding (outside of Kubernetes) that the cluster operator needs to consult you before termination. When the cluster operator contacts you, prepare for downtime, and then delete the PDB to indicate readiness for disruption. Recreate afterwards.

[wkloucek]

Otherwise looks good

[wkloucek]

There are some more no "Newline at end of file" files.

[d7oc]

@d7oc wouldn't it make sense to add the PDB to all services?

From the docs (https://kubernetes.io/docs/tasks/run-application/configure-pdb/):

Single-instance Stateful Application: Concern: do not terminate this application without talking to me. Possible Solution 1: Do not use a PDB and tolerate occasional downtime. Possible Solution 2: Set PDB with maxUnavailable=0. Have an understanding (outside of Kubernetes) that the cluster operator needs to consult you before termination. When the cluster operator contacts you, prepare for downtime, and then delete the PDB to indicate readiness for disruption. Recreate afterwards.

We can add it but as written in the statement the technical protection won't properly work there needs to be communication outside the Kubernetes environment. So to me the benefit is quite limited. And the downside I see is that people set this to 1 and start to wonder why the single-instance pods aren't updated.
How are chances that we get replica support for the outstanding services? That would be my preferred approach.

[wkloucek]

@d7oc wouldn't it make sense to add the PDB to all services?
From the docs (https://kubernetes.io/docs/tasks/run-application/configure-pdb/):
Single-instance Stateful Application: Concern: do not terminate this application without talking to me. Possible Solution 1: Do not use a PDB and tolerate occasional downtime. Possible Solution 2: Set PDB with maxUnavailable=0. Have an understanding (outside of Kubernetes) that the cluster operator needs to consult you before termination. When the cluster operator contacts you, prepare for downtime, and then delete the PDB to indicate readiness for disruption. Recreate afterwards.

We can add it but as written in the statement the technical protection won't properly work there needs to be communication outside the Kubernetes environment. So to me the benefit is quite limited. And the downside I see is that people set this to 1 and start to wonder why the single-instance pods aren't updated. How are chances that we get replica support for the outstanding services? That would be my preferred approach.

Fine for me. You're right some services' Deployment could be replaced by a StatefulSet (IDM, NATS, IDP; but we're not recommending to to use them anyways, so no priority). other services still wait to be scalable, see #15