{"id":82920,"date":"2020-05-26T13:42:37","date_gmt":"2020-05-26T11:42:37","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/luchshie-praktiki-kubernetes-nastrojka-zaprosov-i-limitov-resursov"},"modified":"2020-05-26T13:42:37","modified_gmt":"2020-05-26T11:42:37","slug":"luchshie-praktiki-kubernetes-nastrojka-zaprosov-i-limitov-resursov","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/luchshie-praktiki-kubernetes-nastrojka-zaprosov-i-limitov-resursov","title":{"rendered":"Meilleures pratiques Kubernetes. Configuration des demandes et des limites de ressources","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Meilleures pratiques Kubernetes. Cr\u00e9ation de petits conteneurs<\/a><\/noindex>
\nMeilleures pratiques Kubernetes. Organisation de Kubernetes avec des espaces de noms<\/a><\/noindex>
\nLes d\u00e9veloppeurs de Xenoblade Chronicles: Definitive Edition dans le dernier num\u00e9ro du magazine Weekly Famitsu.<\/a><\/noindex><\/p>\n

Pour chaque ressource Kubernetes, il est possible de configurer deux types de demandes : Requests et Limits. La premi\u00e8re d\u00e9crit les exigences minimales en mati\u00e8re de ressources libres sur le n\u0153ud n\u00e9cessaires pour ex\u00e9cuter un conteneur ou un pod, la seconde limite strictement les ressources accessibles au conteneur. <\/p>\n

Lorsque Kubernetes planifie un pod, il est tr\u00e8s important que les conteneurs disposent de ressources suffisantes pour fonctionner normalement. Si vous pr\u00e9voyez de d\u00e9ployer une grande application sur un n\u0153ud avec des ressources limit\u00e9es, il est tout \u00e0 fait possible qu'elle ne fonctionne pas en raison d'un manque de m\u00e9moire ou de puissance processeur sur le n\u0153ud. Dans cet article, nous examinerons comment r\u00e9soudre les probl\u00e8mes de manque de puissance de calcul en utilisant des demandes de ressources et des limites.<\/p>\n

Les demandes Requests et les limites Limits sont des m\u00e9canismes que Kubernetes utilise pour g\u00e9rer des ressources telles que le processeur et la m\u00e9moire. Les Requests garantissent que le conteneur obtienne la ressource demand\u00e9e. Si un conteneur demande une ressource, Kubernetes ne le planifiera que sur le n\u0153ud capable de la fournir. Les limites Limits contr\u00f4lent que les ressources demand\u00e9es par le conteneur ne d\u00e9passent jamais une certaine valeur.<\/p>\n

\"Meilleures<\/a><\/noindex><\/p>\n

Un conteneur peut accro\u00eetre ses capacit\u00e9s de calcul uniquement jusqu'\u00e0 une certaine limite, apr\u00e8s quoi il sera restreint. Voyons comment cela fonctionne. Il existe donc deux types de ressources : le processeur et la m\u00e9moire. Le planificateur Kubernetes utilise des donn\u00e9es concernant ces ressources pour d\u00e9terminer o\u00f9 ex\u00e9cuter vos pods. Une sp\u00e9cification typique des ressources pour un pod ressemble \u00e0 ceci.<\/p>\n

\"Meilleures
\n
\nChaque conteneur dans un pod peut d\u00e9finir ses propres demandes et limites, le tout de mani\u00e8re additive. Les ressources CPU sont sp\u00e9cifi\u00e9es en milli-cores. Si votre conteneur n\u00e9cessite deux c\u0153urs complets pour fonctionner, vous d\u00e9finissez la valeur \u00e0 2000m. Si le conteneur a seulement besoin de la puissance d'un quart de c\u0153ur, la valeur sera de 250m. Gardez \u00e0 l'esprit que si vous assignez une valeur de ressources CPU sup\u00e9rieure au nombre de c\u0153urs du n\u0153ud le plus puissant, le lancement de votre pod ne sera pas planifi\u00e9 du tout. Une situation similaire se produira si vous avez un pod n\u00e9cessitant quatre c\u0153urs, alors que le cluster Kubernetes ne se compose que de deux machines virtuelles principales.<\/p>\n

\u00c0 moins que votre application ne soit sp\u00e9cifiquement con\u00e7ue pour tirer parti de plusieurs c\u0153urs (on pense \u00e0 des programmes tels que des calculs scientifiques complexes et des op\u00e9rations sur des bases de donn\u00e9es), la meilleure pratique consiste \u00e0 d\u00e9finir les demandes de CPU \u00e0 1 ou moins, suivie du lancement d'un plus grand nombre de r\u00e9pliques pour la scalabilit\u00e9. Cette approche donnera au syst\u00e8me plus de flexibilit\u00e9 et de fiabilit\u00e9.<\/p>\n

Quand il s'agit des limites de CPU, les choses deviennent plus int\u00e9ressantes, car il est consid\u00e9r\u00e9 comme une ressource compressible. Si votre application commence \u00e0 atteindre la limite de puissance CPU, Kubernetes commencera \u00e0 ralentir votre conteneur en utilisant le throttling CPU \u2014 une r\u00e9duction de la fr\u00e9quence du processeur. Cela signifie que le CPU sera artificiellement limit\u00e9, offrant potentiellement \u00e0 l'application de moins bonnes performances, mais le processus ne sera pas arr\u00eat\u00e9 ou expuls\u00e9. <\/p>\n

Les ressources m\u00e9moire sont d\u00e9finies en octets. En g\u00e9n\u00e9ral, la valeur dans les param\u00e8tres est mesur\u00e9e en m\u00e9bibytes (MiB), mais vous pouvez d\u00e9finir n'importe quelle valeur, des octets aux p\u00e9taoctets. Ici, la m\u00eame situation se produit qu'avec le CPU \u2014 si vous demandez une quantit\u00e9 de m\u00e9moire d\u00e9passant la m\u00e9moire disponible sur vos n\u0153uds, l'ex\u00e9cution de ce pod ne sera pas planifi\u00e9e. Toutefois, contrairement aux ressources CPU, la m\u00e9moire n'est pas compressible, car il n'y a aucun moyen de limiter son utilisation. Ainsi, l'ex\u00e9cution du conteneur sera arr\u00eat\u00e9e d\u00e8s qu'il d\u00e9passera la m\u00e9moire qui lui a \u00e9t\u00e9 allou\u00e9e.<\/p>\n

\"Meilleures
\n
\nIl est important de se rappeler que vous ne pouvez pas configurer des demandes qui d\u00e9passent la taille des ressources que vos n\u0153uds peuvent fournir. Les caract\u00e9ristiques des ressources partag\u00e9es pour les machines virtuelles GKE peuvent \u00eatre trouv\u00e9es dans les liens plac\u00e9s sous cette vid\u00e9o.<\/p>\n

Dans un monde id\u00e9al, les configurations de conteneurs par d\u00e9faut seraient largement suffisantes pour que les flux de travail se d\u00e9roulent sans accroc. Mais le monde r\u00e9el n'est pas tel, les gens peuvent facilement oublier de configurer l'utilisation des ressources ou des hackers peuvent d\u00e9finir des demandes et des limites qui d\u00e9passent les capacit\u00e9s r\u00e9elles de l'infrastructure. Pour \u00e9viter de telles sc\u00e9narios, il est possible de configurer des quotas de ressources ResourceQuota et des plages de limites LimitRange.<\/p>\n

Apr\u00e8s la cr\u00e9ation des espaces de noms, ils peuvent \u00eatre bloqu\u00e9s \u00e0 l'aide de quotas. Par exemple, si vous avez des espaces de noms prod et dev, vous pouvez utiliser un mod\u00e8le o\u00f9 les quotas de production sont totalement absents alors que les quotas de d\u00e9veloppement sont tr\u00e8s stricts. Cela permet \u00e0 prod, en cas de pic de trafic soudain, de prendre toutes les ressources disponibles, bloquant compl\u00e8tement dev.<\/p>\n

Un quota de ressources pourrait ressembler \u00e0 ceci. Dans cet exemple, il y a 4 sections \u2013 c'est 4 lignes de code inf\u00e9rieures.<\/p>\n

\"Meilleures
\n
\nExaminons chacun d'eux. Requests.cpu repr\u00e9sente le nombre maximal combin\u00e9 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\u00e9rieur \u00e0 500m, tout ira bien.<\/p>\n

La m\u00e9moire demand\u00e9e requests.memory repr\u00e9sente la taille maximale combin\u00e9e des demandes de m\u00e9moire que peuvent avoir tous les conteneurs dans un espace de noms. Comme dans le cas pr\u00e9c\u00e9dent, 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\u00e9moire demand\u00e9e dans l'espace de noms reste inf\u00e9rieur \u00e0 100 mebibytes.<\/p>\n

Limits.cpu est la valeur maximale combin\u00e9e de la puissance processeur que peuvent utiliser tous les conteneurs d'un espace de noms. On peut consid\u00e9rer cela comme la limite des demandes de puissance processeur.<\/p>\n

Enfin, limits.memory correspond \u00e0 la quantit\u00e9 maximale de m\u00e9moire g\u00e9n\u00e9rale pouvant \u00eatre utilis\u00e9e par tous les conteneurs dans un espace de noms. Ce seuil concerne les demandes de m\u00e9moire globales.
\nAinsi, par d\u00e9faut, les conteneurs d'un cluster Kubernetes fonctionnent avec des ressources de calcul illimit\u00e9es. Gr\u00e2ce aux quotas de ressources, les administrateurs de cluster peuvent limiter la consommation et la cr\u00e9ation 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\u00e9moire que d\u00e9fini par le quota de ressources. Cependant, il existe des pr\u00e9occupations quant \u00e0 la possibilit\u00e9 qu'un seul pod ou conteneur monopolise toutes les ressources disponibles. Pour \u00e9viter cela, il est utilis\u00e9 un seuil de plage de limitation \u2013 une politique d'allocation des ressources (pour les pods ou conteneurs) dans l'espace de noms.<\/p>\n

La plage de limites fournit des contraintes qui peuvent :<\/p>\n