3 häufige Troubleshooting-Aufgaben in Kubernetes meistern
Brauchen Sie mehr Knoten? Noisy Neighbours in der Cloud? Mangelnde Performance von Containern kann viele Gründe haben. Wir erklären, wie Sie drei häufige Probleme lösen.
Das Beheben von Fehlern in Kubernetes kann zur Herausforderung werden. Wenn ein Cluster nicht verfügbar ist, oder ein Pod nicht reagiert wie erwartet, bemerkt man das recht schnell. Was jedoch länger dauern kann, ist die Ursache dafür zu finden.
Im Folgenden stellen wir drei häufige Fehler in Kubernetes vor und zeigen, wie Administratoren und DevOps-Teams die Ursachen finden und das Problem lösen können.
1. Nicht verfügbare Knoten
Hohe Verfügbarkeit ist bei vielen Anwendungen ein wichtiges Anliegen. Dafür muss Kubernetes Anwendungen auf eine Vielzahl von Knoten (Nodes) also physische oder virtuelle Server verteilen, welche die Host-Infrastruktur für einen Kubernetes-Cluster bilden. Wenn Sie feststellen, dass die Verfügbarkeit der Anwendungen auf Ihrem Kubenetes-Cluster zu wünschen übrig lässt, dann könnte es daran liegen, dass Sie nicht genügend Knoten im Cluster haben.
Um dieses Problem zu beheben, stellen Sie zunächst sicher, dass dem Cluster genügend Knoten zugewiesen haben. Als Faustregel gilt, dass ein für Hochverfügbarkeit ausgelegter Cluster aus mindestens zwei Dutzend Knoten bestehen sollte. Zwei oder mehr davon sollten Masterknoten sein.
Ein anderer Grund für eine zu geringe Zahl an Knoten ist, dass sie zwischenzeitlich ausgefallen sind. Ist das der Fall, sollte man zunächst die Host-VMs (virtuelle Maschinen) dieser Knoten neustarten. Die meisten Anbieter von VM-Plattformen für die Cloud oder On-Premises bieten im Rahmen ihrer Managementsoftware für Kubernetes Wiederherstellungsfunktionen, mit denen sich ausgefallene Server automatisch neu starten lassen.
Eine Erhöhung der Anzahl der physischen Server in einem Cluster kann auch die Knotenverfügbarkeit verbessern, selbst wenn die Anzahl der Knoten gleichbleibt. Wenn man die Knoten auf mehr physische Server verteilt, begrenzt man damit den Schaden, der dem Cluster durch einen Serverausfall entsteht.
Abbildung 1: Aufbau eines Kubernetes-Clusters
2. Laute Nachbarn
Das so genannte Noisy-Neighbour-Problem entsteht, wenn eine Anwendung Ressourcen in einer Weise in Beschlag nimmt, die anderen Anwendungen die notwendigen Ressourcen entzieht. Es tritt häufig auf bei Kubernetes-Clustern mit mehreren Mandanten.
Kubernetes ist zwar darauf ausgelegt, alle Anwendungen mit ausreichend Ressourcen zu versorgen, jedoch enthalten die Kubernetes-Konfigurationsdateien nicht immer die Details, die der Scheduler benötigt, um das zu gewährleisten. Kubernetes hat keine Möglichkeit, den Anwendungscode automatisch auszulesen, um festzulegen, wie viel Rechen-, Speicher- oder andere Ressourcen eine Anwendung zu einem bestimmten Zeitpunkt benötigt. Es kann nur auf der Grundlage der Einstellungen handeln, die in Kubernetes-Konfigurationsdateien angegeben sind.
Um Probleme mit lauten Nachbarn zu beheben, sollte man zunächst sicherstellen, dass die Konfigurationsdateien entsprechend aufgesetzt sind, dass jeder Workload die richtige Menge an Ressourcen bekommt. Admins können dies auf der Ebene einzelner Container oder Pods durch das Festlegen von Grenzbereichen erreichen. Dabei geben sie die maximalen Ressourcen an, die ein Container oder Pod verbrauchen darf.
Das richtige Einsetzen von Namensräumen (Namespaces) ist ebenfalls hilfreich, um Probleme mit lauten Nachbarn zu beheben. Man verwendet Namespaces, um ein einzelnes Cluster in verschiedene virtuelle Räume zu unterteilen.
Das Tool Ressource Quotas kann die Menge der Ressourcen, die ein einzelner Namensraum verbrauchen kann, begrenzen und so dazu beitragen, dass ein Namensraum nicht mehr Ressourcen belegt, als vorgesehen. Dabei gilt es zu beachten, dass Ressourcenquoten für einen gesamten Namensraum gelten; sie können nicht das Verhalten einzelner Anwendungen innerhalb desselben Namensraums steuern. Dafür verwendet man das Tool Limit Ranges.
3. Container antworten nicht
In einem Cluster, das genug Knoten hat und mit Ressource Quotas sowie Limit Ranges konfiguriert ist, kann es trotzdem zu mangelhaften Antwortzeiten für Container oder Pods kommen. Das liegt normalerweise daran, dass die Liveness- und Readiness-Prüfungen nicht richtig konfiguriert sind.
Das richtige Einsetzen von Namensräumen (Namespaces) ist ebenfalls hilfreich, um Probleme mit lauten Nachbarn in Kubernetes-Clustern zu beheben.
Kubernetes verwendet Liveness, um zu prüfen, ob ein Container erreichbar ist. Ist dies nicht der Fall, startet Kubernetes den Container neu. Readiness stellt fest, ob ein Container oder eine Gruppe von Containern betriebsbereit ist und bereit, um Traffic zu verarbeiten.
Im Allgemeinen verhindern diese beiden Tools, dass Admins einen Container mit einer Fehlfunktion manuell neustarten müssen oder dass ein Container unbemerkter Weise noch nicht vollständig initialisiert und daher noch nicht bereit ist, Anfragen zu bearbeiten.
Überaktive Liveness- und Readiness-Tools können jedoch, paradoxerweise, Schuld daran sein, dass ein Container nicht verfügbar ist. Angenommen, das Liveness-Tool testet den Container jede Sekunde und startet ihn neu, wenn er nicht antwortet, durch Netzwerküberlastung oder Latenzprobleme dauert die Bereitschaftsprüfung jedoch länger als eine Sekunde. Das würde dazu führen, dass Liveness den Container ohne Unterlass neu startet, so dass er nicht mehr verfügbar ist.
Um dies zu verhindern, sollte man Liveness- und Readiness-Tests so konfigurieren, dass es für die vorliegende Container und Umgebungsvariablen sinnvoll ist. Sehr wahrscheinlich benötigt jeder Container seine eigenen Richtlinien.
