Champs d’état

États d’affichage

Les GitRepos, HelmOps, Clusters et Bundles ont différents états à chaque phase d’application des Bundles.

Puisque les états des BundleDeployments sont propagés au Bundle, GitRepo, Cluster et ClusterGroup, vous les trouverez affichés de la même manière. La différence réside dans la perspective sur les ressources.

En regardant le GitRepo, les états de toutes les ressources liées au GitRepo y sont affichés. En regardant le Cluster, les états de tous les Bundles dans ce Cluster sont affichés, ce qui peut s’étendre sur plusieurs GitRepos. En regardant le Bundle, les états de tous les BundleDeployments dans ce Bundle sont affichés.

La condition Ready est utilisée pour déterminer si les BundleDeployments sont dans un état Ready. La condition Ready est définie sur True si tous les BundleDeployments sont dans l’état Ready. Si au moins un BundleDeployment n’est pas dans l’état Ready, la condition Ready est définie sur False.

Tous les états des BundleDeployments sont agrégés dans le champ message de la condition d’état Ready. Pour éviter que le message ne devienne trop long, seuls les dix premiers états sont affichés. Le champ message contient le nombre de BundleDeployments dans chaque état, suivi du nom du Cluster où se trouve le BundleDeployment. Les états Ready sont exclus du champ message.

Par exemple :

status:
  conditions:
  - lastUpdateTime: "2025-06-25T14:59:35Z"
    message: WaitApplied(1) [Cluster fleet-default/downstream4]
    status: "False"
    type: Ready

SUSE® Rancher Prime Continuous Delivery utilise le paquet kstatus du module sigs.k8s.io/cli-utils pour déterminer l’état Prêt des BundleDeployments en fonction de l’état de leurs ressources. Pour plus de détails, voir le README du paquet kstatus.

Le champ status.display fournit un résumé de l’état. Les états sont classés, et le pire état possible est utilisé comme state dans le champ status.display.

C’est le rang selon lequel les états sont affichés. Si un Bundle a des BundleDeployments dans différents états, le pire état est utilisé dans le champ status.display.state. Cet état est également propagé des Bundles vers d’autres ressources SUSE® Rancher Prime Continuous Delivery (GitRepos, Clusters, ClusterGroups).

Du meilleur au pire :

Prêt
NotReady
En attente
OutOfSync
Modifié le
Attente appliquée
Erreur appliquée

Ensembles

Prêt : Les Bundles ont été déployés, et toutes les ressources sont prêtes. Sinon, le champ message de la condition Ready contient une agrégation des états des BundleDeployments.
Pas prêt : Les BundleDeployments ont été déployés, mais certaines ressources ne sont pas prêtes (par exemple, les images de conteneur sont en cours de téléchargement ou les services n’ont pas signalé leur disponibilité).
En attente : Les Bundles sont en attente de traitement par le contrôleur Fleet. Cela peut se produire si le déploiement est suspendu (voir Stratégie de déploiement).
Hors de synchronisation : Les Bundles sont synchronisés depuis le contrôleur Fleet, mais les BundleDeployments mis à jour n’ont pas encore été créés, donc les agents en aval ne peuvent pas synchroniser les changements. Cela peut également se produire si le déploiement est suspendu (voir Stratégie de déploiement).
Modifié : Les Bundles sont déployés et les ressources sont prêtes, mais certaines ressources déployées ont été modifiées de manière externe et non depuis Git.
Attente appliquée : Les Bundles sont synchronisés mais en attente de déploiement. L’affichage persistant de cet état peut indiquer un cluster cible injoignable.
Erreur appliquée : Les Bundles ont été synchronisés avec succès mais ont rencontré des erreurs lors du déploiement.

Clusters

Attente d’enregistrement : En attente que l’agent rapporte les informations d’enregistrement et l’état du cluster.

Prêt : Tous les Bundles dans ce cluster sont déployés et les ressources sont prêtes.
Pas prêt : Certains Bundles dans ce cluster ne sont pas prêts.
En attente : Certains Bundles sont en attente.
Hors de synchronisation : Certains Bundles sont hors de synchronisation.
Modifié : Certains Bundles sont modifiés.
Attente appliquée : Certains paquets attendent d’être appliqués.
Erreur appliquée : Certains Bundles contiennent des erreurs.

GitRepo

Prêt : True si les états désirés et actuels correspondent. Si False, le message contient :
- une erreur du contrôleur GitJob,
- une erreur du Bundle (par exemple, échec de la modélisation), ou
- une liste agrégée de paquets non présents dans Ready.
GitPolling : Indique si le polling ou le clonage initial est en cours. True si le polling est réussi ou désactivé.
Rapprochement : Le contrôleur est actuellement en train de rapprocher les changements.
Bloqué : Le contrôleur a rencontré une erreur ou n’a pas réussi à progresser.
Accepté : Des restrictions GitRepo ont été appliquées et des secrets Helm externes existent.

Conditions HelmOp

Prêt : True si tous les BundleDeployments ont été déployés avec succès ; False si certains ne sont pas prêts.
Accepté : False si les options Helm sont invalides, si les versions de chart ne peuvent pas être résolues, si le polling a échoué, ou si la création du Bundle a échoué.
Pollé : True si le polling a réussi. False sinon, avec un message d’erreur.

status.display

Les champs status.display sont partagés entre GitRepos et GitOps. Les deux ressources contiennent un champ status.display résumant l’état de la ressource. La valeur de state peut différer selon le type de ressource.

readyBundleDeployments : Une chaîne sous la forme %d/%d montrant le nombre de BundleDeployments prêts par rapport au total.
state : Représente l’état du GitRepo (par exemple, GitUpdating) ou le plus haut BundleState selon le Rang d’État. Si Ready, il est défini sur une valeur vide.
message : Contient des messages de condition de déploiement pertinents.
error : true si un message d’erreur existe.

Liste des ressources

Les ressources déployées sur les clusters cibles sont classées sous GitRepos et HelmOps.

La liste status.ResourceCounts pour les GitRepos est dérivée de bundleDeployments.

Le champ perClusterResourceCounts fournit des statistiques par cluster sur les ressources déployées.

perClusterResourceCounts:
    fleet-default/imported-0:
      desiredReady: 9
      missing: 0
      modified: 0
      notReady: 0
      orphaned: 0
      ready: 9
      unknown: 0
      waitApplied: 0
    fleet-default/imported-1:
      desiredReady: 9
      missing: 0
      modified: 0
      notReady: 0
      orphaned: 0
      ready: 9
      unknown: 0
      waitApplied: 0
    fleet-default/imported-2:
      desiredReady: 9
      missing: 0
      modified: 0
      notReady: 0
      orphaned: 0
      ready: 9
      unknown: 0
      waitApplied: 0
  readyClusters: 3
  resourceCounts:
    desiredReady: 27
    missing: 0
    modified: 0
    notReady: 0
    orphaned: 0
    ready: 27
    unknown: 0
    waitApplied: 0

Cela aide à identifier rapidement quels clusters ont des déploiements incomplets ou incohérents.

La ressource BundleDeployment comprend deux champs supplémentaires pour une meilleure visibilité :

incompleteState : qui est défini sur vrai si le statut des ressources non prêtes ou modifiées a plus de 10 éléments.
resourceCounts : qui compte le nombre de ressources par leur état.

La liste status.ResourceCounts pour HelmOps est dérivée de bundleDeployments.

Comptes de ressources

Cela montre comment les comptes de ressources se propagent entre les ressources.

Les ressources déployées sont listées sous GitRepos dans status.Resources, dérivées de bundleDeployments.

De même, les ressources déployées pour HelmOps sont listées dans status.Resources, dérivées de bundleDeployments.

Dans les Clusters, status.ResourceCounts est dérivé de GitRepos.

Dans les Groupes de Clusters, status.ResourceCounts est dérivé de GitRepos.