Introduction

You can generate Kubernetes YAML with kubectl in two main ways. If you want YAML for a resource that already exists, use kubectl get ... -o yaml. If you want a manifest template without actually creating the resource, use a create command together with --dry-run=client -o yaml.

Those two cases are easy to confuse, but they solve different problems. One exports the current state of an existing resource, while the other generates a manifest from the command you would have run.

Export YAML for an Existing Resource

To fetch the YAML for something already in the cluster:

kubectl get deployment my-app -o yaml

That prints the resource as Kubernetes currently knows it.

You can redirect it to a file:

kubectl get service my-service -o yaml > service.yaml

This is useful for inspection, debugging, or starting from a live resource as a baseline.

Generate a Manifest Without Creating the Resource

If you want a YAML template from a kubectl create command, use --dry-run=client -o yaml:

kubectl create deployment my-app \
  --image=nginx:1.27 \
  --dry-run=client -o yaml

That prints the deployment manifest but does not create anything in the cluster.

You can save it directly:

kubectl create deployment my-app \
  --image=nginx:1.27 \
  --dry-run=client -o yaml > deployment.yaml

This is the most common answer when people ask how to generate a starter YAML template from kubectl.

Example with a Service

You can do the same for other resource types:

kubectl create service clusterip my-service \
  --tcp=80:8080 \
  --dry-run=client -o yaml

This gives you a starting service manifest that you can edit further before applying it.

Know the Difference Between Generated and Exported YAML

Generated YAML from kubectl create ... --dry-run=client -o yaml is usually cleaner for authoring because it contains only the fields needed for the desired resource.

Exported YAML from kubectl get -o yaml often contains extra cluster-managed metadata such as:

• 'resourceVersion'
• 'uid'
• 'managedFields'
• status sections

Those fields are useful for inspection, but you usually do not want to keep all of them when creating a reusable manifest file.

That is why many people prefer generating a fresh manifest or cleaning an exported one before putting it under version control. It leads to quieter diffs and less accidental drift from server-generated fields. It also makes code review easier for teams using declarative Git-based workflows.

Apply the Generated YAML Later

Once the file looks the way you want, apply it normally:

kubectl apply -f deployment.yaml

This is a nice workflow for teams that want to start from kubectl syntax but end with declarative YAML checked into a repository.

Common Pitfalls

• Using kubectl get -o yaml when what you really wanted was a clean starter template.
• Forgetting --dry-run=client, which may create the resource instead of only printing YAML.
• Committing exported YAML with cluster-generated metadata that should not be managed manually.
• Assuming every imperative kubectl command supports the same generation pattern without checking the command syntax.

Summary

• Use kubectl get <resource> <name> -o yaml to export an existing resource.
• Use kubectl create ... --dry-run=client -o yaml to generate a starter manifest without creating anything.
• Redirect the output to a file if you want a reusable YAML template.
• Generated YAML is usually cleaner than raw exported YAML for authoring.
• Be careful not to keep cluster-managed metadata in manifests you plan to maintain manually.