Comment définir les limites de ressources du pod Kubernetes –
La définition de limites de ressources sur vos pods Kubernetes empêche un conteneur errant d’avoir un impact sur d’autres charges de travail. Kubernetes vous permet de limiter les ressources, y compris la consommation de processeur et de mémoire. Les pods peuvent être arrêtés lorsque leurs limites sont dépassées, ce qui maintient la stabilité globale du cluster.
Sommaire
Unités de ressources
Avant de définir des limites, il convient de noter comment Kubernetes exprime la disponibilité des ressources.
La consommation de processeur est mesurée en termes de processeurs virtuels utilisés. Une limite de 0.5 Les processeurs virtuels indiquent que le pod peut consommer la moitié du temps disponible de l’un des processeurs virtuels disponibles. Un processeur virtuel est ce que vous verrez annoncé sur les pages d’hébergement des fournisseurs de cloud. Lorsque vous utilisez du matériel nu, il s’agit d’un hyperthread sur votre processeur.
La mémoire est mesurée en octets. Vous pouvez le spécifier sous la forme d’un nombre entier d’octets ou d’une quantité plus conviviale, telle que 512Mi ou 1Gi.
Création d’une limite de processeur
Pour ajouter une limite de processeur aux conteneurs de pod, incluez le resources:limits champ dans le manifeste de votre conteneur:
apiVersion: v1 kind: Pod metadata: name: demo namespace: demo spec: containers: - name: my-container image: example/example resources: limits: cpu: "0.5"
L’exemple ci-dessus limitera vos conteneurs à 0,5 vCPU. Ils seront limités afin qu’ils ne puissent pas consommer plus de la moitié du temps processeur disponible sur une période de 100 ms.
Création d’une limite de mémoire
Les limites de mémoire sont créées de la même manière. Changer la limits:cpu champ dans le manifeste pour limits:memory:
Le conteneur sera limité à 512Mi de RAM. Kubernetes lui permettra toujours d’accéder à plus si le nœud sur lequel il est planifié a une capacité excédentaire. Sinon, le dépassement de la limite entraînera le marquage du conteneur comme candidat à la résiliation.
Limites de stockage
Tous les nœuds Kubernetes disposent d’une quantité de stockage éphémère disponible. Ce stockage est utilisé par les pods pour stocker les caches et les journaux. Le pool de stockage éphémère est également l’endroit où le cluster Kubernetes conserve les images de conteneur.
Vous pouvez définir des limites pour l’utilisation du stockage éphémère d’un pod. Il s’agit d’une fonctionnalité bêta destinée à garantir que le cache d’un seul pod ne peut pas consommer l’intégralité du pool de stockage. Utilisez le limits:ephemeral-storage champ manifeste du conteneur:
limits: ephemeral-storage: "1Gi"
Ce conteneur serait désormais limité à l’utilisation de 1Gi du stockage éphémère disponible. Les pods qui essaient d’utiliser plus de stockage seront expulsés. Lorsqu’il y a plusieurs conteneurs dans un pod, le pod est expulsé si la somme de l’utilisation du stockage de tous les conteneurs dépasse la limite de stockage globale.
Kubernetes suit généralement l’utilisation du stockage en analysant périodiquement le système de fichiers de stockage éphémère du nœud. Il additionnera ensuite l’utilisation de stockage de chaque pod et conteneur. Il existe une prise en charge facultative des quotas de stockage du système de fichiers au niveau du système d’exploitation, ce qui permet une surveillance plus précise.
Vous aurez besoin d’un système de fichiers pris en charge par les quotas de projet, tel que XFS ou ext4. Assurez-vous que le système de fichiers est monté avec le suivi des quotas de projet activé, puis activez le LocalStorageCapacityIsolationFSQuotaMonitoring indicateur de fonctionnalité dans kubelet. Des conseils sur la configuration de ce système sont fournis dans la documentation de Kubernetes.
Demandes de ressources
En plus des limites de ressources, vous pouvez définir des ressources demandes. Ceux-ci sont disponibles pour le processeur, la mémoire et le stockage éphémère. limits champ à requests dans chacun des exemples présentés ci-dessus.
La définition d’une demande de ressource indique la quantité de cette ressource que vous prévoyez que le conteneur utilisera. Kubernetes prend ces informations en compte lors de la détermination du nœud sur lequel planifier le pod.
En utilisant la mémoire comme exemple, un request de 512Mi entraînera la planification du pod sur un nœud avec au moins 512 Mo de mémoire disponible. La disponibilité est calculée en additionnant les demandes de mémoire de tous les pods existants sur le nœud et en soustrayant cela de la capacité mémoire totale du nœud.
Un nœud ne pourra pas héberger un nouveau conteneur si la somme des demandes de charge de travail, y compris la demande du nouveau conteneur, dépasse la capacité disponible. Cela reste le cas même si l’utilisation de la mémoire en temps réel est en réalité très faible. La capacité disponible a déjà été allouée aux conteneurs existants pour s’assurer que leurs demandes peuvent être satisfaites.
Contrairement à une limite, Kubernetes autorise toujours les conteneurs à dépasser leur demande de ressources. Ils peuvent consommer toutes les quantités de ressources inutilisées que d’autres conteneurs ont demandées mais n’utilisent pas actuellement.
Utilisation des requêtes et des limites
Les comportements différents des demandes et des limites signifient que vous devez examiner attentivement les valeurs que vous utilisez. Il est généralement préférable de limiter les demandes. Vous définissez ensuite les limites aussi élevées que possible sans affecter la capacité de coexistence de vos charges de travail.
L’utilisation d’une valeur de demande de ressource faible donne à vos pods les meilleures chances d’être planifiés sur un nœud. Le planificateur a plus de flexibilité lors de la prise de décisions d’allocation, car il est plus probable qu’un nœud donné puisse héberger le conteneur. Le conteneur recevra un accès rapide à toutes les ressources excédentaires dont il a besoin, au-delà de la demande, jusqu’à la limite spécifiée.
Chaque demande et limite doit être équilibrée afin d’obtenir le plus grand effet. Vous devez examiner les demandes et les limites des autres pods exécutés dans votre cluster. Assurez-vous de connaître les quantités totales de ressources fournies par vos nœuds afin de ne pas définir de limites trop élevées (risque de stabilité) ou trop faibles (perte de capacité).
Conclusion
Vous devez toujours définir des limites de ressources pour vos charges de travail Kubernetes. L’utilisation efficace des limites permet aux charges de travail de coexister de manière pacifique sans mettre en danger la santé de votre cluster.
Ceci est particulièrement important dans le cas de la mémoire. Sans limites, un conteneur avec un processus errant peut rapidement consommer toute la mémoire offerte par son nœud. Un tel scénario de manque de mémoire pourrait supprimer d’autres pods programmés sur ce nœud, car le gestionnaire de mémoire au niveau du système d’exploitation commencerait à tuer les processus pour réduire l’utilisation de la mémoire.
La définition d’une limite de mémoire permet à Kubernetes de mettre fin au conteneur avant qu’il ne commence à avoir un impact sur d’autres charges de travail du cluster, sans parler des processus externes. Vous perdez votre charge de travail, mais le cluster global gagne en stabilité.
