💼 🕺🏽 😕 Meilleures pratiques Kubernetes. Définition de requêtes et de limites de ressources 🐓 🏢 🦄

Meilleures pratiques Kubernetes. Création de petits conteneurs
Kubernetes Best Practices. Organisation Kubernetes avec l'
espace de noms Kubernetes Best Practices. Vérification de la viabilité de Kubernetes à l'aide des tests de disponibilité et de validité

Pour chaque ressource Kubernetes, vous pouvez configurer deux types d'exigences - Demandes et limites. Le premier décrit les exigences minimales pour la disponibilité des ressources de nœuds libres nécessaires pour exécuter un conteneur ou un foyer, le second limite strictement les ressources disponibles pour le conteneur.

Lorsque Kubernetes prévoit un pod, il est très important que les conteneurs disposent de suffisamment de ressources pour un fonctionnement normal. Si vous prévoyez de déployer une grande application sur un nœud avec des ressources limitées, il est fort possible que cela ne fonctionne pas car le nœud manque de mémoire ou manque de puissance processeur. Dans cet article, nous verrons comment vous pouvez résoudre les problèmes de manque de capacité informatique à l'aide de demandes de ressources et de restrictions.

Les demandes et les limites sont des mécanismes que Kubernetes utilise pour gérer des ressources telles que le processeur et la mémoire. Les demandes sont le résultat duquel le conteneur est garanti de recevoir la ressource demandée. Si un conteneur demande une ressource, Kubernetes la planifie uniquement sur l'hôte qui peut la fournir. Limits limite le contrôle que les ressources demandées par le conteneur ne dépasseront jamais une certaine valeur.

Un conteneur ne peut augmenter la puissance de calcul que dans une certaine limite, après quoi il sera limité. Voyons voir comment ça fonctionne. Il existe donc deux types de ressources - processeur et mémoire. Le planificateur Kubernetes utilise les données de ces ressources pour déterminer où exécuter vos pods. Une spécification de ressource de foyer typique ressemble à ceci.

Chaque conteneur dans le pod peut définir ses propres requêtes et restrictions, qui sont toutes additives. Les ressources du processeur sont définies en millimètres. Si votre conteneur de lancement a besoin de deux cœurs complets, vous définissez la valeur sur 2000 m. Si le conteneur n'a besoin que de 1/4 du noyau, la valeur est de 250 m. Gardez à l'esprit que si vous attribuez une valeur de ressource processeur supérieure au nombre de cœurs du plus grand nœud, le lancement de votre foyer ne sera pas du tout prévu. Une situation similaire se produira si vous avez un sous-système qui a besoin de quatre cœurs et que le cluster Kubernetes ne comprend que deux machines virtuelles principales.

Sauf si votre application est spécifiquement conçue pour tirer parti de plusieurs cœurs (avec des programmes tels que le calcul scientifique complexe et les opérations de base de données qui vous viennent à l'esprit), il est préférable de définir les demandes de processeur à 1 ou moins, puis d'exécuter plus de répliques pour évolutivité. Une telle solution donnera au système une plus grande flexibilité et fiabilité.

En ce qui concerne les limitations du processeur, les choses deviennent plus intéressantes car elles sont considérées comme une ressource compressible. Si votre application commence à approcher la limite de capacité du processeur, Kubernetes commencera à ralentir votre conteneur à l'aide de la limitation du processeur, ce qui réduira la fréquence du processeur. Cela signifie que le processeur sera artificiellement limité, offrant à l'application des performances potentiellement moins bonnes, mais le processus ne sera pas interrompu ni transmis.

Les ressources mémoire sont définies en octets. Habituellement, la valeur dans les paramètres est mesurée en mégaoctets Mib, mais vous pouvez spécifier n'importe quelle valeur, des octets aux pétaoctets. Ici, la situation est la même qu'avec le CPU - si vous placez une demande pour une quantité de mémoire dépassant la quantité de mémoire sur vos nœuds, l'exécution de ce pod ne sera pas planifiée. Mais contrairement aux ressources processeur, la mémoire n'est pas compressée, car il n'y a aucun moyen de limiter son utilisation. Par conséquent, l'exécution du conteneur sera arrêtée dès qu'il dépassera les limites de la mémoire qui lui est 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 sites peuvent fournir. Les caractéristiques des ressources partagées pour les machines virtuelles GKE se trouvent sur les liens situés sous cette vidéo.

Dans un monde idéal, les paramètres de conteneur par défaut suffiront pour que les flux de travail se déroulent sans problème. Mais le monde réel n'est pas comme ça, les gens peuvent facilement oublier de configurer l'utilisation des ressources ou les pirates établiront des demandes et des restrictions qui dépasseront les capacités réelles de l'infrastructure. Pour empêcher ces scénarios de se développer, vous pouvez configurer les quotas de ressources ResourceQuota et les plages de restriction LimitRange.

Après avoir créé un espace de noms, vous pouvez les bloquer avec des quotas. Par exemple, si vous avez des espaces de noms prod et dev, un modèle est utilisé dans lequel il n'y a aucun quota de production et les quotas de développement sont très stricts. Cela permet à prod en cas de forte augmentation du trafic de prendre toutes les ressources disponibles pour lui-même, bloquant complètement le développement.

Un quota de ressources peut ressembler à ceci. Dans cet exemple, il y a 4 sections - ce sont les 4 dernières lignes de code.

Regardons chacun d'eux. Requests.cpu est le nombre maximal de demandes d'alimentation de processeur combinées pouvant provenir de tous les conteneurs d'espace de noms. Dans cet exemple, vous pouvez avoir 50 conteneurs avec des demandes de 10 m chacun, cinq conteneurs avec des demandes de 100 m ou juste un conteneur avec une demande de 500 m. Tant que le nombre total de requêtes.cpu de cet espace de noms est inférieur à 500 m, tout ira bien.

Mémoire demandée request.memory est la quantité maximale de demandes de mémoire combinées que tous les conteneurs de l'espace de noms peuvent avoir. Comme dans le cas précédent, vous pouvez avoir 50 conteneurs de 2 Mo chacun, cinq conteneurs de 20 Mo chacun ou un seul conteneur de 100 Mo jusqu'à ce que la quantité totale de mémoire demandée dans l'espace de noms soit inférieure à 100 mégaoctets.

Limits.cpu est la valeur de puissance combinée maximale du processeur que tous les conteneurs d'espace de noms peuvent utiliser. Nous pouvons supposer que c'est la limite des demandes d'alimentation du processeur.

Enfin, limits.memory est la quantité maximale de mémoire partagée que tous les conteneurs de l'espace de noms peuvent utiliser. Il s'agit d'une limitation du nombre total de demandes de mémoire.
Ainsi, par défaut, les conteneurs d'un cluster Kubernetes fonctionnent avec des ressources informatiques illimitées. À l'aide de quotas de ressources, les administrateurs de cluster peuvent limiter la consommation de ressources et leur création en fonction de l'espace de noms. Dans l'espace de noms, le module de pod ou le conteneur peut consommer autant de CPU et de mémoire que le quota de ressources d'espace de noms détermine. Cependant, on craint qu'un sous-conteneur ou un conteneur ne monopolise toutes les ressources disponibles. Pour éviter cette situation, la plage limite Plage Plage est utilisée - la politique de restriction de la distribution des ressources (pour les pods ou les conteneurs) dans l'espace de noms.

La plage de limites fournit des limitations qui peuvent:

;
Starage Request PersistentVolumeClaim ;
Request Limit ;
Requests/Limits .

De cette façon, vous pouvez créer une plage limite dans votre espace de noms. Contrairement au quota qui s'applique à l'ensemble de l'espace de noms, la plage de limites est utilisée pour les conteneurs individuels. Cela peut empêcher les utilisateurs de créer de très petits conteneurs, ou vice versa, à l'intérieur de l'espace de noms. La plage limite peut ressembler à ceci.

Comme dans le cas précédent, 4 sections peuvent être distinguées ici. Jetons un coup d'œil à chacun.
Dans la section par défaut, les restrictions par défaut sont définies pour le conteneur dans l'âtre. Si vous spécifiez ces valeurs dans la plage limite, tous les conteneurs pour lesquels ces valeurs n'ont pas été définies explicitement seront guidés par les valeurs par défaut.

Dans la section de requête par défaut, defaultRequest, les requêtes par défaut pour le conteneur dans l'âtre sont configurées. 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 ces valeurs par défaut.

La section max indique les restrictions maximales pouvant être définies pour le conteneur dans l'âtre. Les valeurs de la section par défaut et les restrictions pour le conteneur ne peuvent pas être définies au-dessus de cette limite. Il est important de noter que si max est défini et que la section par défaut est absente, la valeur maximale devient la valeur par défaut.

La section min indique les requêtes minimales qui peuvent être définies pour le conteneur dans l'âtre. Dans le même temps, les valeurs de la section par défaut 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, la valeur par défaut ne l'est pas, alors la valeur minimale devient la requête par défaut.

Par conséquent, ces demandes de ressources sont utilisées par le planificateur Kubernetes pour exécuter vos charges de travail. Pour 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 de l'âtre sont valides, le programme Kubernetes utilisera l'équilibrage cyclique pour sélectionner le nœud pour la charge de travail.

Kubernetes vérifiera si le nœud Node 1 a suffisamment de ressources pour répondre aux demandes de conteneur de 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 en mesure de satisfaire les demandes, les pods passeront à l'état En attente. Avec les fonctionnalités du moteur Google Kubernetes telles que la mise à l'échelle automatique des nœuds, GKE peut déterminer automatiquement l'état d'attente et créer d'autres nœuds supplémentaires.

Si par la suite il y a une capacité excédentaire de nœuds, la fonction de mise à l'échelle automatique réduira leur nombre afin de vous faire économiser de l'argent. C'est pourquoi Kubernetes prévoit des pods basés sur des requêtes. Cependant, la limite peut être supérieure aux demandes et, dans certains cas, le nœud peut en fait manquer de ressources. Nous appelons cet état un état de surengagement.

Comme je l'ai dit, si nous parlons d'un processeur, Kubernetes commencera à limiter les pods. Chaque pod recevra autant qu'il a demandé, mais si en même temps il n'atteint pas la limite, alors la limitation commencera à s'appliquer.

En ce qui concerne les ressources de mémoire, ici Kubernetes est obligé de prendre des décisions sur les pods à supprimer et ceux à conserver jusqu'à ce que vous libériez les ressources système, sinon le système entier plantera.

Imaginons un scénario dans lequel vous avez une machine qui n'a plus de mémoire - comment Kubernetes fera-t-il cela?

Kubernetes recherchera des pods qui utilisent plus de ressources que demandé. Donc, si vos conteneurs n'ont pas du tout de requêtes, cela signifie que par défaut, ils utilisent plus que ce qu'ils ont demandé, simplement parce qu'ils n'ont rien demandé du tout! Ces conteneurs deviennent les principaux candidats à l'arrêt. Les prochains candidats sont des conteneurs qui ont satisfait toutes leurs demandes, mais qui restent en dessous de la limite maximale.

Donc, si Kubernetes trouve plusieurs pods qui ont dépassé les paramètres de leurs requêtes, 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 les pods qui dépassent leurs demandes plus que le reste des pods.

Dans de très rares cas, Kubernetes peut interrompre les foyers qui sont toujours à sa portée. Cela peut se produire lorsque des composants système critiques tels que l'agent Kubelet ou Docker commencent à consommer plus de ressources que ce qui leur était réservé.
Ainsi, aux premiers stades des petites entreprises, le cluster Kubernetes peut fonctionner correctement sans définir de demandes de ressources et de restrictions, mais au fur et à mesure que vos équipes et vos projets commencent à se développer, vous courez le risque de rencontrer des problèmes dans ce domaine. L'ajout de requêtes et de restrictions à vos modules et espaces de noms nécessite très peu d'efforts supplémentaires et peut vous éviter beaucoup de tracas.

Meilleures pratiques Kubernetes. Correct Terminate Disable

Un peu de publicité :)

Merci de rester avec nous. Aimez-vous nos articles? Vous voulez voir des matériaux plus intéressants? Soutenez-nous en passant une commande ou en recommandant à vos amis des VPS basés sur le cloud pour les développeurs à partir de 4,99 $ , un analogue unique de serveurs d'entrée de gamme que nous avons inventés pour vous: Toute la vérité sur les VPS (KVM) E5-2697 v3 (6 cœurs) 10 Go DDR4 480 Go SSD 1 Gbit / s à partir de 19 $ ou comment diviser le serveur? (les options sont disponibles avec RAID1 et RAID10, jusqu'à 24 cœurs et jusqu'à 40 Go de DDR4).

Dell R730xd 2 fois moins cher au centre de données Equinix Tier IV à Amsterdam? Nous avons seulement 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV à partir de 199 $ aux Pays-Bas!Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - à partir de 99 $! En savoir plus sur la création d'un bâtiment d'infrastructure. classe c utilisant des serveurs Dell R730xd E5-2650 v4 coûtant 9 000 euros pour un sou?

Meilleures pratiques Kubernetes. Définition de requêtes et de limites de ressources

Un peu de publicité :)

More articles: