Article du guide · 5 min de lecture
Conversion de Kubernetes YAML en JSON en toute sécurité
La conversion de Kubernetes YAML en JSON se produit à la limite API : Kubernetes parle JSON, et YAML est une couche pratique que kubectl et ses bibliothèques clientes convertissent pour vous — c'est pourquoi la compréhension de la conversion est importante lorsque quelque chose tourne mal.
Mis à jour
Kubernetes YAML à JSON : pourquoi convertir ?
- Débogage avec la forme API réelle : lorsqu'un champ est rejeté, JSON vous montre exactement ce que voit le serveur, sans ambiguïté de frappe YAML.
- Alimentation des pipelines : de nombreux outils (moteurs de politiques, scripts CI, pipelines jq) consomment JSON plus confortablement que YAML.
- Rendu différent : la comparaison de deux versions Helm avec JSON rend les changements de type visibles — le bug classique « vrai n'est pas « vrai » ».
- Documentation et enseignement : les accolades JSON rendent l'imbrication de spec.template.spec.containers indubitable.
Le problème du multidocument
Un fichier manifeste contient généralement de nombreuses ressources séparées par --- : Namespace, ConfigMap, Deployment, Service, Ingress, HPA. Un convertisseur naïf de YAML à JSON lit le premier document et supprime silencieusement le reste – un mode de défaillance véritablement dangereux pour les travaux d'infrastructure. Les bons convertisseurs produisent un tableau JSON, un élément par document, et vous indiquent combien ils en ont trouvé.
Helm, ancres et "pourquoi n'y a-t-il pas d'ancres dans ma sortie ?"
YAML ancres et alias peuvent dédupliquer des blocs dans un seul fichier. Les modèles Helm vont plus loin : ils ne sont pas du tout YAML tant qu'ils ne sont pas rendus. Convertissez uniquement la sortie rendue (modèle de barre / helm obtient le manifeste), jamais un fichier de modèle brut. Consolider les ancres dans leurs valeurs est le comportement correct : JSON n'a pas d'alias, le convertisseur doit donc les déréférencer.
Les pièges à taper
- Booléens : les versions et les noms comme "y", "yes", "on" sont des booléens dans YAML 1.1. Dans Kubernetes, une balise d'image comme « on » ou une version comme « 1.10 » est un cas classique de corruption silencieuse — citez-les toujours dans la source.
- Ports et ressources : conteneurPort : 8080 est un entier ; "8080" en tant que chaîne sera rejeté par le API pour les champs saisis. JSON garde la distinction explicite.
- Quantités de mémoire : 128Mi est une chaîne dans les deux formats - correct, car elle est analysée par Kubernetes, et non par YAML.
- Valeurs d'environnement : les valeurs d'environnement sont des chaînes par spécification ; valeur : 3000 dans YAML devient le nombre 3000, que le API rejette. C'est l'un des bogues manifestes les plus courants, et la sortie JSON le rend immédiatement évident.
Un flux de travail pratique
- Rendre en premier (si Helm) : modèle de barre mychart > render.yaml.
- Convertissez avec la prise en charge de plusieurs documents en un tableau JSON, afin qu'aucune ressource ne soit supprimée.
- Comparez ce que possède le cluster : kubectl get déployer web-app -o json, par rapport à un outil de comparaison JSON — les changements importants ressortent immédiatement.
- Patchez en toute confiance : les correctifs JSON (RFC 6902) et les correctifs de fusion stratégiques sont plus faciles à écrire sur JSON sans ambiguïté.
Les deux étapes sont couvertes par des outils sur ce site : YAML à JSON pour la conversion, et JSON Diff pour comparer le résultat avec la sortie kubectl — aucune donnée de cluster ne quitte votre machine.