Kubernetes CPU-Drosselung: Der stille Killer der Reaktionszeit

Die Mehrheit der Unternehmen, die geschäftskritische Anwendungen auf Kubernetes betreiben, tun dies heute in Multi-Tenant-Umgebungen. Diese mandantenfähigen Umgebungen sind auf die Festlegung von Limits angewiesen, um den Verbrauch der Mandanten-Workloads zu regulieren oder um Limits für die Abrechnung zu verwenden. Einige Entwickler entscheiden sich dafür, CPU- oder GPU-Limits für Benchmark-Tests ihrer Anwendungen festzulegen.

CPU-Drosselung – bei der die Aufgabenplanungsrate auf den physischen CPU-Kernen unbeabsichtigt verringert wird, was oft zu einer unerwünschten Erhöhung der Reaktionszeit der Anwendung führt – ist die unbeabsichtigte Folge dieses Designs. Sehen Sie sich dieses Beispiel an:

In der obigen Abbildung beträgt die CPU-Auslastung eines Containers nur 25 %, was ihn zu einem idealen Kandidaten für eine Größenanpassung macht:

Aber nachdem wir die Größe des Containers verkleinert hatten (die CPU-Auslastung des Containers beträgt jetzt 50 %, ist immer noch nicht hoch), hat sich die Reaktionszeit vervierfacht.

Also, was passiert da? CPU-Drosselung tritt auf, wenn Sie ein CPU-Limit für einen Container konfigurieren, was umgekehrt die Reaktionszeit Ihrer Anwendung verlangsamen und ein Drosselungsproblem verursachen kann. Selbst wenn Sie über mehr als genug Ressourcen auf Ihrem zugrunde liegenden Knoten verfügen, wird die Container-Workload immer noch gedrosselt, da sie nicht richtig konfiguriert wurde. Darüber hinaus können die Auswirkungen der Drosselung auf die Leistung je nach zugrunde liegendem physischen Prozessor (Intel vs. AMD vs. NVIDIA) variieren. Die hohen Reaktionszeiten stehen in direktem Zusammenhang mit Perioden mit hoher CPU-Drosselung, und genau so wurde Kubernetes entwickelt.

Um dies zu verbessern, stellen Sie sich vor, Sie legen ein CPU-Limit von 200 ms fest und dieses Limit wird in eine Gruppenquote im zugrunde liegenden Linux-System übersetzt. Der Container kann jeweils nur 20 ms CPU nutzen (eine sogenannte CPU-Zeitscheibe), da der standardmäßige Erzwingungszeitraum nur 100 ms beträgt. Wenn Ihre Aufgabe länger als 20 ms dauert, werden Sie gedrosselt und es dauert 4x länger, bis Sie die Aufgabe abgeschlossen haben.

Aufgrund dieses Verhaltens leidet die Leistung der Anwendung aufgrund der durch die Drosselung verursachten längeren Reaktionszeit, und Sie beginnen mit der Fehlersuche, um das Problem zu finden.

Wenn Sie eine kleine Bereitstellung ausführen, können Sie möglicherweise manuell Fehler bei der Drosselung beheben.

Zuerst würden Sie den betroffenen Pod mithilfe von Tools wie kubectl identifizieren. Überprüfen Sie als Nächstes die Ressourcen und die Beschränkungen des Pod, um sicherzustellen, dass sie angemessen festgelegt sind. Suchen Sie nach ressourcenintensiven Prozessen, die im Container laufen und die Drosselung verursachen könnten, und analysieren Sie die CPU-Auslastung und die Grenzwerte.

Wenn die CPU-Drosselung weiterhin besteht, sollten Sie eine horizontale Pod-Autoskalierung in Betracht ziehen, um die Workload auf weitere Pods zu verteilen, oder die Knotenressourcen des Clusters anpassen, um den Anforderungen gerecht zu werden. Überwachen und Feinabstimmung Sie die Ressourcen kontinuierlich, um die Leistung zu optimieren und weitere Drosselungsprobleme zu vermeiden.

In einer größeren Bereitstellung wird dieser Ansatz wahrscheinlich nicht skalieren oder Bestand haben, wenn Sie weitere Pods hinzufügen.

Die CPU-Drosselung ist aufgrund der direkten Korrelation zwischen der Reaktionszeit und der CPU-Drosselung eine wichtige Metrik für die Leistung der Anwendung. Das ist eine großartige Neuigkeit für Sie, denn Sie können diese Metrik direkt von Kubernetes und OpenShift erhalten.

Um sicherzustellen, dass die Antwortzeiten Ihrer Anwendung niedrig bleiben, die CPU nicht gedrosselt wird und Sie weiterhin eine Anwendung mit hoher Leistung haben, müssen Sie zunächst verstehen, dass Sie sich bei einer CPU-Drosselung nicht allein auf die Auslastung der CPU-Kerne verlassen können. Sie müssen alle Analyse und Ressourcenabhängigkeiten berücksichtigen, die sich auf die Anwendung auswirken. IBM Turbonomic hat diese Überlegungen in seine Analyseplattform integriert.

Bei der Festlegung von Maßnahmen zur Korrektur von Containern analysiert Turbonomic kontinuierlich vier Dimensionen:

1. CPU-Grenzwerte
2. CPU-Anforderungen
3. Speicherbegrenzungen
4. Speicheranforderungen

Turbonomic kann die CPU-Grenzwerte bestimmen, die das Risiko einer Drosselung mindern und es Ihren Anwendungen ermöglichen, ungehindert zu laufen. Dies alles dank der Möglichkeit, die CPU-Drosselung als Dimension für die Plattform hinzuzufügen, um die auftretenden Kompromisse zu analysieren und zu verwalten. Das Hinzufügen der Dimension der CPU-Drosselung sorgt für niedrige Antwortzeiten der Anwendung.

Darüber hinaus generiert Turbonomic Aktionen zum Verschieben Ihrer Pods und zum Skalieren Ihrer Cluster – wie wir alle wissen, ist es eine Full-Stack-Herausforderung. Kunden haben die Möglichkeit, die KPIs zu sehen und zu fragen: „Welcher meiner Services wird gedrosselt?“ Es ermöglicht ihnen auch, den Verlauf der CPU-Drosselung für jeden Dienst zu verstehen und sich daran zu erinnern, dass jeder Dienst direkt mit der Reaktionszeit der Anwendung zusammenhängt, was den Benutzern wertvolle Einblicke in die Leistung ihres Systems bietet.

Im Kontext von Kubernetes ist einer der Hauptvorteile von Turbonomic seine Fähigkeit, unbeabsichtigte Folgen einer Strategie schnell zu erkennen und zu beheben, anstatt den Kunden seine Multi-Tenant-Strategie überarbeiten zu lassen. Turbonomic kann nicht nur Metriken zur CPU-Drosselung überwachen, sondern die Plattform kann auch Ihr CPU-Limit automatisch richtig dimensionieren und die Drosselung auf ein handhabbares Niveau senken.

IBM Turbonomic kann Ihnen helfen, gleichzeitig Ihre Cloud-Ausgaben und -Leistung zu optimieren. Optimierungsmaßnahmen können kontinuierlich in Echtzeit – und ohne menschliches Eingreifen – automatisieren und damit proaktiv die effizienteste Nutzung von Rechen-, Arbeitsspeicher-, Speicher- und Netzwerkressourcen für Ihre Apps auf jedem Stack-Ebene ermöglichen.