Si vous avez travaillé avec les versions récentes d'IBM Maximo Application Suite (MAS), vous avez peut-être rencontré un problème où le pod admin-build-config passe de manière répétée à l'état " Evicted état.

À première vue, tout semble sain. L'utilisation du CPU est faible, l'utilisation de la mémoire semble raisonnable et le stockage persistant dispose de beaucoup de capacité disponible. Pourtant, le pod continue d'échouer et de redémarrer, empêchant l'environnement MAS de se déployer.

Récemment, j'ai constaté que ce problème devenait plus courant dans les versions plus récentes de MAS, et dans de nombreux cas, la cause première n'est pas du tout le CPU, la mémoire ou le stockage persistant.

C'est le stockage éphémère.

Comprendre le stockage éphémère

Contrairement aux volumes persistants, le stockage éphémère n'existe que pendant la durée de vie du pod. Comme il réside sur le nœud de travail lui-même, Kubernetes surveille de près la consommation et peut expulser les pods lorsque les limites configurées sont dépassées.

Pour de nombreux administrateurs, le stockage éphémère est facile à négliger car il ne fait généralement pas partie des discussions de routine sur la capacité. Nous nous concentrons sur le CPU, la mémoire et le dimensionnement des PVC, mais les charges de travail de construction peuvent consommer des quantités importantes d'espace disque temporaire.

Un déclencheur courant : plusieurs archives de personnalisation

Un schéma que j'ai remarqué est que ce problème se produit le plus fréquemment dans les environnements où plusieurs (ou de très grandes) archives de personnalisation sont configurées pour le déploiement.

Pendant le processus de construction admin, MAS télécharge et extrait chaque archive de personnalisation avant d'ajouter le contenu à la construction. Bien qu'une seule archive puisse avoir un impact minimal, plusieurs archives peuvent augmenter considérablement la consommation de stockage temporaire... et rapidement !

Ce qui surprend de nombreux administrateurs, c'est que l'espace requis est souvent bien plus grand que la taille combinée des fichiers ZIP eux-mêmes. Lors de l'extraction et du traitement, des fichiers temporaires sont créés et stockés dans le stockage éphémère du pod. À mesure que le nombre et la taille des paquets de personnalisation augmentent, les besoins en stockage temporaire augmentent également. Le processus de construction dépasse rapidement la limite de stockage éphémère configurée, entraînant l'expulsion du pod avant son achèvement.

Symptômes

Lorsque le stockage éphémère est en cause, Kubernetes est très explicite à ce sujet dans les messages d'événement. Si le pod admin-build-config est à l'état "Evicted", cliquez sur l'onglet Événements et recherchez un message comme celui-ci :
‍

‍

Résolution du problème

Lorsque la charge de travail de construction de l'administrateur dépasse l'allocation par défaut, l'augmentation de la demande et de la limite de stockage éphémère pour la configuration de construction de l'administrateur (Admin Build Config) résoudra le problème.
‍

Vérifiez votre configuration actuelle dans la manageWorkspace Définition de ressource personnalisée (CRD). Les valeurs par défaut prêtes à l'emploi (OOTB) sont affichées ci-dessous :
‍

‍

Dans la documentationd'IBM, le manageWorkspace Les CRD peuvent censément être mis à jour via l'interface utilisateur de la console OpenShift en modifiant la section spec.settings.deployment.ephemeralStorage. Cependant, les tentatives de mise à jour de ces valeurs via l'interface utilisateur ont échoué. La configuration revenait systématiquement aux paramètres par défaut.
‍

La seule méthode fiable que j'ai trouvée a été d'appliquer la modification à l'aide d'une commande oc patch :
‍

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

‍
Après avoir appliqué le patch, laissez le processus de réconciliation se terminer. Une fois la réconciliation terminée, un nouveau pod de build sera créé. Ouvrez le fichier YAML du pod admin-build-config et vérifiez que les valeurs de stockage éphémère mises à jour sont présentes. Rechercher le terme « ephemeral » dans le fichier YAML permet de confirmer facilement que les modifications ont été appliquées avec succès.
‍