Profilage des ressources

Les tests de ressources visaient à traiter les énoncés de problème suivants :

Les composants testés sont :

Ce sont des chiffres de référence pour un système stable utilisant uniquement des composants empaquetés K3s (Traefik Ingress, Klipper lb, stockage local) exécutant une pile de surveillance standard (Prometheus et Grafana) et l’application exemple Guestbook.

Les chiffres de ressources, y compris les IOPS, concernent uniquement la base de données Kubernetes et le plan de contrôle, et n’incluent pas les frais généraux pour les agents de gestion au niveau système ou la journalisation, la gestion des images de conteneurs, ou toute exigence spécifique à la charge de travail.

Une instance autonome de Prometheus v2.43.0 a été utilisée pour collecter des statistiques sur l’UC, la mémoire et les E/S de disque de l’hôte en utilisant prometheus-node-exporter installé via apt.

systemd-cgtop a été utilisé pour vérifier l’utilisation de l’UC et de la mémoire au niveau des cgroups systemd. system.slice/k3s.service suit l’utilisation des ressources pour K3s et containerd, tandis que les pods individuels sont sous la hiérarchie kubepods.

Des données supplémentaires détaillées sur l’utilisation de la mémoire K3s ont été collectées à partir de kubectl top node en utilisant le serveur de métriques intégré pour les processus serveur et agent.

Les chiffres d’utilisation étaient basés sur des lectures du 95e percentile provenant d’un fonctionnement en état stable sur des nœuds exécutant les charges de travail décrites.

Cette section présente les résultats des tests pour déterminer les exigences minimales en ressources pour le fonctionnement de base de K3s.

Les chiffres d’utilisation du serveur K3s sont principalement déterminés par le support du datastore Kubernetes (kine ou etcd), du serveur API, du contrôleur de gestion et des boucles de contrôle du planificateur, ainsi que par toutes les tâches de gestion nécessaires pour effectuer des changements dans l’état du système. Les opérations qui augmentent la charge sur le plan de contrôle Kubernetes, telles que la création/modification/suppression de ressources, provoqueront des pics temporaires d’utilisation. L’utilisation d’opérateurs ou d’applications qui font un usage intensif du datastore Kubernetes (comme Rancher ou d’autres applications de type opérateur) augmentera les exigences en ressources du serveur. L’augmentation de la taille du cluster en ajoutant des nœuds supplémentaires ou en créant de nombreuses ressources de cluster augmentera les exigences en ressources du serveur.

Les chiffres d’utilisation de l’agent K3s sont principalement déterminés par le support des boucles de contrôle de gestion du cycle de vie des conteneurs. Les opérations impliquant la gestion des images, la fourniture de stockage ou la création/destruction de conteneurs entraîneront des pics temporaires d’utilisation. Les téléchargements d’images, en particulier, sont généralement très dépendants de l’UC et des E/S, car ils impliquent la décompression du contenu des images sur le disque. Si possible, le stockage de charge de travail (stockage éphémère des pods et volumes) doit être isolé des composants de l’agent (/var/lib/rancher/k3s/agent) afin de garantir qu’il n’y a pas de conflits de ressources.

Lors de l’exécution dans un environnement où le serveur héberge également des pods de charge de travail, il convient de veiller à ce que les IOPS de l’agent et de la charge de travail n’interfèrent pas avec le magasin de données.

Cela peut être réalisé de la meilleure manière en plaçant les composants du serveur (/var/lib/rancher/k3s/server) sur un support de stockage différent de celui des composants de l’agent (/var/lib/rancher/k3s/agent), qui incluent le magasin d’images containerd.

Le stockage de charge de travail (stockage éphémère des pods et volumes) doit également être isolé du magasin de données.

Le non-respect des exigences de débit et de latence du magasin de données peut entraîner un retard de réponse du plan de contrôle et/ou un échec du plan de contrôle à maintenir l’état du système.

Ces données ont été récupérées dans des conditions de test spécifiques. Cela variera en fonction de l’environnement et des charges de travail. Les étapes ci-dessous donnent un aperçu du test qui a été réalisé pour récupérer cela. Il a été effectué pour la dernière fois sur v1.31.0+k3s1. Toutes les machines ont été provisionnées dans AWS avec des volumes gp3 standard de 20 GiB. Le test a été réalisé avec les étapes suivantes :