La mise à l'échelle automatique des grappes ne se réduit pas
J'ai un cluster régional mis en place dans google kubernetes engine (GKE). Le groupe de noeuds est constitué d'un seul vm dans chaque région (3 au total). J'ai un déploiement avec 3 répliques minimum contrôlé par un HPA . Le groupe de nœuds est configuré pour être autoscaling (cluster autoscaling aka CA) . Le scénario du problème:
Mettre à jour l'image de déploiement. Kubernetes crée automatiquement de nouveaux pods et l'autorité de certification identifie le besoin d'un nouveau nœud. J'ai maintenant 4 . Les anciens pods sont supprimés lorsque tous les nouveaux pods ont démarré, ce qui signifie que j'ai exactement la même demande de processeur que la minute précédente. Mais au bout des 10 minutes d’échelle maximale, il me reste 4 nœuds.
Les demandes de la CPU pour les nœuds sont maintenant:
CPU Requests CPU Limits Memory Requests Memory Limits
------------ ---------- --------------- -------------
358m (38%) 138m (14%) 516896Ki (19%) 609056Ki (22%)
--
CPU Requests CPU Limits Memory Requests Memory Limits
------------ ---------- --------------- -------------
800m (85%) 0 (0%) 200Mi (7%) 300Mi (11%)
--
CPU Requests CPU Limits Memory Requests Memory Limits
------------ ---------- --------------- -------------
510m (54%) 100m (10%) 410Mi (15%) 770Mi (29%)
--
CPU Requests CPU Limits Memory Requests Memory Limits
------------ ---------- --------------- -------------
823m (87%) 158m (16%) 484Mi (18%) 894Mi (33%)
Le nœud 38% est en cours d'exécution:
Namespace Name CPU Requests CPU Limits Memory Requests Memory Limits
--------- ---- ------------ ---------- --------------- -------------
kube-system event-exporter-v0.1.9-5c8fb98cdb-8v48h 0 (0%) 0 (0%) 0 (0%) 0 (0%)
kube-system fluentd-gcp-v2.0.17-q29t2 100m (10%) 0 (0%) 200Mi (7%) 300Mi (11%)
kube-system heapster-v1.5.2-585f569d7f-886xx 138m (14%) 138m (14%) 301856Ki (11%) 301856Ki (11%)
kube-system kube-dns-autoscaler-69c5cbdcdd-rk7sd 20m (2%) 0 (0%) 10Mi (0%) 0 (0%)
kube-system kube-proxy-gke-production-cluster-default-pool-0fd62aac-7kls 100m (10%) 0 (0%) 0 (0%) 0 (0%)
Je soupçonne qu’il ne sera pas moins performant parce que Heapster ou kube-dns-autoscaler . Mais le pod de 85% contient:
Namespace Name CPU Requests CPU Limits Memory Requests Memory Limits
--------- ---- ------------ ---------- --------------- -------------
kube-system fluentd-gcp-v2.0.17-s25bk 100m (10%) 0 (0%) 200Mi (7%) 300Mi (11%)
kube-system kube-proxy-gke-production-cluster-default-pool-7ffeacff-mh6p 100m (10%) 0 (0%) 0 (0%) 0 (0%)
my-deploy my-deploy-54fc6b67cf-7nklb 300m (31%) 0 (0%) 0 (0%) 0 (0%)
my-deploy my-deploy-54fc6b67cf-zl7mr 300m (31%) 0 (0%) 0 (0%) 0 (0%)
Les pods fluentd et kube-proxy sont présents sur chaque nœud, donc je suppose qu'ils ne sont pas nécessaires sans le nœud. Ce qui signifie que mon déploiement pourrait être déplacé vers les autres nœuds puisqu'il ne dispose que d'une requête de 300 m (31%, puisque 94% seulement des processeurs de nœud peuvent être alloués).
J'ai donc pensé que je vérifierais les journaux. Mais si je lance kubectl get pods --all-namespaces, aucun module n'est visible sur GKE pour l'autorité de certification. Et si j’utilise la commande kubectl get configmap cluster-autoscaler-status -n kube-system -o yaml, elle ne me dit que si elle est sur le point d’être mise à l’échelle, mais pas pourquoi ni pourquoi .. .. Une autre option consiste à consulter /var/log/cluster-autoscaler.log dans le nœud principal. I SSH: ed dans les 4 noeuds et seulement trouvé un fichier gcp-cluster-autoscaler.log.pos qui dit: /var/log/cluster-autoscaler.log 0000000000000000 0000000000000000 ce qui signifie que le fichier doit être là mais qu'il est vide . Dernière option en fonction du FAQ , est de vérifiez les événements pour les pods, mais pour autant que je sache, ils sont vides.
Quelqu'un sait pourquoi il ne va pas en bas ou au moins où trouver les journaux?
Me répondre pour la visibilité.
Le problème est que l'autorité de certification ne considère jamais de déplacer quoi que ce soit à moins que toutes les conditions mentionnées dans FAQ ne soient satisfaites en même temps ... .. Donc, disons que j'ai 100 nœuds avec 51% de demandes de CPU. Il ne sera toujours pas envisagé de réduction d'échelle.
Une solution consiste à augmenter de 50% la valeur de vérification effectuée par l'autorité de certification. Mais malheureusement, ce n'est pas supporté par GKE, voir la réponse du support Google @GalloCedrone:
De plus, je sais que cette valeur peut sembler trop basse et que quelqu'un pourrait être intéressé à en conserver également 85% ou 90% pour éviter votre scénario . Actuellement, une demande de fonctionnalité est ouverte pour donner à l'utilisateur la possibilité de modifier l'indicateur "--scale-down-use-seuil", mais il n'est pas encore implémenté.
La solution de contournement que j'ai trouvée consiste à réduire la demande de processeur (100 m au lieu de 300 m) des pods et à laisser le HPA (Horizontal Pod Autoscaler) en créer davantage à la demande. Cela me convient, mais si votre application ne convient pas à de nombreuses petites instances, vous n’avez pas de chance. Peut-être un travail cron qui connecte un nœud si l'utilisation totale est faible?
Je suis d'accord que selon Documentation il semble que "gke-name-cluster-default-pool" puisse être supprimé en toute sécurité, conditions:
- La somme des demandes de CPU et de mémoire de tous les pods exécutés sur ce nœud est inférieure à 50% de l'allocation du nœud.
- Tous les pods exécutés sur le nœud (à l'exception de ceux qui s'exécutent sur tous les nœuds par défaut, comme les pods à exécution de manifeste ou créés par des daemonsets) peuvent être déplacés vers d'autres noeuds.
- L'annotation désactivée n'est pas réduite Par conséquent, elle devrait être supprimée au bout de 10 minutes, ce qui est considéré comme inutile.
Cependant, en vérifiant la Documentation j'ai trouvé:
Quels types de pods peuvent empêcher l'autorité de certification de supprimer un nœud?
[...] Les pods du système Kube qui ne sont pas exécutés sur le noeud par défaut, * [..]
heapster-v1.5.2 --- est en cours d'exécution sur le nœud et il s'agit d'un module système Kube qui n'est pas exécuté sur le nœud par défaut.
Je mettrai à jour la réponse si je découvre des informations plus intéressantes.
METTRE À JOUR
Le fait que le nœud soit le dernier de la zone ne pose pas de problème.
Pour le prouver, j'ai testé sur un tout nouveau cluster avec 3 nœuds, chacun dans une zone différente. L'un d'entre eux était sans charge de travail autre que "kube-proxy" et "fluentd" et était correctement supprimé même s'il contenait la taille de la zone à zéro.