01
Choisir la source des labels
Le mode ressources accepte un objet, un tableau ou un type List ou *List contenant un tableau items. Il ne lit que metadata.labels, sans parcourir le modèle de Pod d’un Deployment.
Kubernetes
sélecteur de labels Kubernetescomprendre chaque correspondance
Vérifiez les labels, puis inspectez les conditions appliquées à chaque ressource fournie.
sélecteur de labels Kubernetes
Résultats de correspondance
Les entrées restent dans ce navigateur. Aucun envoi, aucune connexion au cluster ni requête réseau.
Format des entrées et syntaxe
= · == · != · in · notin · key · !key. Les virgules imposent un ET ; un sélecteur vide accepte toutes les entrées.
Limites : 500 000 caractères JSON, 8 192 pour le sélecteur, 500 ressources, 64 conditions, 256 labels par ressource.
Sémantique : Kubernetes 1.35 / apimachinery v0.35.0 ; égalité, ensembles et existence.
Entrée modifiée. Relancez le test avant l’export.
Un sélecteur de labels Kubernetes peut inclure un Pod auquel vous ne pensiez pas : env!=prod accepte aussi un objet sans clé env. Avant de changer une requête ou un Service, examinez les résultats de chaque condition, et pas seulement le nombre de correspondances.
Le mode objet de labels lit tout l’objet ; le mode ressources lit metadata.labels. Les deux entrées sont conservées séparément. Un label nommé metadata reste donc un label, sans détection automatique ambiguë.
Pourquoi vérifier un sélecteur de labels Kubernetes ?
Repérer la condition qui écarte un objet
Ce sélecteur de labels Kubernetes évalue toutes les conditions, même après un premier échec. Un Pod web de développement peut satisfaire app=web et !paused tout en échouant sur la liste des environnements. Vous identifiez le critère précis à revoir, sans retirer des filtres au hasard.
Ne pas confondre vide et absent
Un label dont la valeur est "" existe toujours. Une clé absente ne possède aucune valeur. Le rapport distingue ces deux situations pour expliquer les conditions négatives et éviter de les prendre pour de simples tests d’existence.
Trois vérifications avant de réutiliser la requête
02
Essayer aussi le cas sans clé
Remplacez production par development, puis supprimez environment pour comparer in et notin. Le test automatique attend 350 ms après la saisie. Désactivez-le pour lancer le test avec le bouton ou Ctrl/Cmd + Entrée.
03
Examiner les détails avant l’export
Dépliez une ressource pour voir les labels et toutes les conditions. L’affichage avance par 50 entrées ; le rapport copié ou téléchargé reste complet. Toute modification bloque l’export jusqu’à un nouveau résultat valide.
Relier syntaxe des labels et résultat de sélection
Des règles propres aux clés et aux valeurs
Le préfixe DNS facultatif utilise des minuscules et compte au plus 253 caractères. Le nom contient de 1 à 63 caractères ASCII autorisés, avec majuscules possibles. La valeur peut être vide ou atteindre 63 caractères. Les préfixes réservés restent valides du point de vue syntaxique.
Égalité et ensembles dans une même requête
Un sélecteur de label peut combiner =, == et != avec in ou notin. Un sélecteur basé sur un ensemble regroupe les valeurs possibles d’une même clé. Les virgules entre conditions imposent un ET : ajouter une égalité réduit les possibilités au lieu de créer un OU.
Un résultat par entrée, même à nom identique
Le rapport conserve l’index, le chemin JSON et, s’ils sont présents, le type, le namespace et le nom. metadata ou labels absent ou null donne une map vide. Les noms identiques ne provoquent aucune fusion ; chaque objet garde son résultat.
Aucune conversion silencieuse de type
Dans les labels et sélecteurs, "01" et "1" sont des chaînes différentes. Les nombres, booléens et valeurs null sont refusés comme valeurs de label. Les clés JSON dupliquées sont aussi rejetées, au lieu de laisser la dernière valeur masquer la précédente.
Périmètre du test et limites des entrées
- Un sous-ensemble explicite de la syntaxe
- La référence est Kubernetes 1.35 / apimachinery v0.35.0 pour l’égalité, les ensembles et l’existence. Les comparaisons numériques < ou >, OU entre clés, jokers, expressions régulières, field selectors et règles d’affinité ne sont pas pris en charge.
- Du JSON strict et un mode choisi
- Pas de commentaires ni de virgules finales. YAML, fichiers, URL et objets structurés matchLabels ou matchExpressions ne sont pas lus. Un type List doit contenir un tableau items ; une ressource ordinaire est évaluée à partir de son propre metadata.labels.
- Une erreur bloque tout le lot
- Limites : 500 000 caractères JSON, 8 192 pour le sélecteur, 500 ressources, 64 conditions et 256 labels par ressource, en unités UTF-16. Le parseur limite aussi la profondeur à 100, les nœuds à 50 000 et chaque nombre à 1 000 caractères. Aucun objet invalide n’est ignoré pour produire un succès partiel.
- Le vide dépend du contexte d’API
- Une chaîne de sélecteur vide accepte ici tous les objets valides. Une zone JSON vide signifie pourtant aucune entrée : utilisez {} pour une map vide. Les sélecteurs de Service et les sélecteurs structurés null peuvent avoir une autre sémantique ; le rapport ne la déduit pas.
- Un instantané de vérification, pas un manifeste
- L’export conserve les champs d’identité choisis, les labels et les résultats, en omettant le reste de la ressource. Il ne modifie rien et ne vérifie ni disponibilité des Pods, ni endpoints, ni routage, ni appartenance à un contrôleur. Pour les données du cluster, obtenez les objets avec kubectl avant de tester leurs labels ici.
Questions sur le sélecteur de labels Kubernetes
Comment filtrer des Pods avec plusieurs labels ?
Séparez les exigences par des virgules, par exemple app=web,environment=production. Toutes doivent être satisfaites. Conservez le préfixe du nom : app.kubernetes.io/name et name désignent deux clés différentes.
Peut-on utiliser OU entre les conditions ?
Pas entre des clés différentes avec cette syntaxe. Pour plusieurs valeurs d’une même clé, utilisez environment in (production,staging). Deux égalités séparées par une virgule imposent au contraire un ET, parfois impossible à satisfaire.
Un label peut-il avoir une clé sans valeur ?
Oui : {"maintenance":""} représente une valeur vide. maintenance teste l’existence ; maintenance= exige une valeur vide présente ; !maintenance exige l’absence. Dans la syntaxe chaîne, maintenance in () contient une valeur vide et ne représente pas un ensemble sans élément.
Un Service sans endpoint a-t-il forcément un mauvais sélecteur ?
Non. Vérifiez d’abord les labels des Pods attendus, puis le namespace, leur état de disponibilité et les endpoints dans le cluster. Cette page ne connaît que les objets collés ; une correspondance ne garantit pas que le Service puisse acheminer le trafic.
Pourquoi env!=prod accepte-t-il un Pod sans label env ?
!= et notin acceptent aussi une clé absente. Pour exiger sa présence et une valeur autre que prod, écrivez env,env!=prod. Le détail du rapport sépare ce cas de celui où env possède une autre valeur.
Une question reste sans réponse ?
Vérifier les labels réellement présents
Appliquez ce sélecteur de labels Kubernetes à votre JSON et examinez les conditions en échec avant de modifier une configuration de workload.