Convert JSON to a Kubernetes YAML Manifest

The end-to-end GitOps move: export the live Deployment, strip server fields, convert at indent 2, commit. The converter alone won't strip status — that's why json-key-filter is the prior step.

1. kubectl get deployment web -n prod -o json > web.json

2. json-key-filter → remove: status, metadata.managedFields,
   metadata.resourceVersion, metadata.uid, metadata.creationTimestamp

3. json-to-yaml (indent 2) →

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
  namespace: prod
spec:
  replicas: 3
  selector:
    matchLabels:
      app.kubernetes.io/name: web
  template:
    spec:
      containers:
        - name: web
          image: nginx:1.25
          ports:
            - containerPort: 8080

Same JSON, two indent settings. Indent 2 is the manifest style; indent 4 expands the sequence dash onto its own line. Both parse identically in Kubernetes, but reviewers and linters expect the compact form.

JSON: {"containers":[{"name":"app","image":"nginx"}]}

Indent 2 (use this):
containers:
  - name: app
    image: nginx

Indent 4 (avoid for manifests):
containers:
    -
        name: app
        image: nginx

A common worry is that conversion quotes everything. It doesn't — numbers and booleans stay unquoted, which is exactly what the Kubernetes schema requires.

JSON:
{"spec":{"replicas":3,"template":{"spec":{"hostNetwork":true,
  "containers":[{"ports":[{"containerPort":443}]}]}}}}

YAML (indent 2):
spec:
  replicas: 3
  template:
    spec:
      hostNetwork: true
      containers:
        - ports:
            - containerPort: 443

kubectl frequently emits null for unset optional fields. YAML keeps them as null. The API accepts this, but a reviewer-friendly manifest omits them.

JSON (from kubectl):
{"spec":{"strategy":{"rollingUpdate":null},"replicas":2}}

YAML:
spec:
  strategy:
    rollingUpdate: null   # <- review: usually drop this line
  replicas: 2

When comparing two exports of the same object, enabling sort-keys makes both files byte-stable so the diff shows only real changes. The trade-off is that canonical field order (apiVersion → kind → metadata → spec) is lost.

JSON: {"kind":"Service","apiVersion":"v1","metadata":{"name":"web"}}

sortKeys ON →
apiVersion: v1
kind: Service
metadata:
  name: web

(alphabetical: apiVersion before kind before metadata)

The converter dumps every key it receives. If you feed it raw kubectl get -o json, the output will contain status: and metadata.managedFields: — exactly the runtime cruft you should not commit. Remove those keys with json-key-filter before converting. This is intentional: silently dropping fields would be unsafe for a general JSON→YAML tool.

At indent 4, js-yaml writes a sequence item as a bare - on one line with the mapping indented beneath it. It parses fine, but it does not match kubectl/manifest conventions and may trip strict style linters like yamllint with custom rules. Keep indent at 2 for Kubernetes.

JSON numbers larger than 2^53 (about 9 quadrillion) exceed JavaScript's safe integer range. The browser's JSON.parse rounds them before YAML ever sees them, so a 20-digit generation or external ID can change. Kubernetes rarely uses numbers this large, but if a CRD field does, store it as a JSON string to preserve it.

If the JSON contains the same key twice in one object, JSON.parse keeps only the last occurrence — the first is silently discarded before conversion. Malformed kubectl output won't do this, but hand-edited JSON might. Validate first with json-validator.

The converter calls JSON.parse on the file. A trailing comma, a comment, or an unquoted key throws a parse error and nothing converts. Kubernetes objects from kubectl are always strict JSON; if you hand-edited the file, fix it with json-format-fixer first.

A Secret object's data map holds base64-encoded values. The converter passes those base64 strings through verbatim — it does not decode or re-encode them. The YAML Secret remains functionally identical to the JSON one. Treat the output as sensitive and avoid committing real Secret values to Git.

kubectl get pods -o json returns a List with an items array. The converter handles it, producing one big YAML document with an items: sequence — not separate --- documents. The tool does not emit multi-document YAML, so to split a List into individual manifests, separate them in the JSON first.

A single-line command or args value longer than 80 characters is wrapped using a folded block scalar (>-). The folded value reconstructs to the same string, so Kubernetes runs the identical command. If you prefer it on one line for readability, the meaning is unchanged regardless.

Keys or string values that look like YAML 1.1 keywords (on, off, yes, no) are quoted on output to keep them as strings — correct behaviour. This is uncommon in Kubernetes objects but can appear in custom annotation values.