Passer au contenu
100% Confidentialité — Vos fichiers restent sur votre appareil
>_
Français

Validateur YAML Kubernetes

Collez un ou plusieurs manifests Kubernetes (séparés par ---) et validez-les selon le vrai schéma avant de faire kubectl apply.

Déposez un fichier .yaml/.yml ici, ou collez le texte du manifest ci-dessus.

Les manifests séparés par "---" sont validés comme des documents distincts.

Options avancées

L'analyse et la validation s'exécutent dans votre navigateur — seul le schéma de la ressource (jamais votre manifest) est récupéré depuis un CDN public.

Collez un manifeste Kubernetes ci-dessus (ou chargez l'exemple) et les résultats de la validation s'afficheront ici.

Repérer les erreurs de manifeste Kubernetes avant kubectl

Un `kubectl apply` rejeté est souvent le premier moment où une erreur dans un manifeste Kubernetes devient visible — et à ce stade, vous êtes en plein déploiement, face à un message d'erreur qui cite un chemin de validation JSON Schema (`spec.template.spec.containers[0].image: Required value`) dont le lien avec le fichier YAML que vous éditiez n'a rien d'évident. Détecter le même type d'erreur plus tôt, avec la ligne exacte surlignée, transforme cela en correction de cinq secondes au lieu d'un changement de contexte.

La syntaxe de YAML a des angles vifs qu'on ne retrouve pas dans la plupart des autres formats de configuration : l'indentation est significative et un mélange de tabulations et d'espaces peut produire, dans certains cas, une structure différente (et fausse) sans aucune erreur ; les séparateurs de documents `---` sont faciles à perdre de vue dans un long fichier multi-ressources ; et un niveau d'imbrication en trop reste du YAML valide tout en signifiant tout autre chose pour Kubernetes. Cet outil analyse le YAML avec une approche qui conserve la position exacte dans la source : un problème de syntaxe est signalé à la vraie ligne où il se produit, et non « quelque part dans ce fichier de 200 lignes ».

Les apiVersion obsolètes sont un piège au ralenti : les Deployments en `extensions/v1beta1`, les StatefulSets et DaemonSets en `apps/v1beta1`/`apps/v1beta2` et les Ingress en `networking.k8s.io/v1beta1` sont toujours du YAML parfaitement valide et fonctionnaient sur les anciens clusters — jusqu'à ce que le cluster soit mis à niveau au-delà de la version où Kubernetes supprime définitivement l'ancien groupe d'API ; chaque manifeste qui l'utilise cesse alors de s'appliquer, sans avertissement préalable. Les repérer pendant l'édition (avec l'apiVersion de remplacement suggérée) évite de les découvrir en pleine mise à niveau du cluster.

La validation par schéma avec la vraie spécification OpenAPI de Kubernetes attrape le reste : un champ `replicas` devenu une chaîne entre guillemets au lieu d'un nombre, un `containerPort` hors de la plage autorisée, un champ obligatoire comme `spec.selector` d'un Deployment supprimé lors d'un copier-coller entre manifestes. Aucune de ces erreurs n'est une erreur de syntaxe YAML — le fichier s'analyse très bien — et c'est précisément pourquoi une passe de schéma dédiée détecte ce qu'une lecture rapide du fichier laisse passer.

Questions fréquentes

Cet outil remplace-t-il `kubectl apply --dry-run` ou `kubeconform` ?

Non. `kubectl apply --dry-run=server` est la seule vérification qui s'exécute auprès de l'API server de votre vrai cluster (y compris les CRD et webhooks d'admission installés), et `kubeconform`/`kubeval` sont des outils en ligne de commande éprouvés conçus pour les pipelines CI. Cet outil valide la même catégorie de problèmes — syntaxe YAML, forme du schéma, apiVersion obsolètes — depuis un onglet de navigateur, avant même d'avoir configuré `kubectl`, ou pour relire un manifeste qu'on vous a envoyé.

D'où viennent les schémas ?

De `yannh/kubernetes-json-schema`, un miroir communautaire mis à jour automatiquement des JSON Schemas dérivés de l'OpenAPI de Kubernetes, récupérés à la demande depuis un CDN public pour la version de Kubernetes que vous choisissez. Rien de votre manifeste n'est envoyé : seul le fichier de schéma public et versionné est téléchargé, le même pour tous les utilisateurs qui valident ce kind et cette version.

Pourquoi seulement 10 types de ressources ?

Deployment, Service, Ingress, ConfigMap, Secret, StatefulSet, DaemonSet, Job, CronJob et PersistentVolumeClaim couvrent la grande majorité des manifestes écrits à la main. Les autres kinds bénéficient quand même du contrôle complet de la syntaxe YAML et de la détection des apiVersion obsolètes ; ils n'ont simplement pas encore de validation de la forme par schéma.

Mon YAML quitte-t-il mon navigateur ?

Non. L'analyse et la validation par schéma s'exécutent toutes deux en JavaScript pur dans cet onglet : la seule requête réseau de cet outil consiste à récupérer le fichier JSON Schema public correspondant au type de ressource et à la version de Kubernetes sélectionnés, jamais le contenu de votre manifeste.

Outils associés