Auf einen Blick: Kubernetes-Rechenressourcen verwalten CPU- und Speicherzuweisungen für Pods und sorgen so für eine effiziente Ressourcennutzung. Dieser Leitfaden beschreibt Ressourcenanfragen, Limits und Quality of Service (QoS)-Klassen, um die Anwendungsleistung aufrechtzuerhalten.
- Rechenressourcen umfassen messbare CPU und Speicher für Pods.
- QoS-Klassen priorisieren die Kapselbeseitigung basierend auf der Ressourcenverfügbarkeit.
In der Kubernetes-Welt gibt es zwei Arten von Ressourcen:
- Rechenressourcen wie CPU (Einheiten) und Speicher (Bytes), die gemessen werden können.
- API-Ressourcen wie Pods, Services usw., die einfach K8s-Objekte sind.
In diesem Artikel werde ich Rechenressourcen erklären.
Qualität der Dienstleistung (QoS)
Standardmäßig verbrauchen die Pod-Container beim Deployen eines Pods im Grunde alle verfügbaren Rechenressourcen auf der Worker-Node-Instanz. Das ist großartig – dann müssen wir uns um nichts Sorgen machen, oder?
Was passiert, wenn einer der Container mehr CPU- und Speicherressourcen verbraucht als andere? Was passiert mit den anderen Pod-Containern, die auf dem Knoten laufen? Es besteht eine hohe Wahrscheinlichkeit, dass einige der Container aufgrund fehlender Ressourcen ausfallen; wenn wir eine Anwendung mit einer schlechten Codebasis ausführen, kann das Auswirkungen auf das Geschäft haben.
Um dieses Problem zu lösen, hat Kubernetes Resource Requests und Limits, die helfen, die Menge an Ressourcen zu kontrollieren, die ein Pod-Container verbraucht, um das höchste Niveau an Servicequalität (QoS) zu gewährleisten. Es ist wichtig zu betonen, dass QoS (Anfragen und Limits) auch für Namespaces angewendet werden können, nicht nur für Pods. So können Sie, wenn mehrere Entwicklerteams auf einem Cluster deployen, den Ressourcenverbrauch je nach Priorität des Services steuern.
Wie Ressourcenanforderung und -begrenzung funktionieren
Grundsätzlich weist ein Worker-Node oder eine Instanz nur einen bestimmten Teil seiner Gesamtrechenressourcen für Pods zu, sodass dieser Teil zwischen allen auf diesem Node geplanten Pods geteilt wird. Der Kubernetes-Scheduler stellt sicher, dass die Summe aller Rechenressourcen der auf der Instanz laufenden Container nicht die insgesamt zugewiesene Ressource für Pods übersteigt. Es ist wichtig, den Unterschied zwischen Request und Limit zu kennen.
- Die Anfrage ist, wie viele Ressourcen Kubernetes einem Pod garantiert.
- Das Limit ist die maximale Ressourcenmenge, die Kubernetes einem Pod erlaubt.
Beachten Sie, dass Pod-Scheduling auf Anfrage basiert, nicht auf Limit, aber ein Pod und seine Container dürfen das angegebene Limit nicht überschreiten. Wenn Sie einen Pod einsetzen, bestimmt eine Kapazitätskontrolle, ob die gesamte angeforderte Rechenressourcenmenge nicht größer ist als das, was der Knoten zuweisen kann.
Wie Anträge und Beschränkungen durchgesetzt werden
Wie die Anfrage und das Limit durchgesetzt werden, hängt davon ab, ob die Ressource komprimierbar oder nicht komprimierbar ist. Eine komprimierbare Ressource kann gedrosselt werden, aber eine beeindruckbare Ressource – nicht so sehr. Zum Beispiel gilt die CPU als komprimierbar und der Speicher als unkomprimierbar.
Pods erhalten garantiert die angeforderte CPU-Menge; sie können je nach laufenden anderen Pods mehr CPU bekommen, und alles, was das Limit überschreitet, wird gedrosselt. Pod-Speicheranfragen sind ebenfalls garantiert, aber wenn Pods das Speicherlimit überschreiten, wird der Prozess im Container, der den meisten Speicher verbraucht, beendet. Der Pod wird nicht beendet, aber der Prozess im Container, der den Speicher verwendet, wird beendet.
Es gibt Zeiten, in denen ein Knoten komplett ohne Rechenressourcen ist; die Summe aller laufenden Container-Rechenressourcen ist größer als die Rechenressourcen auf dem Knoten selbst. In extremen Fällen wie diesem müssen wir anfangen, laufende Container auf dem Knoten zu töten. Idealerweise entfernen wir zuerst weniger kritische Container, um Ressourcen freizumachen. Wie sagen wir Kubernetes, welcher Pod zuerst gehen muss, wenn alle Ressourcen auf dem Knoten erschöpft sind? Durch die Verwendung von QoS-Klassen.
Wir können drei Arten von Klassen festlegen – Best Effort, Guaranteed und Burstable –, um dem System zu sagen, welche Pods zuerst terminiert werden soll.
- Beste Bemühung. Pods ohne Anfrage oder Limit, die zuerst beendet werden, falls die Ressourcen erschöpft sind.
Containers:
name: foo
Resources:
name: bar
resources:
- Garantiert. Pods, bei denen sowohl Limit als auch (optional) Anfrage sind, sind für alle Ressourcen (CPU und Speicher) eingestellt und ihre Werte sind gleich. Diese Pods haben hohe Priorität, daher werden sie nur dann beendet, wenn sie das Limit überschreiten und keine Pods mit niedrigerer Priorität zu beenden sind.
containers:
name: pong
resources:
limits:
cpu: 100m
memory: 100Mi
requests:
cpu: 100m
memory: 100Mi
- Burstbar. Pods, bei denen sowohl Anfrage- als auch (optional) Limits für eine oder mehrere Ressourcen (CPU und/oder Speicher) gesetzt sind und deren Werte NICHT gleich sind. Diese Pods werden beendet, wenn es keine Best-Effort-Pods zum Terminieren gibt.
containers:
name: foo
resources:
limits:
memory: 1Gi
name: bar
resources:
limits:
cpu: 100m
Da Anwendungs-Uptime Teil von Geschäfts-SLAs ist, ist es wichtig, ausreichende Ressourcen für diese Anwendungen bereitzustellen. Zu verstehen, wie diese Ressourcen richtig geplant werden, ist für das Geschäft entscheidend. Die Nutzung von Anfragen und Limits hilft dem Team, Ressourcen korrekt auf kritische Anwendungen zuzuweisen, und QoS hilft, den Lebenszyklus der Anwendung im Falle einer Ressourcenerschöpfung am Worker-Knoten zu kontrollieren. Teams können diese Anfragen und Limits auch auf Namespace-Ebene definieren, sodass Ressourcen basierend auf Entwicklungsteams zugeschnitten werden können.
Kubernetes-Leitfaden
- Was ist Kubernetes (K8s)? Ein Tutorial zu den Grundlagen von Kubernetes
- Kubernetes Best Practices für verbesserte Cluster-Effizienz
- Best Practices: Wie man Anwendungen für Kubernetes architekt
- Kubernetes Pods: Eine Einführung
- Kubernetes ReplicaSets: Eine kurze Einführung
- Kubernetes-Deployments vollständig erklärt
- Wie man Kubernetes DaemonSets verwendet und verwaltet
- Wie Kubernetes-Dienste funktionieren
- Verwendung von Kubernetes Port, TargetPort und NodePort
- Erstellen und verwenden von ConfigMaps in Kubernetes
- Einführung in Kubernetes-Geheimnisse
- Kubernetes-Netzwerkgrundlagen
- Kubernetes-Ingress erklärt
- Einführung in Kubernetes Helm Charts
- Was ist das Kubernetes-Operator-Muster?
- Bereitstellung von PostgreSQL als StatefulSet in Kubernetes
- Kubernetes Custom Resource Definition (CRDs) erklärt
- 3 Kubernetes-Muster für Cloud-native Anwendungen
- Kubernetes Compute-Ressourcen erklärt
- Kubernetes-Sicherheit für DevOps-Pipelines
- Verwendung von Spinnaker mit Kubernetes für Continuous Delivery
- Kubernetes-Multi-Cluster: Wie und warum man sie verwendet.
- Kubernetes-Überwachung: Ein umfassender Leitfaden
- Kubernetes vs. Docker: Ein kurzer Vergleich
- Kubernetes vs. Docker Swarm: Vergleich von Container-Orchestrierungstools
- Kubernetes vs. OpenShift: Was ist der Unterschied?
- Kubernetes-Zertifizierungen: Wie und warum man zertifiziert wird
Diese Beiträge sind meine eigenen und spiegeln nicht unbedingt die Position, Strategien oder Meinung von BMC wider.