# kubectl and Declarative Objects — Kubernetes

Source: https://www.skillbyai.com/en/kubernetes/i-declare

> Describe, apply, let controllers converge.

## 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.

```bash
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.

**Quiz:** What is the difference between spec and status?

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

*Answer:* spec is the desired state you declare; status is the observed state reported by the cluster. Controllers drive status toward spec.
