ITInsightHub

kubectl cheat sheet: resources & YAML

Every Kubernetes object is a kind of resource described in YAML with four top-level fields: apiVersion, kind, metadata (name, namespace, labels) and spec (the desired state). The resources below are the ones you will actually create; everything else is an extension of them.

The rule that holds them together: a Pod is the smallest unit (one or more containers), a Deployment manages a fleet of identical pods with rollouts and restarts, and a Service gives that fleet a stable network identity.

Published

The core resource types

Workloads and their jobs
KindWhat it runs
Podthe smallest unit — one or more containers sharing network and storage
ReplicaSetkeeps N identical pods running (usually managed by a Deployment)
Deploymentdeclarative pod management with rolling updates and rollbacks — the default choice
StatefulSetpods with stable identities and storage, for databases and stateful apps
DaemonSetone pod on every node (log collectors, agents)
Jobruns to completion once
CronJobruns Jobs on a schedule
Networking, config and isolation
KindWhat it does
Servicea stable IP/DNS in front of a set of pods, with load balancing
IngressHTTP routing from outside the cluster to Services
ConfigMapnon-secret configuration (env vars, config files)
Secretsensitive data (passwords, tokens), base64-encoded at rest
Namespacea virtual cluster for isolating groups of objects
PersistentVolumeClaima request for storage, bound to a volume

A working Deployment + Service

deploy.yaml — a Deployment exposed by a Service
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx:1.27
          ports:
            - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: nginx
spec:
  selector:
    app: nginx
  ports:
    - port: 80
      targetPort: 80
  type: ClusterIP
The spec.selector.matchLabels of the Deployment must match the pod template's metadata.labels, and the Service's spec.selector must match the same labels — that is how the Service knows which pods to route to. A selector mismatch is the single most common "deployment looks healthy but no traffic arrives" bug.

Labels, namespaces and context

Working with labels, namespaces and multiple clusters
# Create a namespace
kubectl create namespace staging

# Get pods with a label selector
kubectl get pods -l app=nginx

# List everything in a namespace (pods, services, deployments, replicasets)
kubectl get all -n staging

# See which cluster/context you are talking to
kubectl config get-contexts

# Switch context
kubectl config use-context prod-cluster
Despite its name, kubectl get all does not list ConfigMaps, Secrets, Ingresses, StatefulSets or many other kinds — it only shows the common workload/service types. Before running a destructive command, always confirm which context is active with kubectl config current-context; the most expensive kubectl mistakes are commands run against the wrong cluster.

References

FAQ

What is the difference between a Pod and a Deployment?

A Pod is the smallest runnable unit — one or more containers. A Deployment is a controller that manages a set of identical pods, recreating them when they fail and performing rolling updates. You rarely create a bare Pod for a long-running service; you create a Deployment and let it manage the pods.

What is the difference between a ConfigMap and a Secret?

Both hold key-value configuration for pods, but a ConfigMap is for non-sensitive data and a Secret is for sensitive data like passwords and tokens. Secrets are base64-encoded (not encrypted) at rest and can be stored encrypted with proper configuration; treat them as the place for credentials, and ConfigMaps as the place for plain settings.

What does a Service actually do?

A Service gives a stable IP address and DNS name to a set of pods, which are otherwise ephemeral (their IPs change on every restart). It also load-balances traffic across the matching pods. Selectors link the Service to pods, and the type field (ClusterIP, NodePort, LoadBalancer) controls how it is exposed.

Why is my Service not routing traffic to my pods?

Almost always a selector mismatch: the Service's spec.selector labels must exactly match the pod template's metadata.labels. Check with kubectl get endpoints — if the Endpoints list is empty, the Service found no matching pods. Confirm the targetPort also matches the container's port.