{"id":97982,"date":"2020-10-23T14:42:15","date_gmt":"2020-10-23T12:42:15","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/devyat-sovetov-po-povysheniyu-proizvoditelnosti-kubernetes"},"modified":"2020-11-18T00:58:47","modified_gmt":"2020-11-17T22:58:47","slug":"devyat-sovetov-po-povysheniyu-proizvoditelnosti-kubernetes","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/devyat-sovetov-po-povysheniyu-proizvoditelnosti-kubernetes","title":{"rendered":"Neuf conseils pour am\u00e9liorer la performance de Kubernetes","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Neuf<\/p>\n

Bonjour \u00e0 tous ! Je m'appelle Oleg Sidorenkov, je travaille chez DomClick en tant que responsable de l'\u00e9quipe infrastructure. Nous exploitons \u00ab Kubik \u00bb en production depuis plus de trois ans, et durant ce temps, nous avons v\u00e9cu de nombreux moments int\u00e9ressants avec lui. Aujourd'hui, je vais vous expliquer comment, en adoptant la bonne approche, vous pouvez tirer encore plus de performance de votre cluster Kubernetes \u00ab vanille \u00bb. Pr\u00eats, partez ! <\/p>\n

Vous savez tous tr\u00e8s bien que Kubernetes est un syst\u00e8me \u00e9volutif de code ouvert pour l'orchestration des conteneurs ; enfin, ou 5 binaires qui font de la magie en g\u00e9rant le cycle de vie de vos microservices dans un environnement serveur. De plus, c'est un outil assez flexible que l'on peut assembler comme un ensemble Lego pour une personnalisation maximale selon diff\u00e9rentes t\u00e2ches.<\/p>\n

Tout semble aller pour le mieux : mettez les serveurs dans le cluster comme du bois dans un four et ne vous inqui\u00e9tez pas. Mais si vous pensez \u00e0 l'\u00e9cologie, vous vous demanderez : \u00ab Comment puis-je entretenir le feu dans la chemin\u00e9e tout en pr\u00e9servant la for\u00eat ? \u00bb. Autrement dit, comment trouver des moyens d'am\u00e9liorer l'infrastructure tout en r\u00e9duisant les co\u00fbts.<\/p>\n

1. Surveillez les ressources des \u00e9quipes et des applications<\/h2>\n

\"Neuf<\/p>\n

Une des m\u00e9thodes les plus banales mais efficaces est l'introduction de requests\/limits. S\u00e9parez les applications par namespaces, et les namespaces par \u00e9quipes de d\u00e9veloppement. Attribuez aux applications, avant d\u00e9ploiement, des valeurs de consommation en termes de temps CPU, m\u00e9moire, et stockage \u00e9ph\u00e9m\u00e8re.<\/p>\n

resources:\n   requests:\n     memory: 2Gi\n     cpu: 250m\n   limits:\n     memory: 4Gi\n     cpu: 500m<\/code><\/pre>\n
Par exp\u00e9rience, nous avons constat\u00e9 qu'il ne faut pas gonfler les requests par rapport aux limits de plus du double. Le volume du cluster est calcul\u00e9 en fonction des requests, et si vous attribuez aux applications une diff\u00e9rence de ressources, par exemple, de 5 \u00e0 10 fois, imaginez ce qui arrivera \u00e0 votre n\u0153ud lorsqu'il sera rempli de pods et recevra soudain une charge. Rien de bon. Au minimum, du throttling, et au maximum, vous direz adieu \u00e0 votre worker et aurez une charge cyclique sur les autres n\u0153uds apr\u00e8s que les pods aient commenc\u00e9 \u00e0 migraient.<\/p>\n
De plus, \u00e0 l'aide de limitranges<\/code> vous pouvez d\u00e9finir d\u00e8s le d\u00e9part des valeurs de ressources pour le conteneur \u2014 minimales, maximales et par d\u00e9faut :<\/p>\n
\u279c  ~ kubectl describe limitranges --namespace ops\nName:       limit-range\nNamespace:  ops\nType        Resource           Min   Max   Default Request  Default Limit  Max Limit\/Request Ratio\n----        --------           ---   ---   ---------------  -------------  -----------------------\nContainer   cpu                50m   10    100m             100m           2\nContainer   ephemeral-storage  12Mi  8Gi   128Mi            4Gi            -\nContainer   memory             64Mi  40Gi  128Mi            128Mi          2<\/code><\/pre>\n
N'oubliez pas de limiter les ressources du namespace pour qu'une \u00e9quipe ne puisse pas prendre toutes les ressources du cluster :<\/p>\n
\u279c  ~ kubectl describe resourcequotas --namespace ops\nName:                   resource-quota\nNamespace:              ops\nResource                Used          Hard\n--------                ----          ----\nlimits.cpu              77250m        80\nlimits.memory           124814367488  150Gi\npods                    31            45\nrequests.cpu            53850m        80\nrequests.memory         75613234944   150Gi\nservices                26            50\nservices.loadbalancers  0             0\nservices.nodeports      0             0<\/code><\/pre>\n
Comme on peut le voir dans la description resourcequotas<\/code>, si l'\u00e9quipe ops souhaite d\u00e9ployer des pods qui utiliseront encore 10 CPU, l'ordonnanceur ne le permettra pas et renverra une erreur :<\/p>\n
Error creating: pods \"nginx-proxy-9967d8d78-nh4fs\" is forbidden: exceeded quota: resource-quota, requested: limits.cpu=5,requests.cpu=5, used: limits.cpu=77250m,requests.cpu=53850m, limited: limits.cpu=10,requests.cpu=10<\/code><\/pre>\n
Pour r\u00e9soudre un tel probl\u00e8me, on peut \u00e9crire un outil, par exemple, comme celui-ci<\/a><\/noindex>, capable de stocker et de commettre l'\u00e9tat des ressources des \u00e9quipes.<\/p>\n
2. Choisissez un stockage de fichiers optimal<\/h2>\n
\"Neuf<\/p>\n
Ici, je voudrais aborder le sujet des volumes persistants et du syst\u00e8me de stockage des n\u0153uds de travail de Kubernetes. J'esp\u00e8re que personne n'utilise de \u00ab Cube \u00bb sur HDD en production, mais parfois un SSD standard devient d\u00e9j\u00e0 insuffisant. Nous avons \u00e9t\u00e9 confront\u00e9s au probl\u00e8me o\u00f9 les journaux saturent le disque par les op\u00e9rations d'entr\u00e9e-sortie, et les options de solution ne sont pas tr\u00e8s nombreuses : <\/p>\n