Hardening

Contexte et motivation

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 :

Assign CPU Resources to Containers and PodsKubernetes

Assign Memory Resources to Containers and PodsKubernetes

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

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

• Un esclave de hardening de pods par nœuds de travail : écrit la consommation de CPU et de RAM dans une base de données centralisée.

• Un pod de hardening-maître déployé sur les nœuds maîtres : il lit les métriques dans la base de données et prend des mesures en cas de crise.

• L'empreinte de la pile de hardening sur les ressources est très faible

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%, l'altération est supprimée.

• Mode de protection (en tant qu'assistant du contrôleur de 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.

Vous ne devez jamais utiliser la wildcard tolérance dans les applications, sinon l'effet préventif de cette solution ne sera pas valable.

Tolérance à éviter dans l'app

tolerations:
  - effect: NoSchedule
    operator: Exists

Limitation : cette solution ne permet pas de protéger les nœuds qui tombent en panne en raison d'un pic d'utilisation extrêmement élevé du CPU pendant une période de temps très courte.

Comment désactiver / activer le hardening

Le nouveau cluster Kubernetes sera provisionné avec le hardeing 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_K8_NODES), le mode de protection sera activé.

Le client peut désactiver ce hardening en créant un ticket requête dans ITCare.

Par conséquent, la vérification TLS_K8_NODES de centreon au niveau du cluster et la vérification de l'état de santé de centreon sur les nœuds de travail seront désactivées.

Cela signifie que les clients doivent redémarrer eux-mêmes les nœuds en cas de crise.

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