Every object the API server stores has the same top-level layout.

apiVersion: apps/v1          ← API group and version
kind: Deployment             ← the type
metadata:                    ← identity: name, namespace, labels, annotations
  name: web
  namespace: shop
  labels: { app: web }
  uid: 943247cc-…            ← set by the server
  resourceVersion: "210"     ← set by the server, changes on every write
  generation: 1              ← bumped when spec changes
spec:                        ← desired state (you write this)
  replicas: 2
  template: …
status:                      ← observed state (controllers write this)
  readyReplicas: 2

The two halves that matter

spec is what you want. status is what the cluster has. A controller's whole job is to make status match spec. When they differ, something is in progress or something is wrong.

Printing an object

Three output formats cover almost every need:

kubectl get deploy web -o yaml
kubectl get deploy web -o json
kubectl get deploy web -o jsonpath='{.spec.template.spec.containers[0].image}'

-o yaml is the full object, including the server-set metadata and status. jsonpath pulls one value out. The path syntax is the YAML structure with dots, and [0] for list items.

Reading the schema

You do not have to memorise fields. explain prints the documentation for any path:

kubectl explain pod.spec.restartPolicy
kubectl explain deployment.spec.selector

api-resources lists every kind the server knows, with its short name and API group:

kubectl api-resources

The APIVERSION column is what goes in apiVersion. Core objects (Pod, Service, ConfigMap) use v1. Deployments and ReplicaSets use apps/v1. Writing apps/v1beta1 for a Deployment is rejected: that version no longer exists.