# kubectl create: Usage, Options & Common CI Errors

> kubectl create imperatively creates resources and scaffolds manifests. create vs apply, --dry-run YAML, and the AlreadyExists error in re-run pipelines.

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

Create resources imperatively - or scaffold YAML to commit.

kubectl create makes a brand-new resource and errors if it already exists. Its subcommands (secret, configmap, deployment, job) are also the fastest way to generate correct manifest YAML.

## What it does

kubectl create -f reads a manifest and creates the objects, failing if any already exist (unlike apply, which patches). The subcommand forms - create secret generic, create configmap, create job - build resources from flags. Add --dry-run=client -o yaml to print the manifest instead of creating it, which is the canonical way to scaffold YAML.

## Common usage

```Terminal
kubectl create deployment web --image=nginx:1.27
kubectl create secret generic db --from-literal=pass=s3cr3t
kubectl create configmap app-cfg --from-file=./config/
kubectl create job --from=cronjob/report run-now
kubectl create deployment web --image=nginx --dry-run=client -o yaml > deploy.yaml
```

## Common errors in CI

"Error from server (AlreadyExists): ... already exists" is the classic re-run failure: create is not idempotent, so a retried pipeline that already created the object fails the second time. Use kubectl apply for declarative idempotency, or for the secret/configmap pattern pipe through apply: kubectl create secret generic db --from-literal=pass=x --dry-run=client -o yaml | kubectl apply -f -. That generates the object and applies it idempotently.

## 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 create: Usage, Options & Common CI Errors?

kubectl create makes a brand-new resource and errors if it already exists. Its subcommands (secret, configmap, deployment, job) are also the fastest way to generate correct manifest YAML.

### What it does?

kubectl create -f reads a manifest and creates the objects, failing if any already exist (unlike apply, which patches). The subcommand forms - create secret generic, create configmap, create job - build resources from flags.

### Common errors in CI?

"Error from server (AlreadyExists): ... already exists" is the classic re-run failure: create is not idempotent, so a retried pipeline that already created the object fails the second time.

---

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