Dépannage

Une plateforme dont les sondes sont vertes peut très bien ne jamais exécuter un run.

C’est la phrase à garder en tête : la plupart des pannes de première installation ne se voient pas dans un kubectl get pods. Cette page liste celles qui ont réellement été rencontrées, avec le symptôme exact plutôt qu’une catégorie générique.

1. L’API refuse de démarrer, et dit pourquoi

Symptôme : le pod de l’API s’arrête avant d’écouter, avec un message qui nomme une variable.

C’est voulu. Un conteneur d’initialisation vérifie les clés obligatoires avant le démarrage et échoue en les nommant — il ne nomme jamais leur valeur. Il refuse aussi une clé présente mais littéralement vide ou égale à <no value>, qui est ce que produit un gabarit non substitué.

Correction : poser la clé nommée dans le message. Ne pas contourner le garde-fou : il vous évite une plateforme qui démarre et échoue plus tard, plus loin, sans rapport apparent.

2. La création d’un locataire échoue en erreur de configuration

Symptôme : la création d’un locataire renvoie une erreur de configuration du locataire, alors que la plateforme tourne.

Cause : l’adresse interne du stockage objet n’est pas configurée. L’application a besoin de joindre le stockage depuis l’intérieur du cluster, sous un nom qui peut différer de l’adresse publique.

3. Le jeton est rejeté alors que l’authentification fonctionne

Symptôme : la connexion aboutit dans le navigateur, mais l’API rejette le jeton.

Cause : l’adresse publique de l’émetteur et l’adresse interne divergent. Le jeton porte l’émetteur vu par le navigateur ; l’API le compare à celui qu’elle connaît. Les deux doivent désigner le même émetteur.

4. Les runs échouent en silence

Symptôme : la plateforme répond, les sondes sont vertes, un run part — et n’aboutit jamais, sans message utile.

Cause : l’URL interne de l’API n’est pas configurée. Le workload lancé doit pouvoir rappeler la plateforme pour signaler son avancement ; sans cette adresse, il s’exécute dans le vide.

C’est la panne la plus coûteuse de la liste, parce que tous les signaux visibles sont au vert. Si un run ne remonte rien, vérifier cette variable avant toute autre chose.

Avant d’ouvrir un ticket

Trois vérifications qui règlent la majorité des cas :

Le conteneur d’initialisation est-il passé ? S’il a échoué, il nomme la clé en cause.
Les adresses internes (stockage objet, API, émetteur d’authentification) sont-elles renseignées et joignables depuis l’intérieur du cluster ?
Le stockage objet et le registre d’images sont-ils accessibles depuis le namespace d’exécution, et pas seulement depuis celui de la plateforme ?