kubectl and Declarative Objects

YAML manifests and kubectl apply

Kubernetes objects are described in YAML (or JSON) manifests with apiVersion, kind, metadata (name, namespace, labels) and spec (desired state); the cluster adds status (observed state). The recommended workflow is declarative: store manifests in git and run kubectl apply -f, so the cluster converges to what the files say. kubectl create ... --dry-run=client -o yaml is a quick way to generate a starting manifest without touching a cluster, and kubectl get, describe and logs inspect what is running.

Generating a Deployment manifest, run

I ran this with kubectl 1.37.0 using --dry-run=client (or kubectl kustomize), which generates manifests locally without a cluster; nothing was applied to a live cluster. The generated manifest has the four top-level parts. Note the empty resources and strategy fields: generated manifests are a starting point to edit, not production-ready.

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

Output:

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

Keep manifests in git

Version-controlled manifests (GitOps tools like Argo CD or Flux can apply them) make every change reviewable and reversible.

Quick check: What is the difference between spec and status?

• spec is only for Services
• They are identical
• status is written by users
• spec is the desired state you declare; status is the observed state reported by the cluster