Une écriture est refusée et ce n'est pas votre requête

Symptom

Une écriture de déploiement est refusée avec le code registry_credential_store_unavailable, et le message indique que le plan de contrôle n’a pas pu résoudre les identifiants du registre. Rien dans la requête n’est incorrect, et aucune modification du spec ne la fera réussir — le même corps sera accepté une fois que la plateforme sera à nouveau saine.

C’est la plateforme qui signale un défaut en elle-même plutôt que de juger ce que vous avez envoyé. Il est utile de connaître la différence à première vue : image_not_found signifie que le registre a répondu et que l’image n’y est pas, ce que vous pouvez corriger. Ce code signifie que le registre n’a jamais été interrogé, car le plan de contrôle n’a pas trouvé les identifiants pour le faire.

Diagnose

Confirmez que c’est la plateforme et non l’image. Lisez le code, pas le texte. image_not_found est une image confirmée absente. registry_credential_store_unavailable est le plan de contrôle qui dit qu’il n’a pas pu vérifier.
Interrogez le plan de contrôle sur lui-même. GET /healthz répond en une ligne : il signale consul not configured lorsque le plan de contrôle a démarré sans client de stockage clé-valeur du tout, et consul unhealthy avec le détail sous-jacent lorsqu’il en avait un et l’a perdu. Ce sont des défauts différents avec des correctifs différents, c’est pourquoi le point de terminaison les distingue.
Pour plus qu’un verdict, GET /api/v1/cluster/health décompose la plateforme en composants et donne au stockage clé-valeur son propre statut — unavailable avec « Consul client not configured », ou unhealthy avec « Consul is disconnected ». Un administrateur de plateforme peut le lire ; c’est la même vue que le rend l’état du cluster du tableau de bord.
Si c’est not configured, l’adresse avec laquelle le plan de contrôle a été démarré est la chose à vérifier — ODYSSEUS_CONSUL_ADDRESS, ou le paramètre consul.address qu’elle remplace. Un plan de contrôle qui a démarré sans une ne l’acquiert pas plus tard de lui-même.
Si c’est disconnected, le stockage est configuré et injoignable maintenant : vérifiez que le conteneur Consul est en cours d’exécution et que le plan de contrôle peut l’atteindre à l’adresse qui lui a été donnée. Un redémarrage du stockage seul n’est pas une preuve suffisante que le plan de contrôle s’est reconnecté — relisez /healthz ensuite plutôt que de le supposer.

Resolve

En tant qu’appelant : rien, et c’est la réponse honnête. Réessayez la requête identique une fois que la plateforme signale un état sain. Rien n’a été écrit, il n’y a donc pas de modification partiellement appliquée à annuler et aucun conteneur n’a été perturbé.
En tant qu’opérateur, non configuré : définissez l’adresse du magasin de clés-valeurs dans la configuration du plan de contrôle et redémarrez-le. Ne contournez pas cela en désactivant la vérification d’image — la vérification existe car une écriture admise sans celle-ci détruit un conteneur sain et découvre ensuite seulement que l’image ne peut pas être récupérée.
En tant qu’opérateur, déconnecté : restaurez le magasin, puis confirmez que le plan de contrôle le voit à nouveau sur /healthz avant de dire à qui que ce soit que la plateforme est de retour. Le refus s’efface de lui-même une fois que la connexion est réelle.

Prevent

Surveillez le composant de stockage clé-valeur de l’état du cluster, pas seulement le fait que le processus du plan de contrôle soit actif. Un plan de contrôle dans cet état répond aux lectures, sert le tableau de bord et semble entièrement vivant tout en refusant chaque écriture de déploiement — donc « le service est en cours d’exécution » n’est pas une preuve que quelqu’un peut déployer.