# kubectl create: Command Reference for CI/CD

> Reference for kubectl create: imperative resource creation, the create-then-apply pattern, --dry-run YAML generation, and a CI example.

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

Create a brand-new resource imperatively, or scaffold manifest YAML.

kubectl create makes a new resource and errors if it already exists, which makes it the non-idempotent counterpart to apply. Its subcommands are also the fastest way to generate correct YAML to commit. This reference covers the flags and the safe CI patterns.

## Common flags and usage

- -f, --filename: create from a manifest (fails on AlreadyExists)
- create deployment|job|namespace: build a resource from flags
- --dry-run=client -o yaml: print the manifest instead of creating it
- --from=cronjob/<name>: create a one-off Job from a CronJob
- --save-config: store last-applied so future apply merges cleanly

## Example

```shell
# Scaffold YAML to commit
kubectl create deployment web --image=web:${GIT_SHA} \
  --dry-run=client -o yaml > k8s/web.yaml

# Idempotent create-then-apply in a re-runnable job
kubectl create namespace ci-${BUILD_ID} \
  --dry-run=client -o yaml | kubectl apply -f -
```

## In CI

create is not idempotent, so a retried pipeline that already created an object fails with AlreadyExists. Pipe create through apply (create ... --dry-run=client -o yaml | kubectl apply -f -) to get the generator ergonomics with declarative idempotency.

## 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: Command Reference for CI/CD?

kubectl create makes a new resource and errors if it already exists, which makes it the non-idempotent counterpart to apply. Its subcommands are also the fastest way to generate correct YAML to commit. This reference covers the flags and the safe CI patterns.

### In CI?

create is not idempotent, so a retried pipeline that already created an object fails with AlreadyExists. Pipe create through apply (create ... --dry-run=client -o yaml | kubectl apply -f -) to get the generator ergonomics with declarative idempotency.

---

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