# Hardening

## Contexte et motivation <a href="#kubernetesclusterhardening-contexteetmotivation" id="kubernetesclusterhardening-contexteetmotivation"></a>

**cegedim.cloud** fournit des clusters Kubernetes certifiés CNCF, garantissant la conformité aux normes et aux meilleures pratiques de l'industrie.

Kubernetes dispose de fonctionnalités et de mécanismes intégrés pour maintenir en bonne santé les nœuds et les workoads kubernetes :

* kube-scheduler décide sur quels nœuds placer les pods en fonction des ressources demandées par les pods et des ressources non réservées des nœuds.
* kubelet Out-Of-Memory tue les pods qui consomment plus de ressources que les valeurs limitées définies dans la spécification (OOM killed).
* Pour quelque raison que ce soit, si le nœud est à court de ressources, kubelet expulse les pods afin d'alléger la pression sur les nœuds (éviction des pods). La décision d'éviction des pods est basée sur la qualité de service des pods.

Gardez à l'esprit que **cegedim.cloud** fournit des clusters Kubernetes standard avec ces fonctionnalités et a qualifié les documentations officielles de Kubernetes ci-dessous :

{% embed url="<https://kubernetes.io/docs/tasks/configure-pod-container/assign-cpu-resource/>" %}

{% embed url="<https://kubernetes.io/docs/tasks/configure-pod-container/assign-memory-resource/>" %}

Le problème se situe au niveau de l'application dans la vie réelle :

* toutes les technologies ne sont pas nativement compatibles avec les conteneurs
* les mesures d'utilisation des ressources collectées par le kubelet (ou l'exportateur de nœuds, etc.) ne sont pas en temps réel
* les mesures d'utilisation des ressources ne sont pas prises en compte par le planificateur kube
* kubelet, en tant que processus Linux, n'est pas toujours le processus le plus prioritaire, en particulier lorsque les nœuds n'ont plus de CPU.

L'incapacité à gérer les contraintes de ressources sur les nœuds par kubelet conduit à des défaillances de nœuds et au redéploiement de toutes les charges de travail correspondantes. Dans le pire des cas, un effet domino sur la défaillance des nœuds peut se produire.

## La solution cegedim.cloud <a href="#kubernetesclusterhardening-lasolutioncegedim.cloud" id="kubernetesclusterhardening-lasolutioncegedim.cloud"></a>

**cegedim.cloud** fournit une solution de hardening appelée cgdm-hardening :

* Un pod hardening-slave par nœud de travail : écrit la consommation de CPU et de RAM dans une base de données centralisée
* Un pod hardening-master déployé sur les nœuds maîtres : lit les métriques dans la base de données et prend des mesures en cas de crise
* La pile de hardening a une empreinte de ressources très faible
* cgdm-hardening est également capable de détecter les problèmes réseau présents sur les nœuds et les étiquette avec **cegedim.io/network=broken** pour une visibilité opérationnelle

Le pod hardening-master peut agir selon deux modes :

* Mode préventif (en tant qu'assistant du planificateur kube, mode par défaut) : place le taint **cegedim.io/overload=true:NoSchedule** pour éviter de placer plus de pods sur des nœuds sous pression (85% RAM ou 90% CPU). Lorsque le CPU est inférieur à 85% et que la RAM est inférieure à 80%, le taint est supprimé.
* Mode de protection (en tant qu'assistant du contrôleur kube) : lorsque la consommation de RAM atteint 95%, il tue les pods les plus récents, l'un après l'autre, pour soulager la pression. Il n'est pas activé par défaut.

{% hint style="warning" %}
Vous ne devez jamais utiliser la wildcard tolérance dans les applications, sinon l'effet préventif de cette solution ne sera pas valable.
{% endhint %}

<pre class="language-yaml" data-title="Tolérance à éviter dans l&#x27;app" data-line-numbers><code class="lang-yaml"><strong>tolerations:
</strong>  - effect: NoSchedule
    operator: Exists
</code></pre>

{% hint style="warning" %}
**Limitation :** Les pannes de nœuds dues à des pics extrêmement élevés de CPU pendant une période très courte ne peuvent pas être atténuées avec cette solution.
{% endhint %}

## Comment désactiver / activer le hardening <a href="#kubernetesclusterhardening-commentdesactiver-activerlehardening" id="kubernetesclusterhardening-commentdesactiver-activerlehardening"></a>

Les nouveaux clusters Kubernetes seront provisionnés avec le hardening préventif activé.

Si les charges de travail déployées par les clients entraînent un grand nombre de défaillances de nœuds (TLS\_K8S\_NODES), le mode de protection sera activé.

Le client peut désactiver ce hardening en créant un ticket de requête ITCare.\
Cela signifie que le client devra redémarrer les nœuds lui-même en cas de crise.

Le client peut réactiver ce hardening en créant un ticket de requête ITCare à tout moment.