Hardening
Contexte et motivation
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 :
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 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.
Vous ne devez jamais utiliser la wildcard tolérance dans les applications, sinon l'effet préventif de cette solution ne sera pas valable.
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.
Comment désactiver / activer le hardening
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.
Last updated