Official documentation describes Kubernetes as an open-source system for container orchestration. That definition is correct, but not immediately useful when something breaks.

A more useful mental model is a distributed key-value store (etcd) plus a set of controllers that continuously reconcile actual state against the desired state you write in YAML. Understanding that loop makes Pods, Deployments, Services, and Namespaces much easier to reason about.

Four core objects

Most day-to-day Kubernetes work starts with these four objects.

1. A Pod is a group of co-scheduled containers

A Pod is not a single container. It is a group of containers that share a network namespace, storage volumes, and lifecycle placement. A main application often needs a closely coupled helper such as a log collector or service proxy, and placing those containers in one Pod is the natural scheduling boundary.

2. A Deployment keeps the desired replica count

You rarely create a bare Pod for production. If its node disappears, nothing schedules a replacement. A Deployment writes replicas: 3, a ReplicaSet watches matching Pods, and missing Pods are replaced. It also performs controlled rolling updates when the image or template changes.

3. A Service is a stable entry point

Pods are routinely replaced and usually receive new IPs. A Service gives a changing set of Pods one stable virtual IP and DNS name. Traffic is forwarded to healthy, ready endpoints through mechanisms such as iptables or IPVS.

4. A Namespace is an organizational scope

A Namespace groups related resources and is useful for separating teams or environments. It is not a strong security boundary by itself. Without RBAC and NetworkPolicy, workloads in different Namespaces may still be able to communicate.

YAML is a structured API request

Long manifests become easier to read once you separate API version, object kind, identity, and desired state:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello
  namespace: demo
spec:
  replicas: 2
  selector:
    matchLabels:
      app: hello
  template:
    metadata:
      labels:
        app: hello
    spec:
      containers:
        - name: web
          image: nginx:1.25
          ports:
            - containerPort: 80

Apply is not success

A successful kubectl apply only means the desired state was accepted. It does not mean the workload is running, ready, or reachable.

Common failure shapes include:

  • Pending Pods from node selector, taint, or resource mismatch
  • ImagePullBackOff from an invalid image reference or credentials
  • CrashLoopBackOff from failing startup, configuration, or probes

Verify immediately after applying:

kubectl get deploy,pods -n demo
kubectl describe pod <pod-name> -n demo

Practice with one small loop

Use the same verification loop for every lab change:

kubectl create namespace demo
kubectl apply -f app.yaml
kubectl get pods -n demo
kubectl describe pod -n demo
kubectl get events -n demo --sort-by=.metadata.creationTimestamp

After a few changes, the event stream and controller behavior become much less abstract.

Common misreads

  • Kubernetes is not a PaaS; it does not build images or write your CI/CD.
  • A Pod is not a long-lived machine.
  • A Service is not a process; it is stable routing to endpoints.
  • Namespace is an organizational scope, not a complete security model.
  • Reconciliation is asynchronous. created does not mean ready.

Three beginner misconceptions

Q: What are the first Kubernetes objects I should understand? A: Pods, Deployments, Services, and Namespaces explain most day-to-day workflows.

Q: Why is Kubernetes called declarative? A: You write desired state, and controllers continuously reconcile the cluster toward it.

Q: Does Kubernetes replace CI/CD, monitoring, or application design? A: No. It manages orchestration and lifecycle; you still need delivery, observability, secure code, and operational standards.

References