{"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 Anfragen und Ressourcengrenzen","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Beste Praktiken f\u00fcr Kubernetes. Erstellen kleiner Container<\/a><\/noindex>
\nBeste Praktiken f\u00fcr Kubernetes. Organisation von Kubernetes mit Namensr\u00e4umen<\/a><\/noindex>
\nBeste Praktiken f\u00fcr Kubernetes. \u00dcberpr\u00fcfen der Lebensf\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. Erstere beschreibt die minimalen Anforderungen an verf\u00fcgbare Ressourcen des Knotens, die zum Starten eines Containers oder Pods erforderlich sind, w\u00e4hrend letztere die Ressourcen, die dem Container zur Verf\u00fcgung stehen, streng limitiert. <\/p>\n

Wenn Kubernetes einen Pod plant, ist es sehr wichtig, dass die Container \u00fcber gen\u00fcgend Ressourcen f\u00fcr einen reibungslosen Betrieb verf\u00fcgen. Wenn Sie eine gro\u00dfe Anwendung auf einem Knoten mit begrenzten Ressourcen bereitstellen m\u00f6chten, kann es gut sein, dass diese aufgrund von Speichermangel oder unzureichender Prozessorleistung nicht funktioniert. In diesem Artikel werden wir untersuchen, wie man Probleme mit unzureichenden Rechenressourcen mit Hilfe von Ressourcenanfragen und -beschr\u00e4nkungen l\u00f6sen kann.<\/p>\n

Requests und Limits sind Mechanismen, die Kubernetes verwendet, um Ressourcen wie Prozessor und Speicher zu verwalten. Requests gew\u00e4hrleisten, dass der Container die angeforderten Ressourcen erh\u00e4lt. Wenn der Container Ressourcen anfordert, plant Kubernetes diese nur auf dem Knoten, der sie 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 steigern, danach wird er begrenzt. Lassen Sie uns ansehen, wie dies funktioniert. Es gibt also zwei Arten von Ressourcen \u2013 Prozessor und Speicher. Der Kubernetes-Planer nutzt Informationen \u00fcber diese Ressourcen, um herauszufinden, wo Ihre Pods gestartet werden sollen. Eine typische Spezifikation der Ressourcen f\u00fcr einen Pod sieht folgenderma\u00dfen aus.<\/p>\n

\"Best
\n
\nJeder Container in einem Pod kann seine eigenen Anforderungen und Limits festlegen, und all dies ist additiv. Die Ressourcen des Prozessors werden in Millikernen definiert. Wenn Ihr Container zum Starten zwei volle Kerne ben\u00f6tigt, stellen Sie den Wert auf 2000m ein. Ben\u00f6tigt der Container jedoch nur eine Leistung von 1\/4 Kern, betr\u00e4gt der Wert 250m. Bitte beachten Sie, dass, wenn Sie einen Wert f\u00fcr die Prozessorressourcen festlegen, der gr\u00f6\u00dfer ist als die Anzahl der Kerne des gr\u00f6\u00dften Knotens, der Start Ihres Pods \u00fcberhaupt nicht geplant wird. Eine \u00e4hnliche Situation tritt ein, wenn Sie einen Pod haben, der vier Kerne ben\u00f6tigt, der Kubernetes-Cluster jedoch nur aus zwei Haupt-VMs besteht.<\/p>\n

Es sei denn, Ihre Anwendung wurde speziell entwickelt, um die Vorteile mehrerer Kerne zu nutzen (worauf Programme wie komplexe wissenschaftliche Berechnungen und Datenbankoperationen einfallen), ist es am besten, CPU-Anforderungen auf 1 oder weniger festzulegen und anschlie\u00dfend eine gr\u00f6\u00dfere Anzahl von Replikaten f\u00fcr die Skalierbarkeit zu starten. Diese L\u00f6sung verleiht dem System gr\u00f6\u00dfere Flexibilit\u00e4t und Zuverl\u00e4ssigkeit.<\/p>\n

Wenn es um die Begrenzungen des Prozessors geht, wird es interessanter, da er als komprimierbare Ressource betrachtet wird. Wenn Ihre Anwendung dem Limit der Prozessorleistung n\u00e4her kommt, wird Kubernetes beginnen, Ihren Container zu drosseln, indem es CPU-Throttling anwendet \u2014 die Frequenz des Prozessors wird gesenkt. Das bedeutet, dass der Prozessor k\u00fcnstlich begrenzt wird, was m\u00f6glicherweise zu einer schlechteren Leistung der Anwendung f\u00fchrt, jedoch wird der Prozess nicht beendet oder herausgenommen. <\/p>\n

Speicherressourcen werden in Bytes definiert. In der Regel wird der Wert in den Einstellungen in Mebibytes (Mib) angegeben, aber Sie k\u00f6nnen jeden Wert von Bytes bis Petabytes festlegen. Hier gilt die gleiche Situation wie bei der CPU: Wenn Sie einen Antrag auf eine Menge an Speicher stellen, die den Speicher Ihrer Knoten \u00fcbersteigt, wird die Ausf\u00fchrung dieses Pods nicht geplant. Im Gegensatz zu den Ressourcen des Prozessors kann der Speicher jedoch nicht komprimiert werden, da es keine M\u00f6glichkeit gibt, seine Nutzung zu begrenzen. Daher wird die Ausf\u00fchrung des Containers gestoppt, sobald er die ihm zugewiesene Speichermenge \u00fcberschreitet.<\/p>\n

\"Best
\n
\nEs ist wichtig, daran zu denken, dass Sie keine Anfragen einrichten k\u00f6nnen, die die Gr\u00f6\u00dfe der Ressourcen \u00fcberschreiten, die Ihre Knoten bereitstellen k\u00f6nnen. Die Eigenschaften der gemeinsamen Ressourcen f\u00fcr virtuelle Maschinen von GKE finden Sie in den Links unter diesem Video.<\/p>\n

In einer idealen Welt w\u00e4ren die Standard-Container-Einstellungen ausreichend, damit die Workflows reibungslos ablaufen. Aber die Realit\u00e4t sieht anders aus, denn Menschen vergessen leicht, die Ressourcennutzung zu konfigurieren, oder Hacker setzen Anfragen und Limits, die die tats\u00e4chlichen M\u00f6glichkeiten der Infrastruktur \u00fcberschreiten. Um die Entwicklung solcher Szenarien zu verhindern, k\u00f6nnen Sie Ressourcen-Quotas (ResourceQuota) und Limit-Bereiche (LimitRange) einrichten.<\/p>\n

Nach der Erstellung von Namespaces k\u00f6nnen diese durch Quotas abgesichert werden. Zum Beispiel, wenn Sie die Namespaces prod und dev haben, wird ein Muster verwendet, bei dem es keinerlei Quotas f\u00fcr die Produktionsumgebung gibt, w\u00e4hrend die Quotas f\u00fcr die Entwicklungsumgebung sehr streng sind. Dies erm\u00f6glicht es prod, bei einem pl\u00f6tzlichen Anstieg des Datenverkehrs alle verf\u00fcgbaren Ressourcen zu beanspruchen und dev vollst\u00e4ndig zu blockieren.<\/p>\n

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

\"Best
\n
\nLassen Sie uns jeden von ihnen betrachten. Requests.cpu ist die maximale Menge an kombinierten CPU-Anfragen, die von allen Containern des Namespaces kommen k\u00f6nnen. In diesem Beispiel k\u00f6nnen Sie 50 Container mit Anfragen von 10m, f\u00fcnf Container mit Anfragen von 100m oder einfach einen Container mit einer Anfrage von 500m haben. Solange die Gesamtzahl der requests.cpu dieses Namespaces unter 500m bleibt, ist alles in Ordnung.<\/p>\n

Der angeforderte Speicher requests.memory ist die maximale Summe der Speicheranfragen, die alle Container im Namespace haben k\u00f6nnen. Wie im vorherigen Fall k\u00f6nnen Sie 50 Container mit jeweils 2 MiB, f\u00fcnf Container mit jeweils 20 MiB oder einen einzelnen Container mit 100 MiB haben, solange die gesamte angeforderte Speichermenge im Namespace weniger als 100 MiB betr\u00e4gt.<\/p>\n

Limits.cpu ist der maximale kombinierte Wert der CPU-Leistung, die alle Container im Namespace verwenden k\u00f6nnen. Man kann sagen, dass dies das Limit f\u00fcr die CPU-Anfragen ist.<\/p>\n

Schlie\u00dflich ist limits.memory der maximale Gesamtbetrag an Arbeitsspeicher, den alle Container im Namensraum verwenden k\u00f6nnen. Diese Einschr\u00e4nkung bezieht sich auf die Gesamtanforderungen an den Arbeitsspeicher.
\nStandardm\u00e4\u00dfig arbeiten Container im Kubernetes-Cluster mit unbegrenzten Rechenressourcen. Mit Ressourcenkontingenten k\u00f6nnen Clusteradministratoren den Ressourcenverbrauch und deren Erstellung basierend auf dem Namensraum begrenzen. Im Namensraum kann ein Pod oder Container so viel CPU-Leistung und Arbeitsspeicher nutzen, wie im Ressourcenkontingent definiert. Es gibt jedoch Bedenken, dass ein Pod oder Container alle verf\u00fcgbaren Ressourcen monopolisiert. Um dies zu verhindern, wird ein Limit Range verwendet \u2013 eine Richtlinie zur Einschr\u00e4nkung der Ressourcenzuteilung (f\u00fcr Pods oder Container) im Namensraum.<\/p>\n

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