Meilleures pratiques Kubernetes. Configuration des demandes et des limites de ressources

Meilleures pratiques Kubernetes. Création de petits conteneurs
Meilleures pratiques Kubernetes. Organisation de Kubernetes avec des espaces de noms
Les développeurs de Xenoblade Chronicles: Definitive Edition dans le dernier numéro du magazine Weekly Famitsu.

Pour chaque ressource Kubernetes, il est possible de configurer deux types de demandes : Requests et Limits. La première décrit les exigences minimales en matière de ressources libres sur le nœud nécessaires pour exécuter un conteneur ou un pod, la seconde limite strictement les ressources accessibles au conteneur.

Lorsque Kubernetes planifie un pod, il est très important que les conteneurs disposent de ressources suffisantes pour fonctionner normalement. Si vous prévoyez de déployer une grande application sur un nœud avec des ressources limitées, il est tout à fait possible qu'elle ne fonctionne pas en raison d'un manque de mémoire ou de puissance processeur sur le nœud. Dans cet article, nous examinerons comment résoudre les problèmes de manque de puissance de calcul en utilisant des demandes de ressources et des limites.

Les demandes Requests et les limites Limits sont des mécanismes que Kubernetes utilise pour gérer des ressources telles que le processeur et la mémoire. Les Requests garantissent que le conteneur obtienne la ressource demandée. Si un conteneur demande une ressource, Kubernetes ne le planifiera que sur le nœud capable de la fournir. Les limites Limits contrôlent que les ressources demandées par le conteneur ne dépassent jamais une certaine valeur.

Un conteneur peut accroître ses capacités de calcul uniquement jusqu'à une certaine limite, après quoi il sera restreint. Voyons comment cela fonctionne. Il existe donc deux types de ressources : le processeur et la mémoire. Le planificateur Kubernetes utilise des données concernant ces ressources pour déterminer où exécuter vos pods. Une spécification typique des ressources pour un pod ressemble à ceci.

Chaque conteneur dans un pod peut définir ses propres demandes et limites, le tout de manière additive. Les ressources CPU sont spécifiées en milli-cores. Si votre conteneur nécessite deux cœurs complets pour fonctionner, vous définissez la valeur à 2000m. Si le conteneur a seulement besoin de la puissance d'un quart de cœur, la valeur sera de 250m. Gardez à l'esprit que si vous assignez une valeur de ressources CPU supérieure au nombre de cœurs du nœud le plus puissant, le lancement de votre pod ne sera pas planifié du tout. Une situation similaire se produira si vous avez un pod nécessitant quatre cœurs, alors que le cluster Kubernetes ne se compose que de deux machines virtuelles principales.

À moins que votre application ne soit spécifiquement conçue pour tirer parti de plusieurs cœurs (on pense à des programmes tels que des calculs scientifiques complexes et des opérations sur des bases de données), la meilleure pratique consiste à définir les demandes de CPU à 1 ou moins, suivie du lancement d'un plus grand nombre de répliques pour la scalabilité. Cette approche donnera au système plus de flexibilité et de fiabilité.

Quand il s'agit des limites de CPU, les choses deviennent plus intéressantes, car il est considéré comme une ressource compressible. Si votre application commence à atteindre la limite de puissance CPU, Kubernetes commencera à ralentir votre conteneur en utilisant le throttling CPU — une réduction de la fréquence du processeur. Cela signifie que le CPU sera artificiellement limité, offrant potentiellement à l'application de moins bonnes performances, mais le processus ne sera pas arrêté ou expulsé.

Les ressources mémoire sont définies en octets. En général, la valeur dans les paramètres est mesurée en mébibytes (MiB), mais vous pouvez définir n'importe quelle valeur, des octets aux pétaoctets. Ici, la même situation se produit qu'avec le CPU — si vous demandez une quantité de mémoire dépassant la mémoire disponible sur vos nœuds, l'exécution de ce pod ne sera pas planifiée. Toutefois, contrairement aux ressources CPU, la mémoire n'est pas compressible, car il n'y a aucun moyen de limiter son utilisation. Ainsi, l'exécution du conteneur sera arrêtée dès qu'il dépassera la mémoire qui lui a été allouée.

Il est important de se rappeler que vous ne pouvez pas configurer des demandes qui dépassent la taille des ressources que vos nœuds peuvent fournir. Les caractéristiques des ressources partagées pour les machines virtuelles GKE peuvent être trouvées dans les liens placés sous cette vidéo.

Dans un monde idéal, les configurations de conteneurs par défaut seraient largement suffisantes pour que les flux de travail se déroulent sans accroc. Mais le monde réel n'est pas tel, les gens peuvent facilement oublier de configurer l'utilisation des ressources ou des hackers peuvent définir des demandes et des limites qui dépassent les capacités réelles de l'infrastructure. Pour éviter de telles scénarios, il est possible de configurer des quotas de ressources ResourceQuota et des plages de limites LimitRange.

Après la création des espaces de noms, ils peuvent être bloqués à l'aide de quotas. Par exemple, si vous avez des espaces de noms prod et dev, vous pouvez utiliser un modèle où les quotas de production sont totalement absents alors que les quotas de développement sont très stricts. Cela permet à prod, en cas de pic de trafic soudain, de prendre toutes les ressources disponibles, bloquant complètement dev.

Un quota de ressources pourrait ressembler à ceci. Dans cet exemple, il y a 4 sections – c'est 4 lignes de code inférieures.

Examinons chacun d'eux. Requests.cpu représente le nombre maximal combiné de demandes de puissance processeur qui peuvent provenir de tous les conteneurs d'un espace de noms. Dans cet exemple, vous pouvez avoir 50 conteneurs avec des demandes de 10m, cinq conteneurs avec des demandes de 100m, ou simplement un conteneur avec une demande de 500m. Tant que le nombre total de requests.cpu de cet espace de noms reste inférieur à 500m, tout ira bien.

La mémoire demandée requests.memory représente la taille maximale combinée des demandes de mémoire que peuvent avoir tous les conteneurs dans un espace de noms. Comme dans le cas précédent, vous pouvez avoir 50 conteneurs de 2 MiB, cinq conteneurs de 20 MiB ou un seul conteneur de 100 MiB, tant que le nombre total de mémoire demandée dans l'espace de noms reste inférieur à 100 mebibytes.

Limits.cpu est la valeur maximale combinée de la puissance processeur que peuvent utiliser tous les conteneurs d'un espace de noms. On peut considérer cela comme la limite des demandes de puissance processeur.

Enfin, limits.memory correspond à la quantité maximale de mémoire générale pouvant être utilisée par tous les conteneurs dans un espace de noms. Ce seuil concerne les demandes de mémoire globales.
Ainsi, par défaut, les conteneurs d'un cluster Kubernetes fonctionnent avec des ressources de calcul illimitées. Grâce aux quotas de ressources, les administrateurs de cluster peuvent limiter la consommation et la création de ressources sur la base de l'espace de noms. Dans cet espace de noms, un pod ou conteneur peut consommer autant de puissance CPU et de mémoire que défini par le quota de ressources. Cependant, il existe des préoccupations quant à la possibilité qu'un seul pod ou conteneur monopolise toutes les ressources disponibles. Pour éviter cela, il est utilisé un seuil de plage de limitation – une politique d'allocation des ressources (pour les pods ou conteneurs) dans l'espace de noms.

La plage de limites fournit des contraintes qui peuvent :

• assurer une utilisation minimale et maximale des ressources de calcul pour chaque pod ou conteneur dans l'espace de noms;
• forcer l'utilisation minimale et maximale de l'espace de stockage Storage Request pour chaque PersistentVolumeClaim dans l'espace de noms;
• obliger à établir un rapport entre la demande Request et la limite Limit pour une ressource dans l'espace de noms;
• définir des Requests/Limits par défaut pour les ressources de calcul dans l'espace de noms et les appliquer automatiquement aux conteneurs lors de l'exécution.

Ainsi, vous pouvez créer une plage de limites dans votre espace de noms. Contrairement aux quotas, qui s'appliquent à l'ensemble de l'espace de noms, la plage de limites est utilisée pour des conteneurs individuels. Cela peut empêcher les utilisateurs de créer des conteneurs très petits ou, à l'inverse, géants dans l'espace de noms. La plage de limites Limit Range peut ressembler à ceci.

Comme dans le cas précédent, ici, nous pouvons distinguer 4 sections. Examinons chacune d'elles.
Dans la section default, des limites par défaut sont définies pour les conteneurs dans le pod. Si vous définissez ces valeurs dans la plage de limites, tous les conteneurs pour lesquels ces valeurs n'ont pas été explicitement définies seront régis par les valeurs par défaut.

La section de la requête par défaut defaultRequest configure les requêtes par défaut pour les conteneurs dans le pod. Encore une fois, si vous définissez ces valeurs dans la plage limite, tous les conteneurs pour lesquels ces paramètres ne sont pas explicitement définis utiliseront par défaut ces valeurs.

La section max indique les limites maximales qui peuvent être définies pour les conteneurs dans le pod. Les valeurs dans la section default et les limites pour le conteneur ne peuvent pas être fixées au-dessus de cette limite. Il est important de noter que si une valeur max est définie et que la section default est absente, la valeur maximale devient la valeur par défaut.

La section min indique les demandes minimales qui peuvent être définies pour les conteneurs dans le pod. En même temps, les valeurs dans la section default et les demandes pour le conteneur ne peuvent pas être définies en dessous de cette limite.

Encore une fois, il est important de noter que si cette valeur est définie, et que la valeur default n’est pas, la valeur minimale devient la demande par défaut.

En fin de compte, ces demandes de ressources sont utilisées par le planificateur Kubernetes pour exécuter vos charges de travail. Afin que vous puissiez configurer correctement vos conteneurs, il est très important de comprendre comment cela fonctionne. Supposons que vous souhaitiez exécuter plusieurs modules dans votre cluster. En supposant que les spécifications du pod sont valides, l'ordonnancement de Kubernetes utilisera un équilibre cyclique pour choisir le nœud sur lequel exécuter la charge de travail.

Kubernetes vérifiera si Node 1 dispose de suffisamment de ressources pour satisfaire les demandes des conteneurs du pod, et si ce n'est pas le cas, il passera au nœud suivant. Si aucun des nœuds du système n'est capable de répondre aux demandes, les pods passeront à l'état d'attente Pending state. Grâce à des fonctions telles que l'autoscaling des nœuds dans Google Kubernetes Engine, GKE peut automatiquement détecter l'état d'attente et créer quelques nœuds supplémentaires.

Si par la suite il y a une capacité excédentaire des nœuds, la fonction d'autoscaling réduira leur nombre pour vous faire économiser de l'argent. Voilà pourquoi Kubernetes planifie les pods en fonction des demandes. Cependant, la limite peut être supérieure aux demandes, et dans certains cas, un nœud peut effectivement épuiser ses ressources. Nous appelons cela un état de sur-engagement overcommitment state.

Comme je l'ai déjà dit, en ce qui concerne le processeur, Kubernetes commencera à limiter les pods. Chaque pod recevra autant qu'il a demandé, mais s'il n'atteint pas la limite, le throttling sera appliqué.

En ce qui concerne les ressources mémoire, Kubernetes doit prendre des décisions sur les pods à supprimer et ceux à conserver, tant que vous ne libérez pas de ressources système, sinon tout le système s'effondrera.

Imaginons un scénario où vous avez une machine qui a atteint sa limite de mémoire – que fera Kubernetes dans ce cas ?

Kubernetes recherche les pods qui utilisent plus de ressources qu'ils n'en ont demandé. Ainsi, si vos conteneurs n'ont aucune demande, cela signifie qu'ils utilisent par défaut plus que ce qu'ils ont demandé, simplement parce qu'ils n'ont rien demandé du tout ! Ces conteneurs deviennent de principaux candidats à l'arrêt. Les suivants sont les conteneurs qui ont satisfait toutes leurs demandes mais qui sont toujours en dessous de la limite maximale.

Donc, si Kubernetes trouve plusieurs pods qui ont dépassé les paramètres de leurs demandes, il les triera par priorité, puis supprimera les modules de priorité la plus basse. Si tous les modules ont la même priorité, Kubernetes arrêtera ceux des pods qui ont dépassé leurs demandes plus que les autres pods.

Dans de très rares cas, Kubernetes peut interrompre les pods qui restent dans les limites de leurs demandes. Cela peut se produire lorsque des composants critiques du système, tels que l'agent Kubelet ou Docker, commencent à consommer plus de ressources que ce qui a été réservé pour eux.
Ainsi, à un stade précoce des petites entreprises, un cluster Kubernetes peut très bien fonctionner sans définir de demandes de ressources et de limites, mais à mesure que vos équipes et projets commencent à grandir, vous risquez de rencontrer des problèmes dans ce domaine. Ajouter des demandes et des limites à vos modules et espaces de noms nécessite très peu d'efforts supplémentaires et peut vous éviter de nombreux tracas.

Meilleures pratiques Kubernetes. Arrêt correct Terminate

Un peu de publicité 🙂

Merci de rester avec nous. Aimez-vous nos articles ? Voulez-vous voir plus de contenu intéressant ? Soutenez-nous en passants une commande ou en nous recommandant à des amis, VPS cloud pour développeurs à partir de 4,99 $, un équivalent unique des serveurs d'entrée de gamme, conçu pour vous : Toute la vérité sur le VPS (KVM) E5-2697 v3 (6 cœurs) 10 Go DDR4 480 Go SSD 1 Gbps à partir de 19 $ ou comment bien diviser un serveur ? (options disponibles avec RAID1 et RAID10, jusqu'à 24 cœurs et jusqu'à 40 Go DDR4).

Dell R730xd deux fois moins cher dans le data center Equinix Tier IV à Amsterdam ? Uniquement chez nous 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64Go DDR4 4x960Go SSD 1Gbps 100 To à partir de 199 $ aux Pays-Bas ! Dell R420 — 2x E5-2430 2.2GHz 6C 128Go DDR3 2x960Go SSD 1Gbps 100To — à partir de 99 $ ! Lisez sur Comment construire une infrastructure de classe entreprise avec des serveurs Dell R730xd E5-2650 v4 coûtant 9000 euros pour des clopinettes ?

Source : habr.com