# kubectl get -o yaml: Usage, Options & Common CI Errors

> kubectl get -o yaml dumps a resource's full spec and status as YAML. Server-side defaults, the managedFields noise, and round-tripping into apply.

Source: https://latchkey.dev/learn/command-reference/kubectl-get-o-yaml  
Updated: 2026-06-25

Dump a live object exactly as the API server stores it.

kubectl get -o yaml prints the complete server representation of a resource - spec, status, and metadata. It is how you inspect what actually got applied and how you capture a baseline for debugging in CI.

## What it does

kubectl get RESOURCE NAME -o yaml serialises the live object, including server-defaulted fields, status, and bookkeeping metadata (resourceVersion, uid, creationTimestamp, managedFields). It reflects reality after admission and defaulting, not just what you submitted.

## Common usage

```Terminal
kubectl get deploy/web -o yaml
kubectl get deploy/web -o yaml > web.snapshot.yaml
kubectl get configmap app-cfg -o yaml | grep -A20 '^data:'
kubectl get pod my-pod -o yaml | yq '.status.conditions'
```

## Common errors in CI

The big gotcha is re-applying this output: a live -o yaml dump carries status, resourceVersion, uid, and managedFields, so kubectl apply -f it back errors or behaves oddly ("resourceVersion should not be set", metadata conflicts). To round-trip an object, strip the runtime fields first (or use kubectl get ... -o yaml --show-managed-fields=false plus a yq scrub). The dump can also be huge because of managedFields noise - pass --show-managed-fields=false to quiet it. Remember Secrets print base64-encoded data, not plaintext.

## Using this in CI

A runner has no kubeconfig, no cached context, and no interactive auth. Every kubectl invocation in CI needs the context supplied explicitly, and most confusing CI failures here are the command running against the wrong cluster or no cluster at all.

```Terminal
# never rely on the ambient context on a runner
kubectl --context "$KUBE_CONTEXT" -n "$NAMESPACE" get pods

# confirm what you are actually connected to before mutating anything
kubectl config current-context
kubectl cluster-info

# fail fast instead of hanging on an unreachable API server
kubectl --request-timeout=30s get nodes
```

> Always set `--request-timeout` in CI. Without it an unreachable API server hangs until the job times out, which turns a thirty-second failure into a twenty-minute one.

## FAQ

### kubectl get -o yaml: Usage, Options & Common CI Errors?

kubectl get -o yaml prints the complete server representation of a resource - spec, status, and metadata. It is how you inspect what actually got applied and how you capture a baseline for debugging in CI.

### What it does?

kubectl get RESOURCE NAME -o yaml serialises the live object, including server-defaulted fields, status, and bookkeeping metadata (resourceVersion, uid, creationTimestamp, managedFields). It reflects reality after admission and defaulting, not just what you submitted.

### Common errors in CI?

The big gotcha is re-applying this output: a live -o yaml dump carries status, resourceVersion, uid, and managedFields, so kubectl apply -f it back errors or behaves oddly ("resourceVersion should not be set", metadata conflicts). To round-trip an object, strip the runtime fields first (or use kubectl get ...

---

Latchkey runs CI/CD that repairs its own failures. Agent entry points: https://latchkey.dev/agent.txt, https://latchkey.dev/openapi.json, https://latchkey.dev/llms.txt