{"id":94262,"date":"2020-09-14T19:42:34","date_gmt":"2020-09-14T17:42:34","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/kak-poluchit-dostup-k-resursam-kubernetes-pod"},"modified":"2020-09-14T19:42:34","modified_gmt":"2020-09-14T17:42:34","slug":"kak-poluchit-dostup-k-resursam-kubernetes-pod","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/kak-poluchit-dostup-k-resursam-kubernetes-pod","title":{"rendered":"Comment acc\u00e9der aux ressources d'un pod Kubernetes","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Comment acc\u00e9der aux ressources d&#039;un pod Kubernetes\" src=\"\/wp-content\/uploads\/2020\/09\/3d6760d512ef456daad121f7d1ddbcf8.jpg\" style=\"display:block;margin: 0 auto;\" \/><noindex><a rel=\"nofollow\" href=\"https:\/\/www.deviantart.com\/tohad\/art\/The-Reward-549720998\"><i>La R\u00e9compense par Tohad<\/i><\/a><\/noindex><\/p>\n<p>Lors de la premi\u00e8re utilisation de Kubernetes, on oublie g\u00e9n\u00e9ralement de configurer les ressources des conteneurs. \u00c0 ce stade, il suffit de s'assurer que l'image Docker fonctionne et peut \u00eatre d\u00e9ploy\u00e9e dans le cluster Kubernetes.<\/p>\n<p>Mais par la suite, l'application doit \u00eatre d\u00e9ploy\u00e9e dans le cluster de production avec d'autres applications. Pour cela, il est n\u00e9cessaire d'allouer des ressources au conteneur et de s'assurer qu'elles sont suffisantes pour le lancement et le fonctionnement de l'application, sans causer de probl\u00e8mes aux autres applications en cours d'ex\u00e9cution.<\/p>\n<p>Commande <noindex><a rel=\"nofollow\" href=\"https:\/\/mcs.mail.ru\/\">Kubernetes aaS de Mail.ru<\/a><\/noindex> J'ai traduit un article sur les ressources des conteneurs (CPU &amp; MEM), les demandes et les limites de ressources. Vous apprendrez quels avantages ces r\u00e9glages apportent et ce qu'il adviendra si vous ne les configurez pas.<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h2>Ressources de calcul<\/h2>\n<p>\nNous avons deux types de ressources avec les unit\u00e9s suivantes :<\/p>\n<ul>\n<li>Processeur central (CPU) \u2014 c\u0153urs;<\/li>\n<li>M\u00e9moire (MEM) \u2014 octets.<\/li>\n<\/ul>\n<p>\nLes ressources sont sp\u00e9cifi\u00e9es pour chaque conteneur. Dans le fichier YAML suivant pour le Pod, vous verrez la section des ressources, qui contient les ressources demand\u00e9es et limites :<\/p>\n<ul>\n<li>Ressources demand\u00e9es pour le Pod = somme des ressources demand\u00e9es de tous les conteneurs ;<\/li>\n<li>Ressources limites du Pod = somme des ressources limites de tous les conteneurs.<\/li>\n<\/ul>\n<p><\/p>\n<pre><code class=\"plaintext\">apiVersion: v1\nkind: Pod\nmetadata:\n  name: backend-pod-name\n  labels:\n    application: backend\nspec:\n  containers:\n    - name: main-container\n      image: my-backend\n      tag: v1\n      ports:\n      - containerPort: 8080\n      resources:\n        requests:\n          cpu: 0.2 # CPU SOLLICIT\u00c9 : 200m c\u0153urs\n          memory: \"1Gi\" # M\u00c9MOIRE SOLLICIT\u00c9E : 1Gi\n        limits:\n          cpu: 1 # UTILISATION MAXIMALE DU CPU : 1 c\u0153ur\n          memory: \"1Gi\" # UTILISATION MAXIMALE DE LA M\u00c9MOIRE : 1Gi\n    - name: other-container\n      image: other-app\n      tag: v1\n      ports:\n      - containerPort: 8000\n      resources:\n        requests:\n          cpu: \"200m\" # CPU SOLLICIT\u00c9 : 200m c\u0153urs\n          memory: \"0.5Gi\" # M\u00c9MOIRE SOLLICIT\u00c9E : 0.5Gi\n        limits:\n          cpu: 1 # UTILISATION MAXIMALE DU CPU : 1 c\u0153ur\n          memory: \"1Gi\" # UTILISATION MAXIMALE DE LA M\u00c9MOIRE : 1Gi<\/code><\/pre>\n<p>Exemple de ressources demand\u00e9es et limites<\/p>\n<p>Champ <code>resources.requested<\/code> de la sp\u00e9cification du Pod \u2014 un des \u00e9l\u00e9ments utilis\u00e9s pour rechercher le n\u0153ud ad\u00e9quat. Cela permet d\u00e9j\u00e0 de planifier le d\u00e9ploiement du Pod. Comment trouve-t-on un n\u0153ud appropri\u00e9 ?<\/p>\n<p>Kubernetes se compose de plusieurs composants, y compris un n\u0153ud principal ou n\u0153ud ma\u00eetre (Kubernetes Control Plane). Dans le n\u0153ud ma\u00eetre, plusieurs processus sont en cours : kube-apiserver, kube-controller-manager et kube-scheduler. <\/p>\n<p>Le processus kube-scheduler est responsable de l'examen des nouveaux modules cr\u00e9\u00e9s et de la recherche des n\u0153uds de travail possibles qui r\u00e9pondent \u00e0 toutes les demandes des modules, y compris en termes de ressources demand\u00e9es. La liste des n\u0153uds trouv\u00e9s par kube-scheduler est class\u00e9e. Le Pod est planifi\u00e9 sur le n\u0153ud avec les meilleures notes.<\/p>\n<p><img decoding=\"async\" alt=\"Comment acc\u00e9der aux ressources d&#039;un pod Kubernetes\" src=\"\/wp-content\/uploads\/2020\/09\/b489991a3cbbd5359c99701886d488e5.jpg\" style=\"display:block;margin: 0 auto;\" \/>O\u00f9 sera plac\u00e9 le Pod violet ?<\/p>\n<p>L'image montre que le kube-scheduler doit planifier un nouveau Pod violet. Le cluster Kubernetes contient deux n\u0153uds : A et B. Comme vous pouvez le constater, le kube-scheduler ne peut pas planifier le Pod sur le n\u0153ud A \u2014 les ressources disponibles (non requises) ne correspondent pas aux demandes du Pod violet. Ainsi, la m\u00e9moire demand\u00e9e par le Pod violet est de 1 Go, ce qui ne peut pas tenir sur le n\u0153ud A, car la m\u00e9moire disponible est de 0,5 Go. Mais le n\u0153ud B a suffisamment de ressources. En fin de compte, le kube-scheduler d\u00e9cide que la destination du Pod violet est le n\u0153ud B.<\/p>\n<p>Maintenant, nous savons comment les ressources demand\u00e9es influencent le choix du n\u0153ud pour ex\u00e9cuter un Pod. Mais comment les ressources limites influencent-elles ?<\/p>\n<p>Les ressources limites sont la fronti\u00e8re que le CPU\/MEM ne peut pas franchir. Cependant, la ressource CPU est flexible, donc les conteneurs atteignant les valeurs limites du CPU ne provoqueront pas l'arr\u00eat du Pod. Au lieu de cela, un throttling CPU sera appliqu\u00e9. Si la limite d'utilisation de la MEM est atteinte, le conteneur sera arr\u00eat\u00e9 en raison de l'OOM-Killer et red\u00e9marr\u00e9, si cela est autoris\u00e9 par la configuration RestartPolicy.<\/p>\n<h2>Ressources demand\u00e9es et limites en d\u00e9tail<\/h2>\n<p>\n<img decoding=\"async\" alt=\"Comment acc\u00e9der aux ressources d&#039;un pod Kubernetes\" src=\"\/wp-content\/uploads\/2020\/09\/22e672100940e8895ae42a56a681111f.jpg\" style=\"display:block;margin: 0 auto;\" \/>Relation des ressources entre Docker et Kubernetes<\/p>\n<p>La meilleure fa\u00e7on d'expliquer comment fonctionnent les ressources demand\u00e9es et limites est de repr\u00e9senter la relation entre Kubernetes et Docker. Dans l'image ci-dessus, vous pouvez voir comment les champs Kubernetes et les options de d\u00e9marrage Docker sont li\u00e9s.<\/p>\n<h2>M\u00e9moire : demande et limite<\/h2>\n<p><\/p>\n<pre><code class=\"plaintext\">containers:\n...\n resources:\n   requests:\n     memory: \"0.5Gi\"\n   limits:\n     memory: \"1Gi\"\n<\/code><\/pre>\n<p>\nComme mentionn\u00e9 ci-dessus, la m\u00e9moire est mesur\u00e9e en octets. En se basant sur <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/concepts\/configuration\/manage-resources-containers\/#meaning-of-memory\">documentation Kubernetes<\/a><\/noindex>, nous pouvons indiquer la m\u00e9moire sous forme de nombre. En g\u00e9n\u00e9ral, c'est un entier, par exemple 2678 \u2014 c'est-\u00e0-dire 2678 octets. On peut \u00e9galement utiliser des suffixes <code>G<\/code> et <code>Gi<\/code>, il est important de se rappeler qu'ils ne sont pas \u00e9quivalents. Le premier est d\u00e9cimal, tandis que le second est binaire. Comme exemple, mentionn\u00e9 dans la documentation k8s : <code>128974848<\/code>, <code>129e6<\/code>, <code>129M<\/code>, <code>123Mi<\/code> \u2014 ils sont pratiquement \u00e9quivalents.<\/p>\n<p>La cl\u00e9 Kubernetes <code>limits.memory<\/code> correspond \u00e0 l'option <code>--memory<\/code> de Docker. En ce qui concerne le <code>request.memory<\/code> la fl\u00e8che pour Docker est absente, car Docker n'utilise pas ce champ. Vous pourriez demander si cela est vraiment n\u00e9cessaire ? Oui, c'est n\u00e9cessaire. Comme je l'ai d\u00e9j\u00e0 mentionn\u00e9, ce champ a de l'importance pour Kubernetes. Sur la base des informations qu'il contient, le kube-scheduler d\u00e9termine sur quel n\u0153ud planifier le Pod.<\/p>\n<p><strong>Que se passe-t-il si on d\u00e9finit une demande de m\u00e9moire insuffisante ?<\/strong><\/p>\n<p>Si le conteneur atteint les limites de la m\u00e9moire demand\u00e9e, le Pod est plac\u00e9 dans un groupe de Pods qui s'arr\u00eatent en cas de manque de m\u00e9moire dans le n\u0153ud.<\/p>\n<p><strong>Que se passe-t-il si vous d\u00e9finissez une limite de m\u00e9moire trop basse ?<\/strong><\/p>\n<p>Si le conteneur d\u00e9passe la limite de m\u00e9moire, il sera termin\u00e9 pour cause d'OOM-Killed. Il sera red\u00e9marr\u00e9 si possible en fonction de RestartPolicy, o\u00f9 la valeur par d\u00e9faut est <code>Always<\/code>.<\/p>\n<p><strong>Que se passera-t-il si aucune m\u00e9moire demand\u00e9e n'est sp\u00e9cifi\u00e9e ?<\/strong><\/p>\n<p>Kubernetes prendra la limite de m\u00e9moire et l'\u00e9tablira comme valeur par d\u00e9faut.<\/p>\n<p><strong>Que peut-il se passer si aucune limite de m\u00e9moire n'est sp\u00e9cifi\u00e9e ?<\/strong><\/p>\n<p>Le conteneur n'a aucune restriction, il peut utiliser autant de m\u00e9moire qu'il le souhaite. S'il commence \u00e0 utiliser toute la m\u00e9moire disponible du n\u0153ud, il sera tu\u00e9 par OOM. Le conteneur sera ensuite red\u00e9marr\u00e9, si cela est possible selon la RestartPolicy.<\/p>\n<p><strong>Que se passe-t-il si aucune limite de m\u00e9moire n'est d\u00e9finie ?<\/strong><\/p>\n<p>C'est le pire sc\u00e9nario : le planificateur ne sait pas combien de ressources le conteneur n\u00e9cessite, ce qui peut causer de graves probl\u00e8mes sur le n\u0153ud. Dans ce cas, il serait bon d'avoir des limites par d\u00e9faut dans l'espace de noms (\u00e9tablies par LimitRange). Il n'y a pas de limites par d\u00e9faut - le Pod n'a aucune restriction, il peut utiliser autant de m\u00e9moire qu'il le souhaite.<\/p>\n<p>Si la m\u00e9moire demand\u00e9e est sup\u00e9rieure \u00e0 ce que peut offrir le n\u0153ud, le Pod ne sera pas planifi\u00e9. Il est important de se rappeler que <code>Requests.memory<\/code> n'est pas une valeur minimale. C'est une description de la quantit\u00e9 de m\u00e9moire suffisante pour le fonctionnement continu du conteneur. <\/p>\n<p>On recommande g\u00e9n\u00e9ralement de d\u00e9finir la m\u00eame valeur pour <code>request.memory<\/code> et <code>limit.memory<\/code>. Cela permet \u00e0 Kubernetes de ne pas planifier le Pod sur un n\u0153ud qui a suffisamment de m\u00e9moire pour le d\u00e9marrage du Pod, mais pas assez pour son fonctionnement. Gardez \u00e0 l'esprit que lors de la planification du Pod, Kubernetes ne prend en compte que <code>requests.memory<\/code>, et <code>limits.memory<\/code> et ne prend pas en compte.<\/p>\n<h2>CPU : demande et limite<\/h2>\n<p><\/p>\n<pre><code class=\"plaintext\">containers:\n...\n resources:\n   requests:\n     cpu: 1\n   limits:\n     cpu: \"1200m\"\n<\/code><\/pre>\n<p>\nPour le CPU, c'est un peu plus compliqu\u00e9. En revenant \u00e0 l'image de la relation entre Kubernetes et Docker, on peut remarquer que <code>request.cpu<\/code> correspond \u00e0 <code>--cpu-shares<\/code>, tandis que <code>limit.cpu<\/code> correspond \u00e0 l'option <code>cpus<\/code> dans Docker.<\/p>\n<p>Le CPU demand\u00e9 par Kubernetes est multipli\u00e9 par 1024 \u2014 la proportion des cycles CPU. Si vous souhaitez demander un c\u0153ur complet, vous devez ajouter <code>cpu: 1<\/code>, comme indiqu\u00e9 ci-dessus. <\/p>\n<p>La demande d'un c\u0153ur complet (ratio = 1024) ne signifie pas que votre conteneur l'obtiendra. Si votre h\u00f4te ne dispose que d'un seul c\u0153ur et que vous utilisez plus d'un conteneur, tous les conteneurs doivent partager le CPU disponible entre eux. Comment cela se passe-t-il ? Regardons l'illustration.<\/p>\n<p><img decoding=\"async\" alt=\"Comment acc\u00e9der aux ressources d&#039;un pod Kubernetes\" src=\"\/wp-content\/uploads\/2020\/09\/7f4b20642708ef3a7e773d7900161267.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nDemande de CPU - syst\u00e8me \u00e0 un c\u0153ur<\/p>\n<p>Imaginons que vous ayez un syst\u00e8me h\u00f4te avec un seul c\u0153ur sur lequel des conteneurs sont en cours d'ex\u00e9cution. Maman (Kubernetes) a cuit un g\u00e2teau (CPU) et veut le partager avec ses enfants (les conteneurs). Trois enfants veulent un g\u00e2teau entier (ratio = 1024), un autre enfant veut la moiti\u00e9 d'un g\u00e2teau (512). Maman veut \u00eatre juste et fait un calcul simple.<\/p>\n<pre><code class=\"plaintext\"># \u0421\u043a\u043e\u043b\u044c\u043a\u043e \u043f\u0438\u0440\u043e\u0433\u043e\u0432 \u0445\u043e\u0442\u044f\u0442 \u0434\u0435\u0442\u0438?\n# 3 \u0440\u0435\u0431\u0435\u043d\u043a\u0430 \u0445\u043e\u0442\u044f\u0442 \u043f\u043e \u0446\u0435\u043b\u043e\u043c\u0443 \u043f\u0438\u0440\u043e\u0433\u0443 \u0438 \u0435\u0449\u0435 \u043e\u0434\u0438\u043d \u0445\u043e\u0447\u0435\u0442 \u043f\u043e\u043b\u043e\u0432\u0438\u043d\u0443 \u043f\u0438\u0440\u043e\u0433\u0430\ncakesNumberKidsWant = (3 * 1) + (1 * 0.5) = 3.5\n# \u0412\u044b\u0440\u0430\u0436\u0435\u043d\u0438\u0435 \u043f\u043e\u043b\u0443\u0447\u0430\u0435\u0442\u0441\u044f \u0442\u0430\u043a:\n3 (\u0440\u0435\u0431\u0435\u043d\u043a\u0430\/\u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440\u0430) * 1 (\u0446\u0435\u043b\u044b\u0439 \u043f\u0438\u0440\u043e\u0433\/\u043f\u043e\u043b\u043d\u043e\u0435 \u044f\u0434\u0440\u043e) + 1 (\u0440\u0435\u0431\u0435\u043d\u043e\u043a\/\u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440) * 0.5 (\u043f\u043e\u043b\u043e\u0432\u0438\u043d\u0430 \u043f\u0438\u0440\u043e\u0433\u0430\/\u043f\u043e\u043b\u043e\u0432\u0438\u043d\u0430 \u044f\u0434\u0440\u0430)\n# \u0421\u043a\u043e\u043b\u044c\u043a\u043e \u043f\u0438\u0440\u043e\u0433\u043e\u0432 \u0438\u0441\u043f\u0435\u0447\u0435\u043d\u043e?\navailableCakesNumber = 1\n# \u0421\u043a\u043e\u043b\u044c\u043a\u043e \u043f\u0438\u0440\u043e\u0433\u0430 (\u043c\u0430\u043a\u0441\u0438\u043c\u0430\u043b\u044c\u043d\u043e) \u0434\u0435\u0442\u0438 \u0440\u0435\u0430\u043b\u044c\u043d\u043e \u043c\u043e\u0433\u0443\u0442 \u043f\u043e\u043b\u0443\u0447\u0438\u0442\u044c?\nnewMaxRequest = 1 \/ 3.5 =~ 28%<\/code><\/pre>\n<p>\nD'apr\u00e8s le calcul, trois enfants recevront 28 % d'un c\u0153ur, et non un c\u0153ur entier. Le quatri\u00e8me enfant recevra 14 % d'un c\u0153ur complet, et non la moiti\u00e9. Mais tout sera diff\u00e9rent si vous avez un syst\u00e8me multic\u0153ur.<\/p>\n<p><img decoding=\"async\" alt=\"Comment acc\u00e9der aux ressources d&#039;un pod Kubernetes\" src=\"\/wp-content\/uploads\/2020\/09\/7bf71d97add9adcf7cf0260941526590.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nDemande de CPU - syst\u00e8me multic\u0153ur (4)<\/p>\n<p>Dans l'image ci-dessus, on voit que trois enfants veulent un g\u00e2teau entier, et un veut la moiti\u00e9. Comme maman a cuit quatre g\u00e2teaux, chacun de ses enfants recevra autant qu'il le souhaite. Dans un syst\u00e8me multic\u0153ur, les ressources processeur sont r\u00e9parties sur tous les c\u0153urs disponibles. Si un conteneur est limit\u00e9 \u00e0 moins d'un c\u0153ur complet de CPU, il peut quand m\u00eame l'utiliser \u00e0 100 %. <\/p>\n<p>Les calculs ci-dessus sont simplifi\u00e9s pour illustrer comment le CPU est r\u00e9parti entre les conteneurs. Bien s\u00fbr, en plus des conteneurs eux-m\u00eames, il existe d'autres processus qui utilisent \u00e9galement les ressources CPU. Lorsque des processus dans un conteneur sont inactifs, d'autres peuvent utiliser sa ressource. <code>CPU: \"200m\"<\/code> correspond \u00e0 <code>CPU : 0,2<\/code>, ce qui repr\u00e9sente environ 20 % d'un c\u0153ur.<\/p>\n<p>Maintenant, parlons de <code>limit.cpu<\/code>. Le CPU, qui limite Kubernetes, est multipli\u00e9 par 100. Le r\u00e9sultat est le temps pendant lequel le conteneur peut utiliser chaque 100 microsecondes (<code>cpu-period<\/code>). <\/p>\n<p><code>limit.cpu<\/code> correspond \u00e0 l'option Docker <code>--cpus<\/code>. C'est une nouvelle combinaison des anciennes <code>--cpu-period<\/code> et <code>--cpu-quota<\/code>. En le d\u00e9finissant, nous indiquons combien de ressources CPU disponibles un conteneur peut utiliser au maximum avant que le throttling ne commence :<\/p>\n<ul>\n<li><strong>cpus<\/strong> \u2014 combinaison <code>cpu-period<\/code> et <code>cpu-quota. cpus = 1.5<\/code> \u00e9quivaut \u00e0 d\u00e9finir <code>cpu-period = 100000<\/code> et <code>cpu-quota = 150000<\/code>;<\/li>\n<li><strong>cpu-period<\/strong> \u2014 p\u00e9riode <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Completely_Fair_Scheduler\">du planificateur CPU CFS<\/a><\/noindex>, par d\u00e9faut 100 microsecondes ;<\/li>\n<li><strong>cpu-quota<\/strong> \u2014 nombre de microsecondes \u00e0 l'int\u00e9rieur <code>cpu-period<\/code>, dont le conteneur est limit\u00e9.<\/li>\n<\/ul>\n<p>\n<strong>Que se passera-t-il si vous configurez une demande de CPU insuffisante ?<\/strong><\/p>\n<p>Si le conteneur a besoin de plus que ce qui est allou\u00e9, il volera du CPU \u00e0 d'autres processus.<\/p>\n<p><strong>Que se passera-t-il si vous configurez une limite de CPU insuffisante ?<\/strong><\/p>\n<p>\u00c9tant donn\u00e9 que la ressource CPU est r\u00e9glement\u00e9e, le throttling sera activ\u00e9.<\/p>\n<p><strong>Que se passera-t-il si vous ne sp\u00e9cifiez pas de demande de CPU ?<\/strong><\/p>\n<p>Comme pour la m\u00e9moire, la valeur de la demande est \u00e9gale \u00e0 la limite.<\/p>\n<p><strong>Que se passera-t-il si vous ne sp\u00e9cifiez pas de limite de CPU ?<\/strong><\/p>\n<p>Le conteneur utilisera autant de CPU que n\u00e9cessaire. Si une politique de CPU par d\u00e9faut est d\u00e9finie dans l'espace de noms (LimitRange), cette limite sera \u00e9galement appliqu\u00e9e au conteneur.<\/p>\n<p><strong>Que se passera-t-il si vous ne sp\u00e9cifiez ni demande ni limite de CPU ?<\/strong><\/p>\n<p>Comme pour la m\u00e9moire, ceci est le pire sc\u00e9nario. Le planificateur ne saura pas combien de ressources votre conteneur a besoin, ce qui peut causer des probl\u00e8mes graves sur le n\u0153ud. Pour \u00e9viter cela, il est n\u00e9cessaire de d\u00e9finir des limites par d\u00e9faut pour les espaces de noms (LimitRange).<\/p>\n<p>N'oubliez pas : si vous demandez plus de CPU que ce que les n\u0153uds peuvent fournir, le Pod ne sera pas planifi\u00e9. <code>Requests.cpu<\/code> \u2014 ce n'est pas la valeur minimale, mais la valeur suffisante pour faire fonctionner le Pod sans erreurs. Si l'application n'effectue pas de calculs intensifs, le mieux est de d\u00e9finir <code>request.cpu &lt;= 1<\/code> et d'ex\u00e9cuter autant de r\u00e9pliques que n\u00e9cessaire.<\/p>\n<h2>La quantit\u00e9 id\u00e9ale de ressources demand\u00e9es ou de limite de ressources<\/h2>\n<p>\nNous avons appris \u00e0 propos de la limitation des ressources de calcul. Il est maintenant temps de r\u00e9pondre \u00e0 la question : \"De combien de ressources mon Pod a-t-il besoin pour faire fonctionner l'application sans probl\u00e8mes ? Quelle est la quantit\u00e9 id\u00e9ale ?\". <\/p>\n<p>Malheureusement, il n'y a pas de r\u00e9ponses d\u00e9finitives \u00e0 ces questions. Si vous ne savez pas comment votre application fonctionne, combien de CPU ou de m\u00e9moire elle n\u00e9cessite, le mieux est de donner \u00e0 l'application beaucoup de m\u00e9moire et de CPU, puis d'ex\u00e9cuter des tests de performance.<\/p>\n<p>En plus des tests de performance, surveillez le comportement de l'application au cours de la semaine avec un monitoring. Si les graphiques montrent que votre application consomme moins de ressources que ce que vous avez demand\u00e9, vous pouvez r\u00e9duire le montant de CPU ou de m\u00e9moire demand\u00e9.<\/p>\n<p>Comme exemple, regardez ce <noindex><a rel=\"nofollow\" href=\"https:\/\/grafana.com\/grafana\/dashboards\/7187\">tableau de bord Grafana<\/a><\/noindex>. Il affiche la diff\u00e9rence entre les ressources demand\u00e9es ou la limite de ressources et l'utilisation actuelle des ressources.<\/p>\n<h2>Conclusion<\/h2>\n<p>\nLa demande et la limitation des ressources aident \u00e0 maintenir la fonctionnalit\u00e9 d'un cluster Kubernetes. Une configuration ad\u00e9quate des limites minimise les co\u00fbts et maintient les applications en fonctionnement de mani\u00e8re constante.<\/p>\n<p>En r\u00e9sum\u00e9, il y a plusieurs points \u00e0 garder \u00e0 l'esprit :<\/p>\n<ol>\n<li>Les ressources demand\u00e9es sont la configuration qui est prise en compte au moment du d\u00e9marrage (lorsque Kubernetes planifie le d\u00e9ploiement de l'application). En revanche, la limitation des ressources est importante pendant l'ex\u00e9cution \u2014 lorsque l'application est d\u00e9j\u00e0 en cours d'ex\u00e9cution sur un n\u0153ud.<\/li>\n<li>Compar\u00e9 \u00e0 la m\u00e9moire, le CPU est une ressource r\u00e9gulable. En cas de p\u00e9nurie de CPU, votre Pod ne s'arr\u00eatera pas, un m\u00e9canisme de throttling s'enclenchera.<\/li>\n<li>Les ressources demand\u00e9es et les limites de ressources ne sont pas des valeurs minimales et maximales ! En d\u00e9finissant les ressources demand\u00e9es, vous garantissez que l'application fonctionnera sans probl\u00e8me.<\/li>\n<li>Il est bon de d\u00e9finir une demande de m\u00e9moire \u00e9gale \u00e0 la limite de m\u00e9moire.<\/li>\n<li>Il est bon de d\u00e9finir la demande <code>CPU &lt;= 1<\/code>, si l'application ne n\u00e9cessite pas de calculs complexes.<\/li>\n<li>Si vous demandez plus de ressources qu'il n'y en a sur le n\u0153ud, alors le Pod ne sera jamais planifi\u00e9 sur ce n\u0153ud.<\/li>\n<li>Pour d\u00e9terminer la quantit\u00e9 appropri\u00e9e de ressources demand\u00e9es \/ limites de ressources, utilisez des tests de charge et du monitoring.<\/li>\n<\/ol>\n<p>\nJ'esp\u00e8re que cet article vous aidera \u00e0 comprendre le concept fondamental des limitations de ressources. Et vous pourrez appliquer ces connaissances dans votre travail.<\/p>\n<p>Bonne chance !<\/p>\n<p><strong>Que lire d'autre :<\/strong><\/p>\n<ol>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/mailru\/blog\/500504\/\">Observabilit\u00e9 SRE : espaces de noms et structure des m\u00e9triques<\/a><\/noindex>.<\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/mcs.mail.ru\/blog\/poleznye-instrumenty-dlya-kubernetes\">90+ outils utiles pour Kubernetes : d\u00e9ploiement, gestion, monitoring, s\u00e9curit\u00e9 et plus encore<\/a><\/noindex>.<\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/tele.click\/k8s_mail\">Notre cha\u00eene Autour de Kubernetes sur Telegram<\/a><\/noindex>.<\/li>\n<\/ol>\n<p>Source : <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/mailru\/blog\/516014\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>The Reward by Tohad \u0412 \u043d\u0430\u0447\u0430\u043b\u0435 \u0440\u0430\u0431\u043e\u0442\u044b \u0441 Kubernetes \u043e\u0431\u044b\u0447\u043d\u043e \u0437\u0430\u0431\u044b\u0432\u0430\u044e\u0442 \u043e \u043d\u0430\u0441\u0442\u0440\u043e\u0439\u043a\u0435 \u0440\u0435\u0441\u0443\u0440\u0441\u043e\u0432 \u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440\u043e\u0432. \u041d\u0430 \u044d\u0442\u043e\u043c \u044d\u0442\u0430\u043f\u0435 \u0434\u043e\u0441\u0442\u0430\u0442\u043e\u0447\u043d\u043e \u0443\u0431\u0435\u0434\u0438\u0442\u044c\u0441\u044f, \u0447\u0442\u043e \u043e\u0431\u0440\u0430\u0437 Docker \u0440\u0430\u0431\u043e\u0442\u0430\u0435\u0442 \u0438 \u0435\u0433\u043e \u043c\u043e\u0436\u043d\u043e \u0440\u0430\u0437\u0432\u0435\u0440\u043d\u0443\u0442\u044c \u0432 \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u0435 Kubernetes. \u041d\u043e \u043f\u043e\u0437\u0434\u043d\u0435\u0435 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0435 \u0442\u0440\u0435\u0431\u0443\u0435\u0442\u0441\u044f \u0440\u0430\u0437\u0432\u0435\u0440\u043d\u0443\u0442\u044c \u0432 \u043f\u0440\u043e\u0434\u0430\u043a\u0448\u0435\u043d \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u0435 \u0432\u043c\u0435\u0441\u0442\u0435 \u0441 \u0434\u0440\u0443\u0433\u0438\u043c\u0438 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u044f\u043c\u0438. \u0414\u043b\u044f \u044d\u0442\u043e\u0433\u043e \u043d\u0443\u0436\u043d\u043e \u0432\u044b\u0434\u0435\u043b\u0438\u0442\u044c \u0440\u0435\u0441\u0443\u0440\u0441\u044b \u0434\u043b\u044f \u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440\u0430 \u0438 \u0443\u0431\u0435\u0434\u0438\u0442\u044c\u0441\u044f, \u0447\u0442\u043e \u0438\u0445 \u0434\u043e\u0441\u0442\u0430\u0442\u043e\u0447\u043d\u043e [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":94263,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-94262","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.2 - aioseo.com -->\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/kak-poluchit-dostup-k-resursam-kubernetes-pod\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.2\" \/>\n\t\t<meta property=\"og:locale\" content=\"fr_FR\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u041a\u0430\u043a \u043f\u043e\u043b\u0443\u0447\u0438\u0442\u044c \u0434\u043e\u0441\u0442\u0443\u043f \u043a \u0440\u0435\u0441\u0443\u0440\u0441\u0430\u043c Kubernetes Pod | ProHoster\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/kak-poluchit-dostup-k-resursam-kubernetes-pod\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2020-09-14T17:42:34+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-09-14T17:42:34+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47 Comment acc\u00e9der aux ressources du Pod Kubernetes | ProHoster","description":"","canonical_url":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/kak-poluchit-dostup-k-resursam-kubernetes-pod","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"fr_FR","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041a\u0430\u043a \u043f\u043e\u043b\u0443\u0447\u0438\u0442\u044c \u0434\u043e\u0441\u0442\u0443\u043f \u043a \u0440\u0435\u0441\u0443\u0440\u0441\u0430\u043c Kubernetes Pod | ProHoster","og:url":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/kak-poluchit-dostup-k-resursam-kubernetes-pod","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-09-14T17:42:34+00:00","article:modified_time":"2020-09-14T17:42:34+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"94262","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 11:30:27","updated":"2022-10-02 18:20:09","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts\/94262","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/comments?post=94262"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts\/94262\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/media\/94263"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/media?parent=94262"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/categories?post=94262"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/tags?post=94262"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}