Convertir JSON en YAML pour Kubernetes (avec exemples)

By ZonoToolsApril 30, 202611 min read

Pourquoi Kubernetes utilise YAML

Kubernetes est construit autour d'une configuration déclarative: vous décrivez l'état souhaité (réplicas, images, environnement, volumes) et les contrôleurs rapprochent le cluster avec cette spécification. Ce flux de travail s'intègre naturellement aux fichiers YAML archivés dans Git, examinés dans les PR et appliqués aveckubectl apply -f. YAML supprime les accolades et les virgules afin que les grandes spécifications imbriquées restent écrémées, exactement ce que vous souhaitez lorsqu'un ingénieur senior compare un service ou un StatefulSet à 2 heures du matin.

GitOps déclaratif suppose que le dépôt est la source de vérité: Argo CD, Flux ou Plain CI applique ce qui a changé. Les différences YAML sont lues orientées ligne dans GitHub/GitLab; JSON s'effondre souvent en blobs minifiés illisibles à moins que vous n'appliquiez une jolie impression partout. Cette friction est importante lorsque les évaluateurs doivent repérer une bosse accidentellereplicasou un deltasecurityContextrisqué.

La lisibilité n’est pas ici cosmétique. Les équipes opérationnelles standardisent les manifestes; Les graphiques Helm et les superpositions Kustomize sont toujours compilés en objets en forme de YAML. Même si vous réalisez un prototype dans un autre format, le chemin JSON vers yaml kubernetes est la manière dont la plupart des équipes transforment les blobs en forme d'API en quelque chose que les humains maintiennent à long terme.

JSON contre YAML dans Kubernetes

Le plan de contrôle parle JSON de bout en bout. Chaque réponsekubectl get deployment nginx -o JSONest JSON; les webhooks d'admission et le serveur API échangent JSON. YAML est une couche pratique pour les auteurs:kubectlaccepte YAML en entrée, le convertit en JSON sous le capot et conserve les objets dans etcd sous une forme structurée.

La répartition est donc pratique: les machines et les traces de débogage exposent JSON; Auteur humain et critique YAML. Les bibliothèques clientes (client-go, contrôleur-runtime) marshalent les structures vers JSON lorsqu'elles parlent à l'API. Votre travail CI peut capturer des objets actifs au format JSON à des fins d'audit, puis l'ingénierie demande YAML afin que les équipes de plate-forme puissent créer et corriger sans toucher aux structures Go.

Lorsque vous collez une exportation API dans un formateur ou transférez des échantillons via un convertisseur, vous comblez délibérément cette lacune: conservez JSON là où l'automatisation en est propriétaire, émettez YAML là où les humains se déconnectent. Pour une comparaison plus approfondie des formats, voir JSON vs YAML: differences and use cases: même objet logique, ergonomie différente.

Exemple: manifeste de déploiement en JSON

Supposons que vous ayez prototype un déploiement à l'aide de bibliothèques clientes ou copié un blob JSON minifié à partir d'un journal d'audit. Voici un déploiement nginx à deux répliques réaliste que vous pourriez recevoir au format JSON:

Il s'agit d'un JSON Kubernetes valide:apiVersion,kind,spec.template.spec.containersimbriqué et une liste de ports exprimée sous forme de tableau JSON.

json

{  "apiVersion": "apps/v1",  "kind": "Deployment",  "metadata": {    "name": "nginx-demo",    "namespace": "default",    "labels": { "app": "nginx-demo" }  },  "spec": {    "replicas": 2,    "selector": { "matchLabels": { "app": "nginx-demo" } },    "template": {      "metadata": { "labels": { "app": "nginx-demo" } },      "spec": {        "containers": [          {            "name": "nginx",            "image": "nginx:1.25-alpine",            "ports": [{ "name": "http", "containerPort": 80 }]          }        ]      }    }  }}

Exemple: le même manifeste que YAML

Après la conversion JSON en yaml kubernetes, vous souhaitez généralement une structure basée sur l'indentation que vous pouvez déposer à côté d'autres manifestes dans un dépôt. Le YAML équivalent conserve les mêmes clés et valeurs scalaires mais élimine le bruit de ponctuation:

Vous pouvez vérifier l'intégrité aveckubectl apply --dry-run=client -f -avant de toucher un cluster actif. Si la conversion supprime des champs ou remodèle les listes de manière inattendue, traitez-le comme un bug dans votre pipeline et non comme un simple geste de production passé.

Le YAML multidocument (séparateurs---) est courant dans les dépôts; la sortie de votre convertisseur est généralement une ressource par pâte. Fusionnez les exportations JSON divisées dans des fichiers séparés ou concaténez-les avec---uniquement après la validation indépendante de chaque document. Ne présumez pas qu'une fusion aveugle préserve les limites du document.

yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-demo
  namespace: default
  labels:
    app: nginx-demo
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx-demo
  template:
    metadata:
      labels:
        app: nginx-demo
    spec:
      containers:
        - name: nginx
          image: nginx:1.25-alpine
          ports:
            - name: http
              containerPort: 80

Supprimer le bruit du cluster avant Git

Les exportations directement à partir de lectures lourdes etcd contiennent des champs dont vous ne voulez jamais dans Git:resourceVersion,uid,creationTimestamp, des blocs ManagedFields et des sous-arbres .status entiers que possèdent les contrôleurs. Leur validation entraîne un désabonnement inutile et entre parfois en conflit avec la sémantique d'application côté serveur.

Avant de convertir JSON en YAML pour l'enregistrement Kubernetes, conservez:

apiVersion,kind,metadataque vous contrôlez (name,namespace,labels,annotationsqui sont intentionnels)
spec(etdatapour ConfigMaps,rulespour RBAC, etc.)

Supprimez ou remplacez tout le reste, sauf si vos outils en dépendent explicitement.kubectl apply --dry-run=serverdétecte certaines erreurs manquées lors de l'exécution à sec côté client lorsque l'admission fait muter des objets.

Si vous créez des modèles autour de CustomResourceDefinitions, les dumps JSON des API alpha incluent parfois des champs par défaut que votre YAML n'a jamais épelés – par rapport àkubectl explain <kind> --recursivelorsque les réviseurs demandent pourquoi un champ est apparu « comme par magie ». Les convertisseurs n’inventent pas la sémantique; ils reflètent la structure. L'entrée de déchets signifie toujours confondre YAML.

Les fluxkubectl applyhérités cachent parfois l'intention sérialisée à l'intérieur demetadata.annotations["kubectl.kubernetes.io/last-applied-configuration"]. Que vous conserviez ou supprimiez cette annotation dépend du fait que vous vous appuyiez toujours sur la sémantique d'application côté client; Les équipes GitOps-first préfèrent souvent l'application côté serveur (--server-side) avec des gestionnaires de champs explicites au lieu de faire glisser le JSON historique dans les annotations.

Problèmes courants: indentation et tableaux

L'indentation est la syntaxe de YAML. Deux espaces par rapport aux tabulations, ou un espace supplémentaire avantcontainers:, peuvent transformer une arborescence JSON valide en une erreur d'analyseur ou pire: un sous-arbre valide mais erroné fusionné sous le mauvais parent. Normalisez toujours les tabulations en espaces et gardez une profondeur cohérente avec la façon dontkubectlémet YAML (kubectl get deploy nginx-demo -o yamlest une bonne référence de style). Les éditeurs qui mélangent « indentation intelligente » avec des arbres collés dérivés de JSON sont une source fréquente de bugs d'espacement de deux: désactivez le formatage lors de l'enregistrement une fois pendant la résolution des problèmes structurels, puis réactivez-le.

Les Tableaux exposent une autre incompatibilité. JSON épelle les séquences comme[...]; YAML utilise les éléments-sous une clé. Un convertisseur doit conserver s'il s'agit d'un objet unique ou d'une liste à un élément: Kubernetes s'en soucie (env,volumeMounts,ports,imagePullSecrets). Un bug d'aplatissement silencieux transforme un PodSpec valide en quelque chose qui se valide localement mais échoue à l'admission ou se déploie avec des side-cars manquants.

Les bizarreries de fusion et les surprises de typage scalaire sont couvertes dans Common JSON to YAML conversion errors: lisez-le avant d'automatiser la conversion dans CI sans tests.

Les manifestes volumineux dekubectl get … -o JSONincluent également des champs remplis par le serveur (resourceVersion,uid, statut). Supprimez le statut et les métadonnées que vous n’avez pas l’intention d’appliquer avant la conversion et la validation; sinon, votre contrôleur GitOps combat les identifiants obsolètes ou réapplique les observations de répliques obsolètes.

Convertissez instantanément avec ZonoTools

Vous n'avez pas besoin d'un script Node jetable pour chaque collage. Ouvrez JSON to YAML: collez le déploiement JSON ou le fragment en forme de CRD, copiez le YAML, puis collez-le dans votre dépôt ou canalisez viakubectl apply --dry-run=client -f -. Le traitement reste dans le navigateur, ce qui est pratique lorsque les manifestes font référence à des hôtes de registre interne ou à des secrets d'espace réservé que vous refusez de transmettre à une API tierce.

Workflow qui a tendance à fonctionner sur de vraies équipes:

Mettez d'abord JSON en forme lisible, ou minifiez-le proprement, si vous l'avez copié depuis des journaux; les virgules parasites brisent rapidement les analyseurs.
Convertissez, puis coupez les champs du serveur et réexécutez l'exécution à sec.
Ouvrez un PR; laissez CI appliquer le schéma ou la politique (OPA, kubeconform, etc.).

Associez cette discipline à la révision du code, et la boucle JSON vers yaml kubernetes cesse d'être une friction entre un bundle JSON exporté par le support et le YAML maintenable attendu par votre référentiel de plate-forme.