Kubernetes 1.27: Bessere Speichermanagement-Funktionen für Ihre Container

Kubernetes v1.27, veröffentlicht im April 2023, bringt Verbesserungen im Bereich Memory QoS (alpha), die eine effizientere Speicherverwaltung auf Linux-Knoten ermöglichen.

Support für Memory QoS wurde ursprünglich in Kubernetes v1.22 eingeführt, wobei später einige Einschränkungen in Bezug auf die Berechnung von memory.high festgestellt wurden. Diese Einschränkungen wurden nun in Kubernetes v1.27 behoben.

Hintergrund

Kubernetes ermöglicht es Ihnen, optional anzugeben, wie viel von jeder Ressource ein Container in der Pod-Spezifikation benötigt. Die häufigsten Ressourcen sind CPU und Speicher.

Ein Beispiel für ein Pod-Manifest, das die Ressourcenanforderungen eines Containers definiert, könnte so aussehen:

apiVersion: v1
kind: Pod
metadata:
  name: example
spec:
  containers:
  - name: nginx
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "64Mi"
        cpu: "500m"

• spec.containers[].resources.requests

  Wenn Sie die Ressourcenanforderung für Container in einem Pod angeben, verwendet der Kubernetes-Scheduler diese Informationen, um zu entscheiden, auf welchem Knoten der Pod platziert wird. Der Scheduler stellt sicher, dass die Summe der Ressourcenanforderungen der geplanten Container für jeden Ressourcentyp geringer ist als die insgesamt zugewiesenen Ressourcen auf dem Knoten.

• spec.containers[].resources.limits

  Wenn Sie das Ressourcenlimit für Container in einem Pod festlegen, setzt der Kubelet diese Limits durch, sodass die laufenden Container nicht mehr dieser Ressourcen verwenden können, als Sie festgelegt haben.

Wenn der Kubelet einen Container als Teil eines Pods startet, übergibt er die Anforderungen und Limits für CPU und Speicher an die Container-Laufzeit. Die Container-Laufzeit weist sowohl dem CPU-Anforderungs- als auch dem CPU-Limitwert einen Container zu. Vorausgesetzt, das System hat freie CPU-Zeit, haben die Container Anspruch auf so viel CPU, wie sie anfordern. Container können jedoch nicht mehr CPU verwenden als das konfigurierte Limit, d.h. die CPU-Nutzung der Container wird gedrosselt, wenn sie mehr CPU verwenden als das angegebene Limit innerhalb eines bestimmten Zeitintervalls.

Vor der Einführung der Memory QoS-Funktion verwendete die Container-Laufzeit nur das Speicherkontingent und ignorierte die Speicheranforderung (Anforderungen wurden und werden weiterhin verwendet, um das Scheduling zu beeinflussen). Wenn ein Container mehr Speicher verwendet als das konfigurierte Limit, wird der Linux Out Of Memory (OOM) Killer aktiviert.

Vergleichen wir, wie die Container-Laufzeit unter Linux typischerweise die Speicheranforderung und das -limit in cgroups konfiguriert, mit und ohne die Memory QoS-Funktion:

• Speicheranforderung

  Die Speicheranforderung wird hauptsächlich vom Kube-Scheduler während der (Kubernetes) Pod-Scheduling verwendet. In cgroups v1 gibt es keine Kontrollen, um die Mindestmenge an Speicher anzugeben, die die cgroups immer behalten müssen. Daher verwendete die Container-Laufzeit den in der Pod-Spezifikation festgelegten Wert der angeforderten Speichermenge nicht.

  Cgroups v2 führte eine memory.min-Einstellung ein, die verwendet wird, um die Mindestmenge an Speicher anzugeben, die den Prozessen innerhalb einer bestimmten cgroup zur Verfügung stehen sollte. Wenn die Speichernutzung einer cgroup innerhalb ihrer effektiven Mindestgrenze liegt, wird der Speicher der cgroup unter keinen Umständen zurückgefordert. Wenn der Kernel nicht mindestens memory.min Bytes Speicher für die Prozesse innerhalb der cgroup aufrechterhalten kann, aktiviert der Kernel seinen OOM-Killer. Mit anderen Worten, der Kernel garantiert, dass mindestens dieser Speicher verfügbar ist oder beendet Prozesse (die möglicherweise außerhalb der cgroup liegen), um den Speicher verfügbarer zu machen. Memory QoS mappt memory.min auf spec.containers[].resources.requests.memory, um die Verfügbarkeit von Speicher für Container in Kubernetes-Pods sicherzustellen.

• Speicherlimit

  Das memory.limit gibt das Speicherlimit an, über das hinaus ein Container nicht mehr Speicher anfordern kann. Wenn der Container versucht, mehr Speicher zuzuweisen als das Limit, wird dies vom System entsprechend behandelt.

Durch die neuen Funktionen in Kubernetes 1.27 können Entwickler und DevOps-Teams jetzt die Speicherverwaltung ihrer Anwendungen optimieren. Dies führt zu einer besseren Ressourcennutzung und weniger Ausfällen durch den OOM-Killer. Nutzen Sie die Vorteile dieser neuen Funktionalitäten und gestalten Sie Ihre Kubernetes-Umgebungen effizienter. ayedo steht Ihnen als Partner für Kubernetes zur Seite, um Ihnen bei der Umsetzung dieser Neuerungen zu helfen.

Quelle: Kubernetes Blog