⌂ Home

Kubernetes objects, labels, and editing workflows

Connect YAML structure to real resources: Deployments, Services, ConfigMaps, and the kubectl commands you use in labs to create, inspect, and change manifests safely.

Prerequisite: Part 1 (indentation, lists, mappings). This part: the standard apiVersion/kind/metadata/spec pattern, label/selectors, full Deployment+Service examples, and practical add/edit flows aligned with repo paths like k8s/labs/basics/.

The standard object shape

apiVersion: ...    # which API
kind: ...          # resource type
metadata:         # name, namespace, labels, annotations
  ...
spec:              # desired state (varies by kind)
  ...

The cluster fills status for you—do not copy status from kubectl get -o yaml back into hand-written files unless you know you need it (usually you do not).

Labels and selectors

Labels are metadata used for grouping and routing. A Service selector must match Pod labels.

Pod template labels

metadata:
  labels:
    app: nginx
    tier: frontend

Service selector

spec:
  selector:
    app: nginx
  ports:
    - port: 80
      targetPort: 8080

If selectors and labels disagree, the Service has no endpoints—always check kubectl describe svc <name> in the lab.

Deployment YAML (controllers + Pod template)

Workloads labs

A Deployment nests a Pod template under spec.template. Indentation depth is easy to get wrong: containers belongs under template.spec, not under spec next to replicas.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx:1.25.3
          ports:
            - containerPort: 80

ConfigMap and Secret (data you will edit)

ConfigMap

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  LOG_LEVEL: info
  app.properties: |
    feature.enabled=true

Secret (authoring with `stringData`)

Use stringData when writing by hand; Kubernetes stores encoded values. Never commit real production secrets to git.

apiVersion: v1
kind: Secret
metadata:
  name: app-secret
type: Opaque
stringData:
  api_token: replace-in-lab-only

Lab workflows: add, apply, edit, re-apply

1. Edit fileOpen k8s/labs/... in your editor. Change image tag, replicas, or env vars.

2. Dry-run (optional)kubectl apply --dry-run=client -f path/to/file.yaml

3. Applykubectl apply -f path/to/file.yaml

4. Verifykubectl get, kubectl describe, kubectl logs

Quick experiment: kubectl edit

kubectl edit deployment/nginx-deployment

Opens the live object in an editor. Good for learning; for reproducible labs, prefer changing the YAML file and re-applying.

Export what the cluster has

kubectl get deployment nginx-deployment -o yaml

Strip status

Use exports to compare field names, then trim status and read-only fields before saving as a manifest.

Try in the labs (concrete exercises)

Change image: In a Pod or Deployment manifest under k8s/labs/basics/ or k8s/labs/workloads/, set image: to another tag (e.g. nginx:1.25-alpine), apply, run kubectl describe pod and confirm the image.
Scale via YAML: Edit replicas: in a Deployment file, apply, watch kubectl get pods -w.
Fix a broken file: Intentionally break indentation under containers:, run kubectl apply, read the error, fix spaces, re-apply.
Two resources, one file: Append --- and a small Service below a Deployment; apply once and verify both objects.

Discover fields with kubectl explain

kubectl explain pod
kubectl explain pod.spec
kubectl explain pod.spec.containers
kubectl explain deployment.spec.template.spec

When YAML fails validation, kubectl explain is faster than guessing field names from blog posts.

Next: editors, validation, and troubleshooting

Go to Part 3 — VS Code extensions, online YAML tools, dry-run/server checks, and common error patterns.