01. October 2023

Enoncé TP 9

/images/k8s.jpeg

TP9 - QosClass, resource management & PDB (PodDisruptionBudget)

🇫🇷 Version Française

Kubernetes gére lui même la gestion du CPU, du disque et de la Mémoire de ses noeuds, en cas de MemoryPressure par exemple il peu choisir d’éliminer un pod pour libérer de la mémoire.

Il est possible de lui indiquer quel pod éliminer dans ces cas là.

QosClass & gestion des ressources

Se placer dans un namespace de notre application.

kub get pod -o jsonpath="{range .items[*]}{@.metadata.name} -> {@.status.qosClass};{end}" | tr “;” “\n”

Rappel:

Pour l’instant tous les pods sont en BestEffort, ça veut dire que si le cluster doit tuer (passer au status evicted) un pod il va d’abord tuer un de ceux là.

Il va choisir dans l’ordre les pods en BestEffort -> Burstable -> Guaranteed

Pour changer ça il faut ajouter une request et une limit au pod afin de modifier sa QosClass.

L’attribution des QosClass se fait comme suit :

  • BestEffort -> aucun container n’a de request ou de limit.
  • Burstable -> au moins un container a une request de définie
  • Guaranteed -> tous les containers ont une request et une limit de CPU et de Mémoire égales.

(faculatif: Tester les attributions de QosClass)

Donner des requests memory aux pods backend de 1G (volontairement trop élévé pour un prochain TP)

Verifier que la QosClass des pods backend modifié ont bien changé.

PDB (Pod Disruption Budget)

Un pod disruption budget permet de créér des régles de gestion des réplicas lorsqu’un noeud veut tuer des pods.

Un PDB se contruit comme suit :

1apiVersion: policy/v1beta1
2kind: PodDisruptionBudget
3metadata:
4  name: backend-pdb
5spec:
6  minAvailable: 2
7  selector:
8    matchLabels:
9      app: back-training-app

Il utilise le selector.matchLabels pour déterminer sur quels groupes de pods il va agir. Et il a comme régle d’interdir l’évition d’un pod si il n’en reste plus que minAvailable (ici 2). (le même principe existe avec la spec maxUnavailable)

La valeur de minAvailable ou de maxUnavailable peut etre un nombre ou un pourcentage.

Pas besoin de créér de PDB dans ces TPs.

🇬🇧 English version

Kubernetes itself manages the CPU, disk and Memory of its nodes, in the case of MemoryPressure for example it can choose to eliminate a pod to free up memory.

It is possible to tell it which pod to eliminate in these cases.

QosClass & resource management

Place yourself in a namespace of our application.

kub get pod -o jsonpath="{range .items[*]}{@.metadata.name} -> {@.status.qosClass};{end}" | tr “;” “\n”

Reminder:

For the moment all pods are in BestEffort, this means that if the cluster has to kill (go to evicted status) a pod it will first kill one of these.

It will choose in order the pods in BestEffort -> Burstable -> Guaranteed

To change this you must add a request and a limit to the pod in order to modify its QosClass.

The allocation of QosClass is done as follows:

  • BestEffort -> no container has any request or limit.
  • Burstable -> at least one container with a defined request
  • Guaranteed -> all containers have equal CPU and Memory request and limit.

(optional: Test QosClass assignments)

Give 1G of memory requests to backend pods (deliberately too high for a future practical)

Verify that the QosClass of the modified backend pods has changed.

PDB (Pod Disruption Budget)

A pod disruption budget allows you to create replica management rules when a node wants to kill pods.

A PDB is constructed as follows:

1apiVersion: policy/v1beta1
2kind: PodDisruptionBudget
3metadata:
4  name: backend-pdb
5spec:
6  minAvailable: 2
7  selector:
8    matchLabels:
9      app: back-training-app

It uses the selector.matchLabels to determine which pod groups it will act on. And it has the rule to prohibit the avoidance of a pod if there is only minAvailable left (here 2). (the same principle exists with the maxUnavailable spec)

The value of minAvailable or maxUnavailable can be a number or a percentage.

No need to create a PDB in these TPs.

Latest Posts