kubectl create

When to Use kubectl create

kubectl create is an imperative command that creates Kubernetes resources. It is the straightforward way to bring a new resource into existence, either from a file or by specifying parameters on the command line. The command will fail if the resource already exists, which makes it safe against accidental overwrites but less suited for continuous deployment workflows.

Imperative vs Declarative

The fundamental distinction in Kubernetes resource management is between imperative commands like kubectl create and declarative commands like kubectl apply. With create, you tell Kubernetes exactly what to do: make this thing. With apply, you declare the desired state and let Kubernetes figure out what changes are needed.

# Imperative: fails if already exists
kubectl create deployment nginx --image=nginx:1.25

# Declarative: creates or updates as needed
kubectl apply -f deployment.yaml

In production, most teams use kubectl apply for resources managed through Git. However, kubectl create remains valuable for quick operations and for generating YAML templates.

Generating YAML Templates

One of the most practical uses of kubectl create is generating starter YAML files with the --dry-run=client -o yaml pattern:

# Generate a deployment manifest
kubectl create deployment web --image=nginx:1.25 --replicas=3 \
  --dry-run=client -o yaml > deployment.yaml

# Generate a service manifest
kubectl create service clusterip web --tcp=80:80 \
  --dry-run=client -o yaml > service.yaml

# Generate a job manifest
kubectl create job backup --image=busybox -- /bin/sh -c "echo backup" \
  --dry-run=client -o yaml > job.yaml

This technique saves you from writing boilerplate YAML by hand. You generate the skeleton, then edit it to add resource limits, environment variables, volume mounts, and other details.

Creating Secrets and ConfigMaps

Creating secrets and configmaps imperatively is a common workflow because these resources often hold data that should not be committed to version control:

# Create a TLS secret from certificate files
kubectl create secret tls my-tls --cert=tls.crt --key=tls.key

# Create a docker registry secret
kubectl create secret docker-registry regcred \
  --docker-server=registry.example.com \
  --docker-username=user \
  --docker-password=pass

# Create a configmap from multiple files
kubectl create configmap app-config \
  --from-file=app.conf \
  --from-file=logging.conf

# Create a configmap from an env file
kubectl create configmap env-config --from-env-file=.env

Subcommands

kubectl create supports many subcommands for specific resource types. Each subcommand has its own flags tailored to that resource:

# Create resources with specific subcommands
kubectl create namespace staging
kubectl create serviceaccount deployer -n staging
kubectl create role pod-reader --verb=get,list --resource=pods
kubectl create rolebinding pod-reader-binding \
  --role=pod-reader --serviceaccount=staging:deployer
kubectl create clusterrole cluster-reader --verb=get,list --resource=nodes
kubectl create quota my-quota --hard=pods=10,requests.cpu=4 -n staging

These subcommands are useful for setting up RBAC, quotas, and other cluster configuration imperatively.

Server-Side Dry Run

The --dry-run=server option sends the request to the API server for validation without persisting it. This is more thorough than --dry-run=client because it validates against admission webhooks, resource quotas, and other server-side checks:

# Validate against server-side policies
kubectl create -f deployment.yaml --dry-run=server

# Check if your RBAC allows creating this resource
kubectl create deployment test --image=nginx \
  --dry-run=server -o yaml

Server-side dry run is particularly useful in CI/CD pipelines to validate manifests before deployment.

Working with Multiple Files

You can create resources from directories or URLs:

# Create all resources in a directory
kubectl create -f ./manifests/

# Create from a URL
kubectl create -f https://raw.githubusercontent.com/org/repo/main/deploy.yaml

# Create from stdin using a heredoc
cat <<EOF | kubectl create -f -
apiVersion: v1
kind: ConfigMap
metadata:
  name: test-config
data:
  key: value
EOF

When creating from a directory, Kubernetes processes all YAML and JSON files in the directory. Files are applied in alphabetical order, so naming conventions like 01-namespace.yaml, 02-service.yaml can help control ordering.

Best Practices

For production workflows, prefer kubectl create for one-off resources and bootstrapping, and kubectl apply for resources you maintain over time. Always use --dry-run=client -o yaml to generate templates rather than writing YAML from scratch. When creating sensitive resources like Secrets, be mindful that the command will appear in your shell history with the literal values exposed.