{"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\/de\/blog\/administrirovanie\/devyat-sovetov-po-povysheniyu-proizvoditelnosti-kubernetes","title":{"rendered":"Neun Tipps zur Leistungssteigerung von Kubernetes","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Neun<\/p>\n

Hallo zusammen! Mein Name ist Oleg Sidorenkov, ich arbeite als Teamleiter der Infrastruktur bei der Firma DomClick. Wir betreiben den \u201eKubik\u201c seit \u00fcber drei Jahren in der Produktion, und in dieser Zeit haben wir viele verschiedene interessante Momente damit erlebt. Heute werde ich euch erz\u00e4hlen, wie man mit dem richtigen Ansatz noch mehr Leistung aus \u201evanilla\u201c Kubernetes f\u00fcr euren Cluster herausholen kann. Bereit, fertig, los! <\/p>\n

Ihr wisst alle, dass Kubernetes ein skalierbares Open-Source-System zur Orchestrierung von Containern ist; oder, nun ja, 5 Bin\u00e4rdateien, die Magie bewirken, indem sie den Lebenszyklus eurer Mikrodienste in einer Serverumgebung verwalten. Dar\u00fcber hinaus ist es ein ziemlich flexibles Werkzeug, das man wie ein Lego-Baukasten f\u00fcr maximale Anpassung an verschiedene Anforderungen zusammenstellen kann.<\/p>\n

Und es scheint alles gut zu sein: Werf die Server in den Cluster, wie Holzscheite in den Ofen, und sorge dir nicht um die Hitze. Aber wenn du um die Umwelt besorgt bist, wirst du dir Gedanken machen: \"Wie kann ich das Feuer im Ofen am Brennen halten und gleichzeitig den Wald schonen?\" Mit anderen Worten, wie kannst du Wege finden, die Infrastruktur zu verbessern und die Kosten zu senken.<\/p>\n

1. Achte auf die Ressourcen der Teams und Anwendungen<\/h2>\n

\"Neun<\/p>\n

Eine der banalsten, aber effektivsten Methoden ist die Einf\u00fchrung von requests\/limits. Teile die Anwendungen nach Namespaces auf und die Namespaces nach Entwicklungsteams. Setze f\u00fcr die Anwendung vor der Bereitstellung Werte f\u00fcr den Verbrauch von CPU-Zeit, Speicher, ephemeral storage.<\/p>\n

resources:\n   requests:\n     memory: 2Gi\n     cpu: 250m\n   limits:\n     memory: 4Gi\n     cpu: 500m<\/code><\/pre>\n
Durch Erfahrung sind wir zu dem Schluss gekommen: Man sollte die Requests nicht mehr als doppelt so hoch wie die Limits ansetzen. Das Volumen des Clusters wird auf Grundlage der Requests berechnet, und wenn du deinen Anwendungen einen Unterschied bei den Ressourcen von beispielsweise 5-10 mal gibst, stell dir vor, was mit deinem Node passiert, wenn sie sich mit Pods f\u00fcllt und pl\u00f6tzlich eine Last erh\u00e4lt. Nichts Gutes. Mindestens throttling, und im schlimmsten Fall verabschiedest du dich von dem Worker und erh\u00e4ltst eine zyklische Last auf den anderen Nodes, nachdem die Pods anfangen umzuziehen.<\/p>\n
Au\u00dferdem k\u00f6nnt ihr mit limitranges<\/code> zu Beginn f\u00fcr den Container Werte f\u00fcr die Ressourcen festlegen \u2013 minimal, maximal und standardm\u00e4\u00dfig:<\/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
Vergessen Sie nicht, die Ressourcen des Namensraums zu begrenzen, damit ein Team nicht alle Ressourcen des Clusters f\u00fcr sich beanspruchen kann:<\/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
Wie aus der Beschreibung hervorgeht resourcequotas<\/code>, wenn das Team ops Pods bereitstellen m\u00f6chte, die weitere 10 CPU verbrauchen, wird der Scheduler dies nicht zulassen und einen Fehler ausgeben:<\/p>\n
Fehler beim Erstellen: Pods \"nginx-proxy-9967d8d78-nh4fs\" sind nicht erlaubt: Quota \u00fcberschritten: resource-quota, angefordert: limits.cpu=5, requests.cpu=5, genutzt: limits.cpu=77250m, requests.cpu=53850m, begrenzt: limits.cpu=10, requests.cpu=10<\/code><\/pre>\n
Um ein solches Problem zu l\u00f6sen, kann man ein Tool schreiben, wie diesen<\/a><\/noindex>, das in der Lage ist, den Zustand der Ressourcen der Teams zu speichern und zu commiten.<\/p>\n
2. W\u00e4hlen Sie den optimalen Speicherorte f\u00fcr Dateien aus<\/h2>\n
\"Neun<\/p>\n
Hier m\u00f6chte ich auf das Thema persistente Volumes und das Speichersystem der Worker-Knoten von Kubernetes eingehen. Ich hoffe, dass niemand \u201eCube\u201c auf HDD in der Produktion verwendet, aber manchmal reicht auch ein gew\u00f6hnliches SSD nicht mehr aus. Wir sind auf das Problem gesto\u00dfen, dass die Protokolle die Festplatte aufgrund von Ein-\/Ausgaben \u00fcberlasteten, und die L\u00f6sungsm\u00f6glichkeiten sind nicht sehr vielf\u00e4ltig: <\/p>\n