kubectl Commands and Kubernetes YAML Examples

Use client dry-run when you want a starter manifest that is not submitted for persistence — common in CKAD/CKA tasks where you paste YAML into an editor.

Run the command:

kubectl create deployment web --image=nginx:1.27 --replicas=2 --dry-run=client -o yaml

Sample output:

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: web
  name: web
spec:
  replicas: 2
  selector:
    matchLabels:
      app: web
  strategy: {}
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
      - image: nginx:1.27
        name: nginx
        resources: {}
status: {}

Save the YAML, edit fields such as resources or probes, then apply it with kubectl apply -f. Drop the status: {} line from manifests you write — Kubernetes controllers and system components populate status after the object exists; kubectl does not fill it in for you.

Server dry-run sends the object through admission controllers and validation webhooks. Use it when client-side YAML looks fine but the API might reject it.

Run the command:

kubectl apply -f - --dry-run=server <<'EOF'
apiVersion: v1
kind: ConfigMap
metadata:
  name: demo-cm
  namespace: demo
data:
  key: value
EOF

Sample output:

configmap/demo-cm created (server dry run)

The (server dry run) suffix confirms nothing was persisted. Create the demo namespace first with kubectl create namespace demo if it does not exist.

kubectl explain reads OpenAPI schema from the API server — faster than guessing field names when you write YAML. For deeper discovery of groups and versions, see Kubernetes API resources.

Run the command:

kubectl explain pod.spec.containers --api-version=v1 | head -12

Sample output:

KIND:       Pod
VERSION:    v1

FIELD: containers <[]Container>


DESCRIPTION:
    List of containers belonging to the pod. Containers cannot currently be
    added or removed. There must be at least one container in a Pod. Cannot be
    updated.

Add --recursive on supported types to print the whole subtree, for example kubectl explain deployment.spec --recursive.

JSONPath pulls one or more fields from kubectl get -o json without dumping the full object — useful in scripts and quick cluster audits.

Run the command:

kubectl get nodes -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.status.nodeInfo.kubeletVersion}{"\n"}{end}'

Sample output:

k8s-cp	v1.36.3
worker01	v1.36.3

{range .items[*]} iterates through every node object, while {"\t"} and {"\n"} format the output into columns and rows. Use {.items[0].metadata.name} when you need a single match.

Declarative apply is the default workflow for manifests you store in Git. kubectl creates the object on first apply and patches it on later runs.

Create a lab namespace if you need one:

kubectl create namespace demo

Create the manifest and apply it:

kubectl apply -f - <<'EOF'
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-demo
  namespace: demo
  labels:
    app: nginx-demo
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx-demo
  template:
    metadata:
      labels:
        app: nginx-demo
    spec:
      containers:
      - name: nginx
        image: nginx:1.27
        ports:
        - containerPort: 80
EOF

Sample output:

deployment.apps/nginx-demo created

Wait until replicas are available:

kubectl rollout status deployment/nginx-demo -n demo --timeout=60s

Sample output:

deployment "nginx-demo" successfully rolled out

created on the first apply becomes configured when you change the same manifest and apply again.

Custom columns are readable in the terminal and map cleanly to the fields you care about during rollouts.

Run the command:

kubectl get pods -n demo -l app=nginx-demo -o custom-columns=NAME:.metadata.name,IP:.status.podIP,NODE:.spec.nodeName,READY:.status.containerStatuses[0].ready

Sample output:

NAME                          IP            NODE       READY
nginx-demo-846cc57b79-fv6cb   192.168.5.6   worker01   true
nginx-demo-846cc57b79-x79xp   192.168.5.5   worker01   true

Pods still starting may show <none> for IP and false for READY until kubelet reports the container state.

Patch when you need a one-field change and do not want to open the full YAML — exams often test strategic merge and JSON Patch syntax.

Run the strategic merge patch (default):

kubectl patch deployment nginx-demo -n demo -p '{"spec":{"replicas":3}}'

Sample output:

deployment.apps/nginx-demo patched

Confirm the new replica count:

kubectl get deployment nginx-demo -n demo -o jsonpath='{.spec.replicas}{"\n"}'

Sample output:

3

For explicit JSON Patch operations, add --type=json and a list of op, path, and value entries.

Imperative commands mutate objects in place. They are quick for labs; prefer YAML in production so changes stay reviewable.

Scale the Deployment:

kubectl scale deployment nginx-demo -n demo --replicas=2

Sample output:

deployment.apps/nginx-demo scaled

Add a label and change the container image:

kubectl label deployment nginx-demo -n demo tier=web --overwrite

kubectl set image deployment/nginx-demo -n demo nginx=nginx:1.27-alpine

Sample output:

deployment.apps/nginx-demo labeled
deployment.apps/nginx-demo image updated

Verify labels on the controller:

kubectl get deployment nginx-demo -n demo --show-labels

Sample output:

NAME         READY   UP-TO-DATE   AVAILABLE   AGE   LABELS
nginx-demo   2/2     2            2           54s   app=nginx-demo,tier=web

set image triggers a rolling update when the image reference changes.

kubectl diff compares the live object with the version that would result if the supplied manifest were applied. Exit code 1 with a unified diff is normal when changes exist.

Run the command:

kubectl diff -f /tmp/nginx-demo-diff.yaml

Sample output:

diff -u -N /tmp/LIVE-784548609/apps.v1.Deployment.demo.nginx-demo /tmp/MERGED-1271217826/apps.v1.Deployment.demo.nginx-demo
--- /tmp/LIVE-784548609/apps.v1.Deployment.demo.nginx-demo
+++ /tmp/MERGED-1271217826/apps.v1.Deployment.demo.nginx-demo
@@ -17,7 +17,7 @@
 spec:
   progressDeadlineSeconds: 600
-  replicas: 2
+  replicas: 5
   revisionHistoryLimit: 10

The minus and plus lines show what apply would change. Generate /tmp/nginx-demo-diff.yaml from your edited manifest or export the live object, change one field, and diff again.

Imperative expose creates a Service that selects Pod labels from an existing controller — handy when you already have Pods running and need a ClusterIP quickly.

Run the command:

kubectl expose deployment nginx-demo -n demo --port=80 --target-port=80 --name=nginx-demo

Sample output:

service/nginx-demo exposed

List the Service:

kubectl get svc nginx-demo -n demo

Sample output:

NAME         TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)   AGE
nginx-demo   ClusterIP   10.100.130.182   <none>        80/TCP    5s

For production, check the generated Service into Git or capture a manifest with client dry-run. kubectl expose reads and reuses the Deployment selector:

kubectl expose deployment nginx-demo -n demo --port=80 --target-port=80 --name=nginx-demo --dry-run=client -o yaml

Literal ConfigMaps are common for exam questions. Client dry-run prints the manifest you can paste into an editor.

Run the command:

kubectl create configmap demo-cm2 -n demo --from-literal=env=prod --dry-run=client -o yaml

Sample output:

apiVersion: v1
data:
  env: prod
kind: ConfigMap
metadata:
  name: demo-cm2
  namespace: demo

Mount or reference this ConfigMap from a Pod env, envFrom, or volume — see the ConfigMap tutorial when you wire it into a workload.