{"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! Ich hei\u00dfe Oleg Sidorenkov und arbeite als Teamleiter Infrastruktur bei der Firma DomKlick. Wir setzen \u00abKubik\u00bb seit \u00fcber drei Jahren produktiv ein und haben in dieser Zeit viele interessante Momente damit erlebt. Heute werde ich euch erz\u00e4hlen, wie man mit dem richtigen Ansatz noch mehr Leistung aus einem \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 besser gesagt, f\u00fcnf Bin\u00e4rdateien, die im Hintergrund die Magie entfalten, indem sie den Lebenszyklus eurer Mikrodienste in der Serverumgebung verwalten. Dar\u00fcber hinaus ist es ein recht flexibles Werkzeug, das wie ein Lego-Bausatz f\u00fcr maximale Anpassung an verschiedene Aufgaben zusammengestellt werden kann.<\/p>\n

Und eigentlich ist alles gut: schmei\u00dft Server in den Cluster wie Holz in den Ofen und kennt kein Problem. Aber wenn dir die Umwelt am Herzen liegt, fragst du dich: \u201eWie kann ich das Feuer im Ofen am Brennen halten und gleichzeitig den Wald schonen?\u201c. Mit anderen Worten, wie findet man Wege zur Verbesserung der Infrastruktur und zur Senkung der Kosten.<\/p>\n

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

\"Neun<\/p>\n

Eine der grundlegendsten, aber effektivsten Methoden ist die Einf\u00fchrung von Anfragen\/Limits. Trennen Sie Anwendungen nach Namespaces und Namespaces nach Entwicklungsteams. Weisen Sie der Anwendung vor dem Deployment Werte f\u00fcr die CPU-Zeit, den Speicher und den ephemeral Speicher zu.<\/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: Es ist nicht ratsam, die Anfragen von den Limits um mehr als das Doppelte zu erh\u00f6hen. Das Volumen des Clusters wird auf der Grundlage der Anfragen berechnet, und wenn Sie den Anwendungen einen Ressourcenunterschied von zum Beispiel 5-10 Mal geben, stellen Sie sich vor, was mit Ihrem Node passiert, wenn es mit Pods gef\u00fcllt wird und pl\u00f6tzlich unter hoher Last steht. Nichts Gutes. Mindestens wird es zu Throttling kommen, und maximal m\u00fcssen Sie sich von dem Worker verabschieden und erleben eine zyklische Belastung der anderen Nodes, nachdem die Pods beginnen zu migrieren.<\/p>\n
Dar\u00fcber hinaus k\u00f6nnen Sie mithilfe von limitranges<\/code> Sie k\u00f6nnen beim Start f\u00fcr den Container Werte f\u00fcr die Ressourcen festlegen \u2014 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 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 ersichtlich resourcequotas<\/code>, wenn das Team ops Pods bereitstellen m\u00f6chte, die weitere 10 CPU ben\u00f6tigen, wird der Scheduler dies verhindern und einen Fehler ausgeben:<\/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
Um ein solches Problem zu l\u00f6sen, kann man ein Werkzeug schreiben, wie zum Beispiel diese<\/a><\/noindex>, das in der Lage ist, den Zustand der Ressourcen der Teams zu speichern und zu committen.<\/p>\n
2. W\u00e4hlen Sie den optimalen Speicher<\/h2>\n
\"Neun<\/p>\n
Hier m\u00f6chte ich das Thema persistenter Volumes und des Disk-Subsystems der Worker-Knoten von Kubernetes ansprechen. Ich hoffe, dass niemand Kub auf HDD im Produktionsbetrieb verwendet, aber manchmal reicht sogar ein gew\u00f6hnliches SSD nicht aus. Wir hatten mit dem Problem zu k\u00e4mpfen, dass die Logs die Festplatte durch Input-Output-Operationen belasteten, und die L\u00f6sungsm\u00f6glichkeiten sind hier nicht sehr vielf\u00e4ltig: <\/p>\n