Kubernetes / Helm
Choisissez une version, consultez les champs signalés et exportez les documents utiles.
Résultat périmé. Relancez le formatage.
Les manifestes et schémas restent dans ce navigateur, sans envoi ni connexion au cluster.
Résultat périmé. Relancez le formatage.
La vérification statique ne garantit pas le déploiement. Le YAML reste exportable avec des erreurs de validation : consultez d’abord les diagnostics.
Ce Validateur YAML Kubernetes sert à relire un ensemble de ressources avant de le transmettre à la chaîne de déploiement. Un fichier peut être du YAML parfaitement lisible tout en contenant une faute de champ ou une valeur du mauvais type. Le numéro de document permet de retrouver l’objet concerné.
Pour valider les manifestes Kubernetes, choisissez un instantané précis : 1.35.0, 1.36.0 ou 1.37.0. Aucun contexte kubeconfig n’est consulté et aucune version n’est déduite de votre environnement. Le résultat correspond uniquement au contenu fourni et au schéma sélectionné.
Le Validateur YAML Kubernetes présente le kind, le nom et l’espace de noms de chaque ressource. Une erreur conserve sa position et son chemin de champ. Sélectionner un document extrait son YAML formaté sans supprimer les autres ressources de l’entrée, qui restent comprises dans la vérification.
Un sélecteur de Service est comparé aux labels des Pods et des modèles de charge du même espace de noms. Les références à ConfigMap et Secret sont recherchées dans les documents fournis. Une absence devient un avertissement, car l’objet peut déjà exister dans le cluster.
La version par défaut est 1.37.0 et le lancement est manuel. Une modification du texte, du schéma ou d’un paramètre périme le résultat et bloque son export. Utilisez le bouton ou Ctrl/Cmd+Entrée pour relancer la vérification, sans compilation répétée pendant la saisie.
Le panneau dédié attend apiVersion, kind et un JSON Schema draft-07. Seule cette paire exacte utilise la définition. Les références internes sont acceptées ; une référence distante manquante produit une erreur au lieu d’être récupérée sur le réseau.
Le formatage et la fusion produisent un aperçu avec le nombre de caractères et de documents. Appliquer remplace l’entrée ; Annuler la dernière modification restaure aussi le résultat précédent. L’export peut ensuite viser un document ou tout le flux YAML multi-documents.
Les définitions complètes proviennent d’un commit fixé du registre dérivé de Kubernetes OpenAPI. Les champs supplémentaires, types incorrects et valeurs obligatoires sont vérifiés. Une première violation est présentée par ressource : corrigez-la puis relancez pour découvrir les suivantes.
Les ressources courantes reçoivent les vérifications DNS adaptées, tandis que RBAC utilise les règles de segment de chemin. Une identité dupliquée compare groupe API, kind, espace de noms et nom, sans distinguer les versions API. Les règles de nom non couvertes sont signalées. Les noms de Job sont limités à 63 caractères, ceux de CronJob à 52.
L’analyse locale couvre les Pods et les modèles Deployment, StatefulSet, Job ou CronJob, entre autres. Elle recherche les objets ConfigMap et Secret utilisés dans les variables d’environnement, volumes et volumes projetés. Elle ne vérifie ni les clés individuelles ni la connectivité effective.
Pour formater YAML Kubernetes, le programme travaille sur l’arbre syntaxique plutôt que sur une conversion JSON. Les commentaires, ancres et écritures numériques restent présents. La fusion et l’extraction d’un document utilisent le même parseur, sans tri ni suppression automatique de champs.
Ce Validateur YAML Kubernetes réutilise des définitions du registre employé par kubeconform, mais ne lance pas son exécutable. Il propose une lecture locale des documents et relations. Un dry-run côté serveur contacte le cluster et peut effectuer des contrôles d’admission absents ici.
Non. Il ne prouve ni les permissions ni la disponibilité des ressources ou des images. Les politiques d’admission, les extensions et l’état du cluster restent déterminants. Gardez la vérification serveur dans votre processus normal, même après un résultat statique sans erreur.
Une ressource personnalisée inconnue nécessite un schéma fourni pour sa paire apiVersion/kind. Un objet CRD dans l’entrée n’installe pas automatiquement une définition pour les autres documents. Les contraintes CEL et la sémantique des extensions Kubernetes ne sont pas exécutées.
Oui, jusqu’à 100 documents séparés par ---. Chaque document non vide est listé et peut être exporté seul. Une enveloppe List est une structure différente : son contenu n’est pas développé et ne reçoit pas de validation individuelle.
Oui. Le formatage conserve les commentaires et les ancres à partir de l’arbre YAML. Il peut modifier l’indentation, les retours ou le style des collections. Examinez l’aperçu avant l’application ; une restauration remet ensemble l’entrée et le résultat précédent.
Une difficulté à signaler ?
Gardez la version du Validateur YAML Kubernetes avec les conclusions de votre revue. Après chaque correction, relancez puis exportez uniquement les documents nécessaires à la suite du travail.