Aller au contenu

Un déploiement ne quitte jamais la planification

Symptom

Le déploiement a été accepté — il existe, GET /api/v1/deployments/{name} le renvoie — et aucun conteneur n’apparaît jamais. Le nombre de réplicas reste à zéro et aucun nœud ne le liste.

Diagnose

  1. Lisez le refus avant de deviner. Un déploiement qui n’a jamais été placé publie un événement deployment.unschedulable portant les propres mots du planificateur : chaque nœud candidat nommé, chacun avec la raison de son rejet. GET /api/v1/events le contient. Le message de statut propre au déploiement est le résumé — que certaines répliques sont inplanifiables car aucun nœud prêt n’accepte de nouveau travail — donc la raison par nœud est dans l’événement et nulle part ailleurs.

  2. Un nœud de votre locataire est-il prêt ? Ouvrez Nœuds, ou GET /api/v1/nodes. Le placement ne franchit jamais la limite du locataire, donc la capacité excédentaire d’un autre locataire n’est pas de la capacité.

  3. Les requêtes en ressources tiennent-elles sur un seul nœud ? Une requête plus grande que la capacité libre de n’importe quel nœud unique n’est pas divisée. Comparez les requêtes du déploiement avec la capacité rapportée des nœuds.

  4. Le bloc de placement correspond-il à quoi que ce soit ? Une contrainte d’étiquette, une anti-affinité ou un nœud nommé est un filtre, et un filtre qui ne correspond à rien ne laisse nulle part où mettre le conteneur. Voir placement et allocation.

  5. Le seul candidat est-il le nœud sur lequel le plan de contrôle lui-même s’exécute ? Un agent peut servir plusieurs locataires, et ce nœud continue d’exécuter les déploiements déjà placés dessus — mais il n’accepte aucun nouveau d’aucun locataire sauf la plateforme. Ce n’est pas non plus signalé comme une faute : tant que l’enregistrement propre à la plateforme de ce nœud est frais, la vivacité du nœud est lue depuis cet enregistrement et la boucle de santé de votre locataire laisse son statut tranquille, donc il n’est jamais marqué en échec et jamais compté parmi les nœuds dégradés. Un locataire dont le seul nœud est celui-là n’a nulle part où mettre quoi que ce soit de nouveau.

  6. Le déploiement exige-t-il une région ou un pays qu’aucun nœud ne publie ? La résidence des données est un filtre dur, pas une préférence. Vous l’écrivez comme placement.residency, et elle se compile en les trois étiquettes que le planificateur lit — donc cherchez l’une ou l’autre forme sur le déploiement :

    vous écrivez il est stocké comme un nœud le satisfait avec
    placement.residency.country odysseus.io/data-residency-country odysseus.io/country égal à celui-ci
    placement.residency.region odysseus.io/data-residency-region odysseus.io/geo-region égal à celui-ci, ou un pays que la région couvre
    placement.residency.blockedCountries odysseus.io/blocked-countries, séparés par des virgules rien — un pays listé supprime le nœud

    Le refus cite à la fois la valeur que vous avez exigée et la valeur que le nœud a signalée, de sorte qu’une différence d’orthographe est visible plutôt que déduite. Si vous êtes arrivé ici en tenant une étiquette odysseus.io/data-residency-* manuscrite, ce format n’est plus du tout accepté : le bloc saisi dans la colonne de gauche est le remplacement, et le rejet imprime vos propres valeurs dans celui-ci. Voir résidence des données.

  7. La résidence a-t-elle été acceptée avec un avertissement que vous n’avez pas lu ? Une contrainte de résidence que ce plan de contrôle ne peut pas honorer est stockée plutôt que refusée, et le corps de la réponse indique laquelle des deux elle est : application géographique désactivée, ou aucun nœud à portée n’annonce une étiquette correspondante — la seconde liste les valeurs que vos nœuds n’annoncent pas. Les deux se trouvent dans rejets et altérations sous placement.residency. Dans tous les cas, le déploiement est accepté et attend. GET /api/v1/scheduler/regions répond directement aux deux questions — les régions que ce plan de contrôle déclare, et si l’application est activée.

  8. Le locataire est-il à son quota ? Un quota atteint arrête les nouveaux conteneurs plutôt que de réduire les existants.

La liste des déploiements dans le tableau de bord Odysseus, montrant le statut et le nombre de répliques de chaque déploiement — où un déploiement accepté mais jamais placé est affiché sans réplique en cours d'exécution.

Resolve

  • Aucun nœud prêt : inscrivez-en un, ou remettez l’existant en service — voir un nœud que vous avez inscrit n’est pas listé.

  • Requêtes trop volumineuses : réduisez-les, ou ajoutez un nœud capable de les contenir. Les requêtes informent le placement ; elles ne sont pas une réservation, donc la correction est un ajustement plutôt qu’une réservation.

  • La contrainte ne correspond à rien : relâchez-la, ou étiquetez un nœud pour qu’il corresponde. Définir à la fois un bloc de placement et l’étiquette manuscrite équivalente est refusé, donc changez l’un des deux, pas les deux.

  • Seul le nœud du plan de contrôle lui-même est candidat : inscrivez un nœud à vous. Celui-ci est délibéré plutôt qu’une faute — un nœud partagé avec le plan de contrôle est exclu de la liste de placement pour chaque locataire sauf la plateforme, tandis que sa vivacité est reflétée depuis l’enregistrement de la plateforme afin que les conteneurs déjà dessus restent honnêtement surveillés. Rien que vous puissiez définir sur le déploiement ne le remplace, car il s’agit d’une règle de sécurité plutôt que d’une contrainte que vous avez écrite.

  • La résidence ne correspond à rien : donnez à un nœud l’étiquette odysseus.io/country ou odysseus.io/geo-region requise par le déploiement — dans la configuration de l’agent de ce nœud lui-même, et elle est re-publiée quand l’agent redémarre, pas quand le plan de contrôle le fait — ou changez ce que le déploiement requiert. Vérifiez ce que les nœuds publient avant de modifier le déploiement : une région orthographiée d’une manière qu’aucun nœud ne publie se lit exactement comme n’ayant aucune capacité du tout. Changez l’exigence dans placement.residency, jamais en modifiant une étiquette odysseus.io/data-residency-* ; cette étiquette est refusée en écriture, et le rejet vous remet le bloc typé rempli avec vos propres valeurs :

    placement:
    residency:
    country: CA # or `region:`, naming one this control plane declares
    blockedCountries: [CN]
  • The region name is not one this control plane declares: it is refused rather than left pending, and the refusal lists the declared names. GET /api/v1/scheduler/regions lists them too, and says whether enforcement is switched on — regions are declared per control plane, so a name that works elsewhere may not exist here.

  • Quota reached: free capacity by removing what you no longer run, or ask for the quota to be raised.

Prevent

Définissez les requêtes à partir de l’usage mesuré plutôt qu’à partir d’un nombre rond, et conservez au moins un nœud à vous qui ne correspond à aucune contrainte, afin qu’une étiquette mal tapée laisse un endroit où le conteneur puisse atterrir. Un nœud partagé avec le plan de contrôle ne compte pas comme ce secours : il n’accepte aucun nouveau placement de votre locataire quelle que soit son étiquette.