Creating and Editing Resources

You already know kubectl apply. But there are several other ways to create and modify resources in Kubernetes, and each follows its own logic. Knowing which one to use, and when, prevents frustrating drift between what your files say and what the cluster actually runs.

kubectl apply: the declarative foundation

kubectl apply -f is the main command for declarative workflows. It creates the resource if it does not exist, and updates it if it does. The API server calculates the difference between what you submit and what is currently stored, then applies only the changes.

nano web-deployment.yaml

# illustrative only
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 2
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: web
          image: nginx:1.28

kubectl apply -f web-deployment.yaml
kubectl get deployment web

Run kubectl apply -f a second time without changing the file. The output says unchanged. That is idempotency in action: the command is safe to run repeatedly.

kubectl create: imperative, one-shot

kubectl create is the imperative counterpart. It creates an object and fails with an AlreadyExists error if the resource is already there. That makes it unsuitable for repeated workflows, but excellent for quick one-off operations and for its specialized subcommands.

kubectl create namespace staging
kubectl create configmap app-config --from-literal=LOG_LEVEL=info
kubectl get configmap app-config

kubectl create deployment is especially useful when you want to generate a YAML template without applying it. You learned this in the yaml-and-objects module: combine --dry-run=client with -o yaml to produce a ready-to-edit manifest.

kubectl create deployment web --image=nginx:1.28 --dry-run=client -o yaml

Nothing is created in the simulated cluster. The output is a valid Deployment manifest you can redirect into a file, adjust, then apply.

kubectl edit: direct live editing

kubectl edit fetches the current live state of a resource and opens it in an editor. On a real cluster this is typically vi. In the simulator, changes take effect immediately after you confirm.

kubectl create deployment web --image=nginx:1.28
kubectl edit deployment web

Why is this convenient but risky? Because kubectl edit modifies the live object without touching any local file. If you later run kubectl apply -f web-deployment.yaml with your original file, the API server will overwrite everything kubectl edit changed. Your file wins, and the edit-based change is silently gone.

This is why production workflows stay on kubectl apply -f. Interactive edits with kubectl edit are fine for exploration and debugging, but they should not be the primary mechanism for changing resources in a team environment.

kubectl set image: targeted image update

kubectl set image changes the container image in a Deployment, DaemonSet, or Pod without opening any editor or touching a file.

kubectl set image deployment/web web=nginx:1.26
kubectl get deployment web -o yaml

This triggers a rolling update on the Deployment. The old ReplicaSet gradually scales down as a new one scales up with the updated image. It is practical for a quick rollout, but it has the same drawback as kubectl edit: your local YAML file no longer reflects what is running.

kubectl delete deployment web
kubectl delete namespace staging
kubectl delete configmap app-config

You now have four ways to create and modify resources, each with a clear scope. The next lesson covers the other end: how deletion works, what cascade means, and how to clean up a namespace safely.