Wenn Sie mit neueren Versionen der IBM Maximo Application Suite (MAS) gearbeitet haben, ist Ihnen möglicherweise ein Problem begegnet, bei dem der admin-build-config Pod wiederholt in den Status „ Evicted “ wechselt.

Auf den ersten Blick scheint alles in Ordnung zu sein. Die CPU-Auslastung ist gering, die Speichernutzung sieht vernünftig aus und der persistente Speicher verfügt über ausreichend freie Kapazität. Dennoch fällt der Pod immer wieder aus und startet neu, wodurch die MAS-Umgebung nicht aufgebaut werden kann.

In letzter Zeit habe ich beobachtet, dass dieses Problem bei neueren MAS-Versionen häufiger auftritt, und in vielen Fällen liegt die Ursache überhaupt nicht in CPU, Arbeitsspeicher oder persistentem Speicher.

Es ist der ephemere Speicher.

Ephemeren Speicher verstehen

Im Gegensatz zu persistenten Volumes existiert ephemerer Speicher nur für die Lebensdauer des Pods. Da er sich auf dem Worker-Knoten selbst befindet, überwacht Kubernetes den Verbrauch genau und kann Pods entfernen, wenn die konfigurierten Grenzwerte überschritten werden.

Für viele Administratoren ist ephemerer Speicher leicht zu übersehen, da er normalerweise nicht Teil routinemäßiger Kapazitätsdiskussionen ist. Wir konzentrieren uns auf CPU, Arbeitsspeicher und PVC-Dimensionierung, aber Build-Workloads können erhebliche Mengen an temporärem Speicherplatz verbrauchen.

Ein häufiger Auslöser: Mehrere Anpassungsarchive

Ein Muster, das mir aufgefallen ist, ist, dass dieses Problem am häufigsten in Umgebungen auftritt, in denen mehrere (oder einfach sehr große) Anpassungsarchive für die Bereitstellung konfiguriert sind.

Während des Admin-Build-Prozesses lädt MAS jedes Anpassungsarchiv herunter und entpackt es, bevor der Inhalt in den Build integriert wird. Während ein einzelnes Archiv nur minimale Auswirkungen haben mag, können mehrere Archive den temporären Speicherverbrauch erheblich erhöhen... und das schnell!

Was viele Administratoren überrascht, ist, dass der benötigte Speicherplatz oft viel größer ist als die Gesamtgröße der ZIP-Dateien selbst. Während der Extraktion und Verarbeitung werden temporäre Dateien im ephemeren Speicher des Pods erstellt und abgelegt. Mit zunehmender Anzahl und Größe der Anpassungspakete steigt auch der Bedarf an temporärem Speicherplatz. Der Build-Prozess überschreitet schnell die konfigurierte Grenze für den ephemeren Speicher, was zur Entfernung des Pods führt, bevor er abgeschlossen ist.

Symptome

Wenn der ephemere Speicher das Problem ist, ist Kubernetes sehr explizit in den Ereignismeldungen. Wenn sich der admin-build-config-Pod im Status „Evicted“ befindet, klicken Sie auf die Registerkarte „Events“ und suchen Sie nach einer Meldung wie dieser:
‍

‍

Problembehebung

Wenn die Admin-Build-Workload die Standardzuweisung überschreitet, wird das Problem durch Erhöhen der Anforderung und des Limits für den ephemeren Speicher für die Admin Build Config behoben.
‍

Überprüfen Sie Ihre aktuelle Konfiguration in der manageWorkspace Custom Resource Definition (CRD). Die Standardwerte (Out of the Box, OOTB) sind unten aufgeführt:
‍

‍

In der IBM- Dokumentationwird die manageWorkspace CRD kann angeblich über die OpenShift Console-Benutzeroberfläche durch Änderung des Abschnitts spec.settings.deployment.ephemeralStorage aktualisiert werden. Versuche, diese Werte über die Benutzeroberfläche zu aktualisieren, waren jedoch erfolglos. Die Konfiguration wurde wiederholt auf die Standardeinstellungen zurückgesetzt.
‍

Die einzige zuverlässige Methode, die ich gefunden habe, war, die Änderung mittels eines oc patch-Befehls anzuwenden:
‍

oc patch manageworkspace a311833-mas -n mas-a311833-manage --type='merge' -p '{"spec":{"settings":{"deployment":{"ephemeralStorage":{"limits":{"adminBuild":"200Gi"},"requests":{"adminBuild":"50Gi"}}}}}}' 

‍
Nachdem der Patch angewendet wurde, lassen Sie den Abgleichprozess abschließen. Sobald der Abgleich abgeschlossen ist, wird ein neuer Build-Pod erstellt. Öffnen Sie die YAML-Datei für den admin-build-config Pod und überprüfen Sie, ob die aktualisierten Werte für den ephemeren Speicher vorhanden sind. Die Suche nach dem Begriff „ephemeral“ in der YAML-Datei erleichtert die Bestätigung, dass die Änderungen erfolgreich angewendet wurden.
‍