Fehlerhafte CPU-Quota-Berechnung durch containerd beim 4096m Limit

Fehlerhafte CPU-Quota-Berechnung durch containerd bei 4096m Limit

Die CPU-Quota-Berechnung von containerd bei der Verwendung des Systemd-cgroup-Treibers verursacht derzeit signifikante Probleme beim Erstellen von Containern, speziell beim Setzen eines CPU-Limits von 4096m. Diese Problematik führt zu einer unregelmäßigen Fehlfunktion, da die Berechnung sowohl korrekt als auch fehlerhaft durchgeführt wird, was den Prozess der Containererstellung behindert.

Unterschiedliche Berechnungen zwischen containerd und runc

Während containerd für die Umrechnung von 4096m in Mikrosekunden teils unterschiedliche Werte berechnet, bleibt die Berechnung durch runc konstant. Containerd hat die Tendenz, entweder den Wert 409600 oder 410000 Mikrosekunden zu erzeugen. Diese zwei unterschiedlichen Ergebnisse entstehen dadurch, dass containerd je nach Situation entweder korrekt den Wert von 409600 (das Ergebnis der Rechnung \\(4.096 \\times 100000\\)) oder einen gerundeten Wert von 410000 (basierend auf \\(4.1 \\times 100000\\)) berechnet. Im Gegensatz dazu berechnet runc durchgängig den Wert von 410000 Mikrosekunden mit einer Rundung auf 4.1. Diese unterschiedliche Vorgehensweise der beiden Systeme führt dazu, dass bei einer Diskrepanz seitens des Linux-Kernels der Versuch der Containenerstellung mit der Meldung „invalid argument“ abgelehnt wird Quelle.

Auswirkungen auf die Pod-Erstellung

Die Problematik tritt insbesondere auf zuvor genutzten Knoten auf, da containerd dort manchmal 409600 Mikrosekunden berechnet und dieser Wert dann in der Hierarchie des Containers bleibt. Die Anwendung bleibt mit dem geringeren Quotenwert eingefroren, während runc versucht, den höheren Wert von 410000 Mikrosekunden zu schreiben, was zur Ablehnung durch den Kernel führt. Dies bedeutet, dass nachfolgenden Versuche, Pods auf diesen Knoten zu erstellen, aus dem gleichen Grund scheitern Quelle.

Nicht-deterministisches Verhalten und mögliche Lösungsansätze

Das nicht-deterministische Verhalten von containerd bei der Berechnung des CPU-Quotas ist ein zentraler Punkt der Problematik. Dieses Verhalten ist nicht an eine spezifische Version gebunden, da dieselbe containerd-Version inkonsistente Ergebnisse liefert. Als Kernfrage bleibt, ob containerd und runc eine geteilte Umrechnungslogik nutzen sollten, um Konsistenz in den Ergebnissen zu gewährleisten.

Diese Inkonsistenz ist den Änderungen von CPU-Limits geschuldet, besonders bei dem Wechsel von 8192m auf 4096m, was bei fractional core values zu beobachten ist Quelle. Eine tiefere Analyse der containerd-Codebasis könnte zeigen, wo genau diese Umrechnungen geschehen, und ob es Möglichkeit gibt, das Verhalten zu standardisieren.

Fazit

Die Problematik der nicht-deterministischen CPU-Quota-Berechnung durch containerd illustriert die Herausforderungen, die bei der Nutzung von container-basierten Umgebungen auftreten können, speziell wenn verschiedene Systemegranular zusammenarbeiten müssen. Eine Harmonisierung der Umrechnungslogiken könnte helfen, solche Inkonsistenzen künftig zu vermeiden und die Stabilität von Container-Deployments zu erhöhen.