{"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\/de\/blog\/administrirovanie\/luchshie-praktiki-kubernetes-nastrojka-zaprosov-i-limitov-resursov","title":{"rendered":"Best Practices f\u00fcr Kubernetes. Konfiguration von Ressourcenanforderungen und -grenzen","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Best Practices f\u00fcr Kubernetes. Erstellung kleiner Container<\/a><\/noindex>
\nBest Practices f\u00fcr Kubernetes. Organisation von Kubernetes mit Namespaces<\/a><\/noindex>
\nBest Practices f\u00fcr Kubernetes. \u00dcberpr\u00fcfung der Betriebsf\u00e4higkeit von Kubernetes mit Readiness- und Liveness-Tests<\/a><\/noindex><\/p>\n

F\u00fcr jede Kubernetes-Ressource besteht die M\u00f6glichkeit, zwei Arten von Anforderungen zu konfigurieren \u2013 Requests und Limits. Die erste beschreibt die minimalen Anforderungen an verf\u00fcgbare Ressourcen eines Knotens, die zum Starten eines Containers oder Pods erforderlich sind, w\u00e4hrend die zweite strikt die Ressourcen begrenzt, die dem Container zur Verf\u00fcgung stehen. <\/p>\n

Wenn Kubernetes einen Pod plant, ist es entscheidend, dass die Container gen\u00fcgend Ressourcen f\u00fcr einen reibungslosen Betrieb haben. Wenn Sie beabsichtigen, eine gro\u00dfe Anwendung auf einem Knoten mit begrenzten Ressourcen bereitzustellen, k\u00f6nnte es gut sein, dass sie aufgrund mangelndem Arbeitsspeicher oder unzureichender CPU-Leistung nicht funktioniert. In diesem Artikel werden wir er\u00f6rtern, wie man Probleme mit unzureichenden Computerressourcen durch Resource Requests und Limits beheben kann.<\/p>\n

Anfragen und Limits sind Mechanismen, die Kubernetes verwendet, um Ressourcen wie CPU und Arbeitsspeicher zu verwalten. Anfragen stellen sicher, dass ein Container die angeforderten Ressourcen garantiert erh\u00e4lt. Wenn ein Container Ressourcen anfordert, plant Kubernetes ihn nur auf einem Knoten, der diese bereitstellen kann. Limits kontrollieren, dass die vom Container angeforderten Ressourcen niemals einen bestimmten Wert \u00fcberschreiten.<\/p>\n

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

Ein Container kann seine Rechenleistung nur bis zu einem bestimmten Limit erh\u00f6hen, danach wird er eingeschr\u00e4nkt. Lassen Sie uns sehen, wie das funktioniert. Es gibt also zwei Ressourcenarten \u2013 CPU und Arbeitsspeicher. Der Kubernetes-Planer nutzt Daten \u00fcber diese Ressourcen, um zu entscheiden, wo Ihre Pods gestartet werden sollen. Eine typische Ressourcenspezifikation f\u00fcr einen Pod sieht so aus.<\/p>\n

\"Best
\n
\nJeder Container in einem Pod kann eigene Ressourcenanforderungen und -beschr\u00e4nkungen festlegen, die additiv sind. Die CPU-Ressourcen werden in Millikernen angegeben. Wenn Ihr Container zwei volle Kerne ben\u00f6tigt, setzen Sie den Wert auf 2000m. Wenn der Container jedoch nur ein Viertel eines Kerns ben\u00f6tigt, betr\u00e4gt der Wert 250m. Beachten Sie, dass Ihr Pod nicht geplant werden kann, wenn Sie einen CPU-Wert zuweisen, der h\u00f6her ist als die Anzahl der Kerne des gr\u00f6\u00dften Knotens. Das gleiche passiert, wenn Sie einen Pod haben, der vier Kerne ben\u00f6tigt, und der Kubernetes-Cluster besteht nur aus zwei virtuellen Maschinen.<\/p>\n

Es sei denn, Ihre Anwendung wurde speziell f\u00fcr die Nutzung mehrerer Kerne entwickelt (denken Sie an Programme wie komplexe wissenschaftliche Berechnungen und Datenbankoperationen), ist es am besten, die CPU-Anforderungen auf 1 oder weniger festzulegen und dann eine gr\u00f6\u00dfere Anzahl von Replikaten zur Skalierung auszuf\u00fchren. Diese L\u00f6sung verleiht dem System mehr Flexibilit\u00e4t und Zuverl\u00e4ssigkeit.<\/p>\n

Wenn es um CPU-Beschr\u00e4nkungen geht, wird es interessanter, da sie als komprimierbare Ressource gelten. Wenn Ihre Anwendung ann\u00e4hernd an die CPU-Leistungslimits kommt, beginnt Kubernetes, Ihren Container durch CPU-Throttling zu drosseln \u2013 das bedeutet eine Reduzierung der Prozessorfrequenz. Das bedeutet, dass der Prozessor k\u00fcnstlich limitiert wird, was zu einer potenziell schlechteren Leistung Ihrer Anwendung f\u00fchren kann, aber der Prozess wird nicht angehalten oder beendet. <\/p>\n

Speicherressourcen werden in Bytes definiert. In der Regel wird der Wert in den Einstellungen in Mebibyte (Mib) angegeben, Sie k\u00f6nnen jedoch jeden Wert von Bytes bis Petabytes festlegen. Hier gilt dasselbe wie f\u00fcr die CPU \u2013 wenn Sie eine Anfrage f\u00fcr eine Menge an Speicher stellen, die das verf\u00fcgbare Ged\u00e4chtnis Ihrer Knoten \u00fcberschreitet, wird die Ausf\u00fchrung dieses Pods nicht geplant. Im Gegensatz zu CPU-Ressourcen wird der Speicher jedoch nicht komprimiert, da es keine M\u00f6glichkeit gibt, seine Nutzung einzuschr\u00e4nken. Daher wird die Ausf\u00fchrung des Containers gestoppt, sobald er die ihm zugewiesene Speichermenge \u00fcberschreitet.<\/p>\n

\"Best
\n
\nEs ist wichtig zu beachten, dass Sie keine Anfragen konfigurieren k\u00f6nnen, die die Gr\u00f6\u00dfe der Ressourcen \u00fcberschreiten, die Ihre Knoten bereitstellen k\u00f6nnen. Die Spezifikationen der gemeinsamen Ressourcen f\u00fcr GKE-VMs finden Sie unter den Links, die unter diesem Video bereitgestellt sind.<\/p>\n

In einer idealen Welt w\u00e4ren die standardm\u00e4\u00dfigen Container-Einstellungen v\u00f6llig ausreichend, damit die Workflows reibungslos ablaufen. Doch die Realit\u00e4t sieht anders aus; Menschen k\u00f6nnen leicht vergessen, die Ressourcennutzung zu konfigurieren, oder Hacker setzen Anfragen und Einschr\u00e4nkungen, die die tats\u00e4chlichen M\u00f6glichkeiten der Infrastruktur \u00fcberschreiten. Um solche Szenarien zu verhindern, k\u00f6nnen Sie Ressourcenkontingente (ResourceQuota) und Einschr\u00e4nkungsbereiche (LimitRange) festlegen.<\/p>\n

Nach der Erstellung von Namespaces k\u00f6nnen diese mit Kontingenten gesperrt werden. Wenn Sie beispielsweise die Namespaces prod und dev haben, wird ein Muster verwendet, bei dem keine Kontingente f\u00fcr die Produktion vorhanden sind, w\u00e4hrend die Kontingente f\u00fcr die Entwicklung sehr streng sind. Dies erm\u00f6glicht es prod, im Falle eines pl\u00f6tzlichen Anstiegs des Verkehrs alle verf\u00fcgbaren Ressourcen zu beanspruchen und dev vollst\u00e4ndig zu blockieren.<\/p>\n

Das Ressourcenquota k\u00f6nnte folgenderma\u00dfen aussehen. In diesem Beispiel gibt es 4 Abschnitte \u2013 das sind die 4 unteren Codezeilen.<\/p>\n

\"Best
\n
\nSchauen wir uns jeden einzelnen an. Requests.cpu ist die maximale Anzahl kombinierter Anfragen an die Prozessorleistung, die von allen Containern im Namensraum erfolgen k\u00f6nnen. In diesem Beispiel k\u00f6nnten Sie 50 Container mit je 10m Anfragen haben, f\u00fcnf Container mit je 100m Anfragen oder einfach einen Container mit einer Anfrage von 500m. Solange die gesamte Anzahl der requests.cpu f\u00fcr diesen Namensraum unter 500m bleibt, ist alles in Ordnung.<\/p>\n

Die angeforderte Speicherkapazit\u00e4t requests.memory ist die maximale Summe der gespeicherten Anfragen, die alle Container im Namensraum haben k\u00f6nnen. Wie im vorherigen Fall k\u00f6nnten Sie 50 Container mit je 2 MiB, f\u00fcnf Container mit je 20 MiB oder einen einzigen Container mit 100 MiB haben, solange die gesamte angeforderte Speicherkapazit\u00e4t im Namensraum unter 100 Mebibyte bleibt.<\/p>\n

Limits.cpu ist der maximal kombinierte Wert der Prozessorleistung, die alle Container im Namensraum nutzen k\u00f6nnen. Man kann dies als die Obergrenze f\u00fcr CPU-Anfragen betrachten.<\/p>\n

Limits.memory ist schlie\u00dflich das maximale Gesamtvolumen an Arbeitsspeicher, das alle Container im Namensraum verwenden d\u00fcrfen. Dies ist die Grenze der gesamten Speichermengenanfragen.
\nStandardm\u00e4\u00dfig arbeiten Container im Kubernetes-Cluster mit unbegrenzten Rechenressourcen. Mit Hilfe von Ressourcenquoten k\u00f6nnen Clusteradministratoren den Ressourcenverbrauch und die -bereitstellung basierend auf dem Namensraum einschr\u00e4nken. Innerhalb eines Namensraums kann ein Pod oder Container so viel CPU- und Speicherleistung verbrauchen, wie durch die Ressourcenquote des Namensraums festgelegt ist. Es besteht jedoch die Sorge, dass ein Pod oder Container alle verf\u00fcgbaren Ressourcen monopolisiert. Um dies zu verhindern, wird ein Limit Range verwendet \u2013 eine Richtlinie zur Begrenzung der Ressourcenverteilung (f\u00fcr Pods oder Container) im Namensraum.<\/p>\n

Ein Limit Range bietet Einschr\u00e4nkungen, die Folgendes erm\u00f6glichen:<\/p>\n