Als u met recente releases van IBM Maximo Application Suite (MAS) hebt gewerkt, bent u mogelijk een probleem tegengekomen waarbij de admin-build-config pod herhaaldelijk de status Evicted krijgt.

Op het eerste gezicht lijkt alles in orde. Het CPU-gebruik is laag, het geheugengebruik ziet er redelijk uit en de permanente opslag heeft voldoende beschikbare capaciteit. Toch blijft de pod falen en opnieuw opstarten, waardoor de MAS-omgeving niet kan worden opgebouwd.

Onlangs heb ik gemerkt dat dit probleem vaker voorkomt bij nieuwere MAS-releases, en in veel gevallen is de hoofdoorzaak helemaal geen CPU, geheugen of permanente opslag.

Het is tijdelijke opslag.

Tijdelijke opslag begrijpen

In tegenstelling tot permanente volumes bestaat tijdelijke opslag alleen gedurende de levensduur van de pod. Omdat het zich op het worker-knooppunt zelf bevindt, bewaakt Kubernetes het verbruik nauwlettend en kan het pods verwijderen wanneer geconfigureerde limieten worden overschreden.

Voor veel beheerders is tijdelijke opslag gemakkelijk over het hoofd te zien, omdat het doorgaans geen deel uitmaakt van routineuze capaciteitsbesprekingen. We richten ons op CPU, geheugen en PVC-dimensionering, maar build-workloads kunnen aanzienlijke hoeveelheden tijdelijke schijfruimte verbruiken.

Een veelvoorkomende oorzaak: Meerdere aanpassingsarchieven

Een patroon dat ik heb opgemerkt, is dat dit probleem het vaakst voorkomt in omgevingen met meerdere (of gewoon zeer grote) aanpassingsarchieven die zijn geconfigureerd voor implementatie.

Tijdens het admin-buildproces downloadt en extraheert MAS elk aanpassingsarchief voordat de inhoud aan de build wordt toegevoegd. Hoewel één enkel archief een minimale impact kan hebben, kunnen meerdere archieven de tijdelijke opslag aanzienlijk verhogen... en snel!

Wat veel beheerders verrast, is dat de benodigde ruimte vaak veel groter is dan de gecombineerde grootte van de ZIP-bestanden zelf. Tijdens extractie en verwerking worden tijdelijke bestanden aangemaakt en opgeslagen in de tijdelijke opslag van de pod. Naarmate het aantal en de grootte van aanpassingspakketten toenemen, neemt ook de behoefte aan tijdelijke opslag toe. Het bouwproces overschrijdt snel de geconfigureerde limiet voor tijdelijke opslag, wat resulteert in het verwijderen van de pod voordat deze is voltooid.

Symptomen

Wanneer tijdelijke opslag het probleem is, is Kubernetes heel expliciet hierover in de gebeurtenismeldingen. Als de admin-build-config pod de status 'Evicted' heeft, klik dan op het tabblad 'Events' en zoek naar een bericht zoals dit:
‍

‍

Het probleem oplossen

Wanneer de workload van de admin-build de standaardtoewijzing overschrijdt, zal het verhogen van de aanvraag en limiet voor tijdelijke opslag voor de Admin Build Config het probleem oplossen.
‍

Controleer uw huidige configuratie in de manageWorkspace Custom Resource Definition (CRD). De standaardwaarden (Out of the Box - OOTB) worden hieronder weergegeven:
‍

‍

In de documentationvan IBM, de manageWorkspace CRD kan naar verluidt worden bijgewerkt via de OpenShift Console UI door de sectie spec.settings.deployment.ephemeralStorage aan te passen. Pogingen om deze waarden via de UI bij te werken, waren echter niet succesvol. De configuratie viel herhaaldelijk terug naar de standaardinstellingen.
‍

De enige betrouwbare methode die ik vond, was om de wijziging toe te passen met een 'oc patch'-commando:
‍

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

‍
Nadat de patch is toegepast, laat u het reconciliatieproces voltooien. Zodra de reconciliatie is voltooid, wordt een nieuwe build-pod aangemaakt. Open de YAML van de admin-build-config pod en controleer of de bijgewerkte waarden voor tijdelijke opslag aanwezig zijn. Door in de YAML te zoeken naar de term 'ephemeral' kunt u eenvoudig bevestigen dat de wijzigingen succesvol zijn toegepast.
‍